[ovirt-users] Re: Hosted Engine I/O scheduler

[Strahil Nikolov]

 Hi All,
I have changed my I/O scheduler to none and here are the results so far:
Before (mq-deadline):Adding a disk to VM (initial creation) START: 
2019-03-17 16:34:46.709Adding a disk to VM (initial creation) COMPLETED: 
2019-03-17 16:45:17.996
After (none):Adding a disk to VM (initial creation) START: 2019-03-18 
08:52:02.xxxAdding a disk to VM (initial creation) COMPLETED: 2019-03-18 
08:52:20.xxx
Of course the results are inconclusive, as I have tested only once - but I feel 
the engine more responsive.
Best Regards,Strahil Nikolov

В неделя, 17 март 2019 г., 18:30:23 ч. Гринуич+2, Strahil 
 написа:  
 
 
Dear All,

I have just noticed that my Hosted Engine has  a strange I/O scheduler:

Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43
[root@engine ~]# cat /sys/block/vda/queue/scheduler
[mq-deadline] kyber none
[root@engine ~]#

Based on my experience  anything than noop/none  is useless and performance 
degrading  for a VM.


Is there any reason that we have this scheduler ?
It is quite pointless  to process (and delay) the I/O in the VM and then 
process (and again delay)  on Host Level .

If there is no reason to keep the deadline, I will open a bug about it.

Best Regards,
Strahil Nikolov
Dear All,

I have just noticed that my Hosted Engine has  a strange I/O scheduler:

Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43
[root@engine ~]# cat /sys/block/vda/queue/scheduler
[mq-deadline] kyber none
[root@engine ~]#

Based on my experience  anything than noop/none  is useless and performance 
degrading  for a VM.


Is there any reason that we have this scheduler ?
It is quite pointless  to process (and delay) the I/O in the VM and then 
process (and again delay)  on Host Level .

If there is no reason to keep the deadline, I will open a bug about it.

Best Regards,
Strahil Nikolov  ___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YY5ZAPMTD5HUYEBEGD2YYO7EOSTVYIE7/

[ovirt-users] Migrate HE beetwen hosts failed.

[kiv]

Hi all.

I have oVirt 4.3.1 and 3 node hosts.
All VM migrate beetwen all hosts successfully.
VM with HE - does not migrate.

vdsm.log:

libvirtError: operation failed: guest CPU doesn't match specification: missing 
features: xsave,avx,xsaveopt

Nodes:
1. Intel Westmere IBRS SSBD Family
2. Intel Westmere IBRS SSBD Family
3. Intel SandyBridge IBRS SSBD Family <- HE now here

Cluster CPU Type: Intel Westmere Family

Info from VM with HE:

Guest CPU Type: Intel Westmere Family

Does anyone know what needs to be done to make migration work?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJTJKPF54G5JENPDRTTHQPUG3RAMGQ2C/

[ovirt-users] Re: Ovirt 4.3.1 problem with HA agent

[Николаев Алексей]

Thx for answer!   18.03.2019, 14:52, "Strahil Nikolov" : Hi Alexei, In order to debug it check the following: 1. Check gluster:1.1 All bricks up ? All peers up. Gluster version is 3.12.15 [root@node-msk-gluster203 ~]# gluster peer statusNumber of Peers: 2 Hostname: node-msk-gluster205.Uuid: 188d8444-3246-4696-a0a7-2872e0a01067State: Peer in Cluster (Connected) Hostname: node-msk-gluster201.Uuid: 919b0a60-b9b7-4091-a60a-51d43b995285State: Peer in Cluster (Connected) All bricks on all gluster servers are UP. Volume Name: dataType: ReplicateVolume ID: 8fb43ba3-b2e9-4e33-b4c3-b0b03cd8cba3Status: StartedSnapshot Count: 0Number of Bricks: 1 x (2 + 1) = 3Transport-type: tcpBricks:Brick1: node-msk-gluster203.:/opt/gluster/dataBrick2: node-msk-gluster205.:/opt/gluster/dataBrick3: node-msk-gluster201.:/opt/gluster/data (arbiter) Volume Name: engineType: ReplicateVolume ID: 5dda8427-c69b-4b96-bcd6-eff3be2e0b5cStatus: StartedSnapshot Count: 0Number of Bricks: 1 x (2 + 1) = 3Transport-type: tcp Bricks:Brick1: node-msk-gluster205.:/opt/gluster/engineBrick2: node-msk-gluster203.:/opt/gluster/engineBrick3: node-msk-gluster201.:/opt/gluster/engine (arbiter)   1.2 All bricks healed (gluster volume heal data info summary) and no split-brain  gluster volume heal data info Brick node-msk-gluster203:/opt/gluster/dataStatus: ConnectedNumber of entries: 0 Brick node-msk-gluster205:/opt/gluster/dataStatus: ConnectedNumber of entries: 7 Brick node-msk-gluster201:/opt/gluster/dataStatus: ConnectedNumber of entries: 7 gluster volume heal engine info Brick node-msk-gluster205.:/opt/gluster/engineStatus: ConnectedNumber of entries: 0 Brick node-msk-gluster203.:/opt/gluster/engineStatus: ConnectedNumber of entries: 0 Brick node-msk-gluster201.:/opt/gluster/engineStatus: ConnectedNumber of entries: 02. Go to the problematic host and check the mount point is there  No mount point on problematic node /rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_dataIf I create a mount point manually, it is deleted after the node is activated. Other nodes can mount this volume without problems. Only this node have connection problems after update. Here is a part of the log at the time of activation of the node: vdsm log 2019-03-18 16:46:00,548+0300 INFO  (jsonrpc/5) [vds] Setting Hosted Engine HA local maintenance to False (API:1630)2019-03-18 16:46:00,549+0300 INFO  (jsonrpc/5) [jsonrpc.JsonRpcServer] RPC call Host.setHaMaintenanceMode succeeded in 0.00 seconds (__init__:573)2019-03-18 16:46:00,581+0300 INFO  (jsonrpc/7) [vdsm.api] START connectStorageServer(domType=7, spUUID=u'5a5cca91-01f8-01af-0297-025f', conList=[{u'id': u'5799806e-7969-45da-b17d-b47a63e6a8e4', u'connection': u'msk-gluster-facility.:/data', u'iqn': u'', u'user': u'', u'tpgt': u'1', u'vfs_type': u'glusterfs', u'password': '', u'port': u''}], options=None) from=:::10.77.253.210,56630, flow_id=81524ed, task_id=5f353993-95de-480d-afea-d32dc94fd146 (api:46)2019-03-18 16:46:00,621+0300 INFO  (jsonrpc/7) [storage.StorageServer.MountConnection] Creating directory u'/rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_data' (storageServer:167)2019-03-18 16:46:00,622+0300 INFO  (jsonrpc/7) [storage.fileUtils] Creating directory: /rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_data mode: None (fileUtils:197)2019-03-18 16:46:00,622+0300 WARN  (jsonrpc/7) [storage.StorageServer.MountConnection] gluster server u'msk-gluster-facility.' is not in bricks ['node-msk-gluster203', 'node-msk-gluster205', 'node-msk-gluster201'], possibly mounting duplicate servers (storageServer:317)2019-03-18 16:46:00,622+0300 INFO  (jsonrpc/7) [storage.Mount] mounting msk-gluster-facility.:/data at /rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_data (mount:204)2019-03-18 16:46:00,809+0300 ERROR (jsonrpc/7) [storage.HSM] Could not connect to storageServer (hsm:2415)Traceback (most recent call last):  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2412, in connectStorageServer    conObj.connect()  File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 179, in connect    six.reraise(t, v, tb)  File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 171, in connect    self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP)  File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 207, in mount    cgroup=cgroup)  File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__    return callMethod()  File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 53, in     **kwargs)  File "", line 2, in mount  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod    raise convert_to_error(kind, result)MountError: (1, ';Running scope as unit run-72797.scope.\nMount failed. Please check the log file for more details.\n')  2.1. Check permissions (should be vdsm:kvm) and 

[ovirt-users] Re: How to fix ovn apparent inconsistency?

[Miguel Duarte de Mora Barroso]

On Mon, Mar 18, 2019 at 2:20 PM Gianluca Cecchi
 wrote:
>
> Hello,
> passing from old manual to current OVN in 4.3.1 it seems I have some problems 
> with OVN now.
> I cannot assign network on OVN to VM (powered on or off doesn't change).
> When I add//edit a vnic, they are not on the possible choices
> Environment composed by three hosts and one engine (external on vSphere).
> The mgmt network during time has been configured on network named 
> ovirtmgmntZ2Z3
> On engine it seems there are 2 switches for every defined ovn network (ovn192 
> and ovn172)
> Below some output of commands in case any inconsistency has remained and I 
> can purge it.
> Thanks in advance.
>

I'm very confused here; you mention that on engine there are 2
switches for every ovn network, but, on your ovn-nbctl list
logical_switch output I can clearly see the 2 logical switches where
the OVN logical networks are stored. Who created those ?

Could you show us the properties of those 2 networks ? (e.g. ovn-nbctl
list logical_switch 32367d8a-460f-4447-b35a-abe9ea5187e0 & ovn-nbctl
list logical_switch 64c4c17f-cd67-4e29-939e-2b952495159f)

+Marcin Mirecki  does this ring a bell? AFAIU, the ovn network names
had to be unique - until bug [0] was fixed, where the network names
would have a whole different format - e.g.
ovirt--  .

@Gianluca Cecchi , I notice that one of your duplicate networks -
'ovn192'  - has no ports attached. That makes it the perfect candidate
to be deleted, and see if it becomes 'listable' on engine. That would
help rule out the 'duplicate name' theory.

At the moment, I can't think of a better alternative. Let's see if
Marcin comes up with a better test / idea / alternative.

Also, please let us know the version of the ovirt-provider-ovn,
openvswitch-ovn-central, and openvswitch-ovn-host.

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1503577

> Gianluca
>
> - On manager ovmgr1:
>
> [root@ovmgr1 ~]# ovs-vsctl show
> eae54ff9-b86c-4050-8241-46f44336ba94
> ovs_version: "2.10.1"
> [root@ovmgr1 ~]#
>
> [root@ovmgr1 ~]# ovn-nbctl show
> switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
> port affc5570-3e5a-439c-9fdf-d75d6810e3a3
> addresses: ["00:1a:4a:17:01:73"]
> port f639d541-2118-4c24-b478-b7a586eb170c
> addresses: ["00:1a:4a:17:01:75"]
> switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
> switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
> port 32c348d9-12e9-4bcf-a43f-69338c887cfc
> addresses: ["00:1a:4a:17:01:72 dynamic"]
> port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69
> addresses: ["00:1a:4a:17:01:74 dynamic"]
> switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
> port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983
> addresses: ["00:1a:4a:17:01:65 dynamic"]
> port 8fc7bed4-7663-4903-922b-05e490c6a5a1
> addresses: ["00:1a:4a:17:01:64 dynamic"]
> port f2b64f89-b719-484c-ac02-2a1ac8eaacdb
> addresses: ["00:1a:4a:17:01:59 dynamic"]
> port f7389c88-1ea1-47c2-92fd-6beffb2e2190
> addresses: ["00:1a:4a:17:01:58 dynamic"]
> [root@ovmgr1 ~]#
>
> - On host ov200 (10.4.192.32 on ovirtmgmntZ2Z3):
> [root@ov200 ~]# ovs-vsctl show
> ae0a1256-7250-46a2-a1b6-8f0ae6105c20
> Bridge br-int
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Port "ovn-ddecf0-0"
> Interface "ovn-ddecf0-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.33"}
> Port "ovn-b8872a-0"
> Interface "ovn-b8872a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.34"}
> ovs_version: "2.10.1"
> [root@ov200 ~]#
>
> - On host ov300 (10.4.192.33 on ovirtmgmntZ2Z3):
>
> [root@ov300 ~]# ovs-vsctl show
> f1a41e9c-16fb-4aa2-a386-2f366ade4d3c
> Bridge br-int
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Port "ovn-b8872a-0"
> Interface "ovn-b8872a-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.34"}
> Port "ovn-1dce5b-0"
> Interface "ovn-1dce5b-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.32"}
> ovs_version: "2.10.1"
> [root@ov300 ~]#
>
> - On host ov301 (10.4.192.34 on ovirtmgmntZ2Z3):
> [root@ov301 ~]# ovs-vsctl show
> 3a38c5bb-0abf-493d-a2e6-345af8aedfe3
> Bridge br-int
> fail_mode: secure
> Port "ovn-1dce5b-0"
> Interface "ovn-1dce5b-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.32"}
> Port "ovn-ddecf0-0"
> Interface "ovn-ddecf0-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.4.192.33"}
> Port br-int
> Interface br-int
> type: 

[ovirt-users] Re: Hosted Engine I/O scheduler

[Darrell Budic]

Checked this on mine, see the same thing. Switching the engine to noop 
definitely feels more responsive.

I checked on some VMs as well, it looks like virtio drives (vda, vdb….) get 
mq-deadline by default, but virtscsi gets noop. I used to think the tuned 
profile for virtual-guest would set noop, but apparently not…

  -Darrell

> On Mar 18, 2019, at 1:58 AM, Strahil Nikolov  wrote:
> 
> Hi All,
> 
> I have changed my I/O scheduler to none and here are the results so far:
> 
> Before (mq-deadline):
> Adding a disk to VM (initial creation) START: 2019-03-17 16:34:46.709
> Adding a disk to VM (initial creation) COMPLETED: 2019-03-17 16:45:17.996
> 
> After (none):
> Adding a disk to VM (initial creation) START: 2019-03-18 08:52:02.xxx
> Adding a disk to VM (initial creation) COMPLETED: 2019-03-18 08:52:20.xxx
> 
> Of course the results are inconclusive, as I have tested only once - but I 
> feel the engine more responsive.
> 
> Best Regards,
> Strahil Nikolov
> 
> В неделя, 17 март 2019 г., 18:30:23 ч. Гринуич+2, Strahil 
>  написа:
> 
> 
> Dear All,
> 
> I have just noticed that my Hosted Engine has  a strange I/O scheduler:
> 
> Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43 
> [root@engine ~]# cat /sys/block/vda/queue/scheduler
> [mq-deadline] kyber none
> [root@engine ~]#
> 
> Based on my experience  anything than noop/none  is useless and performance 
> degrading  for a VM.
> 
> Is there any reason that we have this scheduler ?
> It is quite pointless  to process (and delay) the I/O in the VM and then 
> process (and again delay)  on Host Level .
> 
> If there is no reason to keep the deadline, I will open a bug about it.
> 
> Best Regards,
> Strahil Nikolov
> 
> Dear All,
> 
> I have just noticed that my Hosted Engine has  a strange I/O scheduler:
> 
> Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43
> [root@engine  ~]# cat /sys/block/vda/queue/scheduler
> [mq-deadline] kyber none
> [root@engine  ~]#
> 
> Based on my experience  anything than noop/none  is useless and performance 
> degrading  for a VM.
> 
> 
> Is there any reason that we have this scheduler ?
> It is quite pointless  to process (and delay) the I/O in the VM and then 
> process (and again delay)  on Host Level .
> 
> If there is no reason to keep the deadline, I will open a bug about it.
> 
> Best Regards,
> Strahil Nikolov
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/YY5ZAPMTD5HUYEBEGD2YYO7EOSTVYIE7/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/IXY7RZWFF3B4PJPMO6GCTLTBGWWRMHGB/

[ovirt-users] How to fix ovn apparent inconsistency?

[Gianluca Cecchi]

Hello,
passing from old manual to current OVN in 4.3.1 it seems I have some
problems with OVN now.
I cannot assign network on OVN to VM (powered on or off doesn't change).
When I add//edit a vnic, they are not on the possible choices
Environment composed by three hosts and one engine (external on vSphere).
The mgmt network during time has been configured on network
named ovirtmgmntZ2Z3
On engine it seems there are 2 switches for every defined ovn network
(ovn192 and ovn172)
Below some output of commands in case any inconsistency has remained and I
can purge it.
Thanks in advance.

Gianluca

- On manager ovmgr1:

[root@ovmgr1 ~]# ovs-vsctl show
eae54ff9-b86c-4050-8241-46f44336ba94
ovs_version: "2.10.1"
[root@ovmgr1 ~]#

[root@ovmgr1 ~]# ovn-nbctl show
switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
port affc5570-3e5a-439c-9fdf-d75d6810e3a3
addresses: ["00:1a:4a:17:01:73"]
port f639d541-2118-4c24-b478-b7a586eb170c
addresses: ["00:1a:4a:17:01:75"]
switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
port 32c348d9-12e9-4bcf-a43f-69338c887cfc
addresses: ["00:1a:4a:17:01:72 dynamic"]
port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69
addresses: ["00:1a:4a:17:01:74 dynamic"]
switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983
addresses: ["00:1a:4a:17:01:65 dynamic"]
port 8fc7bed4-7663-4903-922b-05e490c6a5a1
addresses: ["00:1a:4a:17:01:64 dynamic"]
port f2b64f89-b719-484c-ac02-2a1ac8eaacdb
addresses: ["00:1a:4a:17:01:59 dynamic"]
port f7389c88-1ea1-47c2-92fd-6beffb2e2190
addresses: ["00:1a:4a:17:01:58 dynamic"]
[root@ovmgr1 ~]#

- On host ov200 (10.4.192.32 on ovirtmgmntZ2Z3):
[root@ov200 ~]# ovs-vsctl show
ae0a1256-7250-46a2-a1b6-8f0ae6105c20
Bridge br-int
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "ovn-ddecf0-0"
Interface "ovn-ddecf0-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.4.192.33"}
Port "ovn-b8872a-0"
Interface "ovn-b8872a-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.4.192.34"}
ovs_version: "2.10.1"
[root@ov200 ~]#

- On host ov300 (10.4.192.33 on ovirtmgmntZ2Z3):

[root@ov300 ~]# ovs-vsctl show
f1a41e9c-16fb-4aa2-a386-2f366ade4d3c
Bridge br-int
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "ovn-b8872a-0"
Interface "ovn-b8872a-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.4.192.34"}
Port "ovn-1dce5b-0"
Interface "ovn-1dce5b-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.4.192.32"}
ovs_version: "2.10.1"
[root@ov300 ~]#

- On host ov301 (10.4.192.34 on ovirtmgmntZ2Z3):
[root@ov301 ~]# ovs-vsctl show
3a38c5bb-0abf-493d-a2e6-345af8aedfe3
Bridge br-int
fail_mode: secure
Port "ovn-1dce5b-0"
Interface "ovn-1dce5b-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.4.192.32"}
Port "ovn-ddecf0-0"
Interface "ovn-ddecf0-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.4.192.33"}
Port br-int
Interface br-int
type: internal
ovs_version: "2.10.1"
[root@ov301 ~]#

In web admin gui:

In network -> networks ->
- ovn192
Id: 8fd63a10-a2ba-4c56-a8e0-0bc8d70be8b5
VDSM Name: ovn192
External ID: 32367d8a-460f-4447-b35a-abe9ea5187e0

- ovn172
Id: 7546d5d3-a0e3-40d5-9d22-cf355da47d3a
VDSM Name: ovn172
External ID: 64c4c17f-cd67-4e29-939e-2b952495159f
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/W6U4XJHNMYMD3WIXDCPGOXLW6DFMCYIM/

[ovirt-users] Re: Bandwidth problem

[Oliver Riesener]

Hi, 

i got with iperf:

To a remote VM on different HOST:
10.8 Gb/s  „TCP“  bandwidth. „UDP“ (-u) <= 1Kb/s + failed ACK last 
block

To a local VM on same HOST:
 11.1 Gb/s  „TCP“ bandwidth.  „UDP“ (-u) <= 1Mb/s + failed ACK last 
block

VM’s run Linux Debian 8/9, virtio_net, guest tools installed, MTU 1500

HOST's have Intel Cards X540, MTU 1500

Possible did you run „UDP“ tests only ?

Cheers

Oliver

> Am 09.03.2019 um 11:26 schrieb Leo David :
> 
> Hello Everyone,
> I have 10Gb connections setup for all the hosts in the cluster, for both 
> management/vm  and gluster traffic ( separate network cards )
> The problem is that i just cannot pass 1Gb/s traffic between vms ( even 
> between vms running on the same hosts ! - which makes the things more 
> weird... ). Traffic measured by using iperf tool.
> Is there a way I can check waht could be the problem ? Network card type,  vm 
> drivers,  any suggestion ? I just do not know where to look for a possible 
> cause.
> Thank you very much !
> 
> Leo
> 
> -- 
> Best regards, Leo David
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/IVBUE56TB5E3CNSKRGR7TCTTX6IKKHXJ/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/W3ICWOBJFCS6ZZROXAZROZOY5OFLMDJP/

[ovirt-users] Re: How to fix ovn apparent inconsistency?

[Gianluca Cecchi]

On Mon, Mar 18, 2019 at 4:40 PM Miguel Duarte de Mora Barroso <
mdbarr...@redhat.com> wrote:

> On Mon, Mar 18, 2019 at 2:20 PM Gianluca Cecchi
>  wrote:
> >
> > Hello,
> > passing from old manual to current OVN in 4.3.1 it seems I have some
> problems with OVN now.
> > I cannot assign network on OVN to VM (powered on or off doesn't change).
> > When I add//edit a vnic, they are not on the possible choices
> > Environment composed by three hosts and one engine (external on vSphere).
> > The mgmt network during time has been configured on network named
> ovirtmgmntZ2Z3
> > On engine it seems there are 2 switches for every defined ovn network
> (ovn192 and ovn172)
> > Below some output of commands in case any inconsistency has remained and
> I can purge it.
> > Thanks in advance.
> >
>
> I'm very confused here; you mention that on engine there are 2
> switches for every ovn network, but, on your ovn-nbctl list
> logical_switch output I can clearly see the 2 logical switches where
> the OVN logical networks are stored. Who created those ?
>

I think it could be related to the situation described here (it is the same
environment, in the meantime updated also from 4.2.8 to 4.3.1) and previous
configuration not backed up at that time:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/32S5L4JKHGPHE2XIQMLRIVLOXRG4CHW3/

and some steps not done correctly by me.
After following indications, I tried to import ovn but probably I did it
wrong.


>
> Could you show us the properties of those 2 networks ? (e.g. ovn-nbctl
> list logical_switch 32367d8a-460f-4447-b35a-abe9ea5187e0 & ovn-nbctl
> list logical_switch 64c4c17f-cd67-4e29-939e-2b952495159f)
>
>
[root@ovmgr1 ~]# ovn-nbctl list logical_switch
32367d8a-460f-4447-b35a-abe9ea5187e0
_uuid   : 32367d8a-460f-4447-b35a-abe9ea5187e0
acls: []
dns_records : []
external_ids: {}
load_balancer   : []
name: "ovn192"
other_config: {subnet="192.168.10.0/24"}
ports   : [affc5570-3e5a-439c-9fdf-d75d6810e3a3,
f639d541-2118-4c24-b478-b7a586eb170c]
qos_rules   : []
[root@ovmgr1 ~]#

[root@ovmgr1 ~]# ovn-nbctl list logical_switch
64c4c17f-cd67-4e29-939e-2b952495159f
_uuid   : 64c4c17f-cd67-4e29-939e-2b952495159f
acls: []
dns_records : []
external_ids: {}
load_balancer   : []
name: "ovn172"
other_config: {subnet="172.16.10.0/24"}
ports   : [32c348d9-12e9-4bcf-a43f-69338c887cfc,
3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69]
qos_rules   : []
[root@ovmgr1 ~]#



>
> @Gianluca Cecchi , I notice that one of your duplicate networks -
> 'ovn192'  - has no ports attached. That makes it the perfect candidate
> to be deleted, and see if it becomes 'listable' on engine. That would
> help rule out the 'duplicate name' theory.
>

 I can try. Can you give me the command to be run?
It is a test oVirt so It would be not a big problem in case of failures in
this respect.


> At the moment, I can't think of a better alternative. Let's see if
> Marcin comes up with a better test / idea / alternative.
>
> Also, please let us know the version of the ovirt-provider-ovn,
> openvswitch-ovn-central, and openvswitch-ovn-host.
>

On engine:
[root@ovmgr1 ~]# rpm -q ovirt-provider-ovn openvswitch-ovn-central
openvswitch-ovn-host
ovirt-provider-ovn-1.2.20-1.el7.noarch
openvswitch-ovn-central-2.10.1-3.el7.x86_64
package openvswitch-ovn-host is not installed
[root@ovmgr1 ~]#

On the 3 hosts I only have this package installed:
openvswitch-ovn-host-2.10.1-3.el7.x86_64

 Thanks
Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZEWQTJNFISBYAMHWAFUNMXD76WYDSYCX/

[ovirt-users] Re: self-hosted ovirt-engine down

[siovelrm]

Hi, thanks for your answers. Here are the logs of vdsm.log. Please help!!!

2019-03-18 10:12:00,172-0400 INFO  (jsonrpc/4) [jsonrpc.JsonRpcServer] RPC call 
Host.ping2 succeeded in 0.00 seconds (__init__:573)
2019-03-18 10:12:00,175-0400 INFO  (jsonrpc/7) [api.host] START 
getCapabilities() from=::1,47126 (api:46)
2019-03-18 10:12:00,472-0400 INFO  (Reactor thread) 
[ProtocolDetector.AcceptorImpl] Accepted connection from ::1:51344 
(protocoldetector:61)
2019-03-18 10:12:00,479-0400 INFO  (Reactor thread) [ProtocolDetector.Detector] 
Detected protocol stomp from ::1:51344 (protocoldetector:125)
2019-03-18 10:12:00,479-0400 INFO  (Reactor thread) [Broker.StompAdapter] 
Processing CONNECT request (stompreactor:103)
2019-03-18 10:12:00,481-0400 INFO  (JsonRpc (StompReactor)) 
[Broker.StompAdapter] Subscribe command received (stompreactor:132)
2019-03-18 10:12:00,485-0400 INFO  (jsonrpc/7) [root] 
/usr/libexec/vdsm/hooks/after_get_caps/50_openstacknet: rc=0 err= (hooks:110)
2019-03-18 10:12:00,521-0400 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call 
Host.ping2 succeeded in 0.00 seconds (__init__:573)
2019-03-18 10:12:00,534-0400 INFO  (jsonrpc/2) [api.virt] START getStats() 
from=::1,51344, vmId=0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 (api:46)
2019-03-18 10:12:00,535-0400 INFO  (jsonrpc/2) [api.virt] FINISH getStats 
return={'status': {'message': 'Done', 'code': 0}, 'statsList': [{'status': 
'Down', 'exitMessage': "'NoneType' object has no attribute '__getitem__'", 
'statusTime': '4301155670', 'vmId': '0c3e1c08-3928-47f1-96a8-c6a8d0dc3241', 
'exitReason': 1, 'exitCode': 1}]} from=::1,51344, 
vmId=0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 (api:52)
2019-03-18 10:12:00,535-0400 INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call 
VM.getStats succeeded in 0.00 seconds (__init__:573)
2019-03-18 10:12:00,657-0400 INFO  (jsonrpc/7) [root] 
/usr/libexec/vdsm/hooks/after_get_caps/openstacknet_utils.py: rc=0 err= 
(hooks:110)
2019-03-18 10:12:00,703-0400 INFO  (Reactor thread) 
[ProtocolDetector.AcceptorImpl] Accepted connection from ::1:51346 
(protocoldetector:61)
2019-03-18 10:12:00,709-0400 INFO  (Reactor thread) [ProtocolDetector.Detector] 
Detected protocol stomp from ::1:51346 (protocoldetector:125)
2019-03-18 10:12:00,709-0400 INFO  (Reactor thread) [Broker.StompAdapter] 
Processing CONNECT request (stompreactor:103)
2019-03-18 10:12:00,710-0400 INFO  (JsonRpc (StompReactor)) 
[Broker.StompAdapter] Subscribe command received (stompreactor:132)
2019-03-18 10:12:00,751-0400 INFO  (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call 
Host.ping2 succeeded in 0.00 seconds (__init__:573)
2019-03-18 10:12:00,757-0400 INFO  (jsonrpc/3) [api.virt] START 
destroy(gracefulAttempts=1) from=::1,51346, 
vmId=0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 (api:46)
2019-03-18 10:12:00,758-0400 INFO  (jsonrpc/3) [virt.vm] 
(vmId='0c3e1c08-3928-47f1-96a8-c6a8d0dc3241') Release VM resources (vm:5283)
2019-03-18 10:12:00,758-0400 WARN  (jsonrpc/3) [virt.vm] 
(vmId='0c3e1c08-3928-47f1-96a8-c6a8d0dc3241') trying to set state to Powering 
down when already Down (vm:612)
2019-03-18 10:12:00,758-0400 INFO  (jsonrpc/3) [virt.vm] 
(vmId='0c3e1c08-3928-47f1-96a8-c6a8d0dc3241') Stopping connection 
(guestagent:442)
2019-03-18 10:12:00,758-0400 INFO  (jsonrpc/3) [vdsm.api] START 
teardownImage(sdUUID='89fcd80a-0840-4877-8abb-3a4c0432f36e', 
spUUID='----', 
imgUUID='5f6b263c-3ce8-4964-ac7c-ea47c49242e9', volUUID=None) from=::1,51346, 
task_id=6235caf7-9318-4b7b-bf98-4c3b2304ac4a (api:46)
2019-03-18 10:12:00,759-0400 INFO  (jsonrpc/3) [storage.StorageDomain] Removing 
image rundir link 
u'/var/run/vdsm/storage/89fcd80a-0840-4877-8abb-3a4c0432f36e/5f6b263c-3ce8-4964-ac7c-ea47c49242e9'
 (fileSD:600)
2019-03-18 10:12:00,759-0400 INFO  (jsonrpc/3) [vdsm.api] FINISH teardownImage 
return=None from=::1,51346, task_id=6235caf7-9318-4b7b-bf98-4c3b2304ac4a 
(api:52)
2019-03-18 10:12:00,759-0400 INFO  (jsonrpc/3) [virt.vm] 
(vmId='0c3e1c08-3928-47f1-96a8-c6a8d0dc3241') Stopping connection 
(guestagent:442)
2019-03-18 10:12:00,759-0400 WARN  (jsonrpc/3) [root] File: 
/var/lib/libvirt/qemu/channels/0c3e1c08-3928-47f1-96a8-c6a8d0dc3241.ovirt-guest-agent.0
 already removed (fileutils:51)
2019-03-18 10:12:00,760-0400 WARN  (jsonrpc/3) [root] Attempting to remove a 
non existing network: ovirtmgmt/0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 
(libvirtnetwork:196)
2019-03-18 10:12:00,760-0400 WARN  (jsonrpc/3) [root] Attempting to remove a 
non existing net user: ovirtmgmt/0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 
(libvirtnetwork:203)
2019-03-18 10:12:00,761-0400 WARN  (jsonrpc/3) [root] Attempting to remove a 
non existing network: ovirtmgmt/0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 
(libvirtnetwork:196)
2019-03-18 10:12:00,761-0400 WARN  (jsonrpc/3) [root] Attempting to remove a 
non existing net user: ovirtmgmt/0c3e1c08-3928-47f1-96a8-c6a8d0dc3241 
(libvirtnetwork:203)
2019-03-18 10:12:00,762-0400 WARN  (jsonrpc/3) [root] File: 

[ovirt-users] oVirt 4.3.2 RC - ISCSI LUN

[a . e . pool]

I have deployed the latest oVirt 4.3.2 host and the hosted engine without 
problems, until you have to select the storage. I configured a brand new 
FReenAS 11 with ISCSI on three 1TB HDDs, the oVirt engine sees the iscsi target 
but when trying to select the LUN it shows that the LUN is already in use. 
Anyone come across this issue?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/J7RBB5FPFCGQA4KLJ3P7AZ2MWLX6Y7GK/

[ovirt-users] Re: Cancel storage migration task?

[Benny Zlotnik]

To be honest I am not sure if this version is safe for this kind of thing,
we had a serious bug around this[1]
and it was fixed in 4.2, I am not sure it applies to your case as well, as
there are multiple factors in play, so best test it first on some other disk

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1574346

On Mon, Mar 18, 2019 at 2:51 PM Alan G  wrote:

> It's cold migration on 4.1.9.
>
> So I just kill this process?
>
> vdsm 12356 26726 21 12:01 ?00:10:24 /usr/bin/qemu-img convert
> -p -t none -T none -f raw
> /rhev/data-center/mnt/blockSD/f8ab4c37-634b-4c01-a816-40d8eb5d0d3e/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d
> -O raw
> /rhev/data-center/mnt/blockSD/3b308f7f-f5bd-4b1e-9fea-6f91959e2dce/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d
>
>
>
>
>  On Mon, 18 Mar 2019 12:36:13 + *Benny Zlotnik
> >* wrote 
>
> is this live or cold migration?
> which version?
>
> currently the best way (and probably the only one we have) is to kill the
> qemu-img convert process (if you are doing cold migration), unless there is
> a bug in your version, it should rollback properly
>
> On Mon, Mar 18, 2019 at 2:10 PM Alan G  wrote:
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/67XEN6AZGHRG576TOCUSA2V5HVJQ655Q/
>
>
> Hi,
>
> I accidentally triggered a storage migration for a large vdisk that will
> take some hours to complete. Is there a way to cleanly cancel the task,
> such that the vdisk will remain on the original domain?
>
> Thanks,
>
> Alan
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/R22NPYDFN5PMNW3NCXCXIOPFWWBSMDA4/
>
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/P5UZPJFLC5JXBVHWOKD4PIGEWSFYJFX6/

[ovirt-users] Re: Cancel storage migration task?

[Alan G]

I let it run to completion in the end. We're upgrading to 4.2 in a few weeks, 
so I won't burn time testing it on 4.1.






 On Mon, 18 Mar 2019 17:28:09 + Benny Zlotnik 
 wrote 



To be honest I am not sure if this version is safe for this kind of thing, we 
had a serious bug around this[1]

and it was fixed in 4.2, I am not sure it applies to your case as well, as 
there are multiple factors in play, so best test it first on some other disk



[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1574346





On Mon, Mar 18, 2019 at 2:51 PM Alan G  wrote:







It's cold migration on 4.1.9.



So I just kill this process?



vdsm 12356 26726 21 12:01 ?    00:10:24 /usr/bin/qemu-img convert -p -t 
none -T none -f raw 
/rhev/data-center/mnt/blockSD/f8ab4c37-634b-4c01-a816-40d8eb5d0d3e/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d
 -O raw 
/rhev/data-center/mnt/blockSD/3b308f7f-f5bd-4b1e-9fea-6f91959e2dce/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d









 On Mon, 18 Mar 2019 12:36:13 + Benny Zlotnik 
 wrote 



is this live or cold migration? 

which version?



currently the best way (and probably the only one we have) is to kill the 
qemu-img convert process (if you are doing cold migration), unless there is a 
bug in your version, it should rollback properly




On Mon, Mar 18, 2019 at 2:10 PM Alan G  wrote:




___

Users mailing list -- mailto:users@ovirt.org

To unsubscribe send an email to mailto:users-le...@ovirt.org

Privacy Statement: https://www.ovirt.org/site/privacy-policy/

oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/

List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/67XEN6AZGHRG576TOCUSA2V5HVJQ655Q/




Hi,



I accidentally triggered a storage migration for a large vdisk that will take 
some hours to complete. Is there a way to cleanly cancel the task, such that 
the vdisk will remain on the original domain?



Thanks,



Alan





___

Users mailing list -- mailto:users@ovirt.org

To unsubscribe send an email to mailto:users-le...@ovirt.org

Privacy Statement: https://www.ovirt.org/site/privacy-policy/

oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/

List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R22NPYDFN5PMNW3NCXCXIOPFWWBSMDA4/___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PB7BBLYFT3AJ2GD25L5RD2DHNE72IQKE/

[ovirt-users] Re: oVirt 4.3 - create windows2012 failed due to ovirt-imageio-proxy

[Edward Berger]

That is completely normal if you didn't download and install the CA
certificate from your ovirt engine GUI.
There's a download link for it on the page before you login?

On Mon, Mar 18, 2019 at 5:01 PM  wrote:

> Hi,
>
> I tried to create windows2012 vm on nfs data domain, but the disk was
> locked.
> Found the error message as following:
>
> Connection to ovirt-imageio-proxy service has failed. Make sure the
> service is installed, configured, and ovirt-engine certificate is
> registered as a valid CA in the browser.
>
> Is this known issue?
>
> Thanks,
> Jingjie
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/QBZQG553L7WYVHQFDRWUAYKYZ2HLSJKW/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3NYKJQ34KV4Q26735GUCDSN6GGLNZEZZ/

[ovirt-users] Re: Forum available

[Alexey Nikolaev]

I had the some bug with email web-client.

No my messages in the thread 
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/OU3FKLEPH7AHT2LO2IYZ47RJHRA72C3Z/


Testing now from thunderbird client.


09.02.2019 18:47, Greg Sheremeta пишет:


On Sat, Feb 9, 2019 at 8:54 AM Strahil > wrote:


I thought that hypperkitty is just a web page to search the
mailing lists...


You can reply right in there, too -- so it's pretty much a forum -- 
assuming the threading works.


Sadly several threads were broken and it doesn't seem reliable.
In contrast , CentOS forum is much more usable.


Sadly, it is quite broken at the moment. We have a ticket open, and 
there is an upstream bug filed with the mailman team. We're now 
waiting on our ovirt infra person (Duck) to reply to run some 
debugging commands and get back to them.


Greg


Best Regards,
Strahil Nikolov



--

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.com  IRC: gshereme




___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/S3OU6WL5W7G4BK6TXRPWX7NNA56Y5NUX/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/W2636VHBKUMOLNQMBU7RVMQTKTYYACME/

[ovirt-users] Re: Hosted Engine I/O scheduler

[Strahil]

Hi Darrel,

Still, based on my experience we shouldn't queue our I/O in the VM, just to do 
the same in the Host.

I'm still considering if I should keep deadline  in my hosts or to switch to 
'cfq'.
After all, I'm using Hyper-converged oVirt and this needs testing.
What I/O scheduler  are  you using on the  host?

Best Regards,
Strahil NikolovOn Mar 18, 2019 19:15, Darrell Budic  
wrote:
>
> Checked this on mine, see the same thing. Switching the engine to noop 
> definitely feels more responsive.
>
> I checked on some VMs as well, it looks like virtio drives (vda, vdb….) get 
> mq-deadline by default, but virtscsi gets noop. I used to think the tuned 
> profile for virtual-guest would set noop, but apparently not…
>
>   -Darrell
>
>> On Mar 18, 2019, at 1:58 AM, Strahil Nikolov  wrote:
>>
>> Hi All,
>>
>> I have changed my I/O scheduler to none and here are the results so far:
>>
>> Before (mq-deadline):
>> Adding a disk to VM (initial creation) START: 2019-03-17 16:34:46.709
>> Adding a disk to VM (initial creation) COMPLETED: 2019-03-17 16:45:17.996
>>
>> After (none):
>> Adding a disk to VM (initial creation) START: 2019-03-18 08:52:02.xxx
>> Adding a disk to VM (initial creation) COMPLETED: 2019-03-18 08:52:20.xxx
>>
>> Of course the results are inconclusive, as I have tested only once - but I 
>> feel the engine more responsive.
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> В неделя, 17 март 2019 г., 18:30:23 ч. Гринуич+2, Strahil 
>>  написа:
>>
>>
>> Dear All,
>>
>> I have just noticed that my Hosted Engine has  a strange I/O scheduler:
>>
>> Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43
>> [root@engine ~]# cat /sys/block/vda/queue/scheduler
>> [mq-deadline] kyber none
>> [root@engine ~]#
>>
>> Based on my experience  anything than noop/none  is useless and performance 
>> degrading  for a VM.
>>
>> Is there any reason that we have this scheduler ?
>> It is quite pointless  to process (and delay) the I/O in the VM and then 
>> process (and again delay)  on Host Level .
>>
>> If there is no reason to keep the deadline, I will open a bug about it.
>>
>> Best Regards,
>> Strahil Nikolov
>>
>> Dear All,
>>
>> I have just noticed that my Hosted Engine has  a strange I/O scheduler:
>>
>> Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43
>> [root@engine ~]# cat /sys/block/vda/queue/scheduler
>> [mq-deadline] kyber none
>> [root@engine ~]#
>>
>> Based on my experience  anything than noop/none  is useless and performance 
>> degrading  for a VM.
>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KMFTTEVXFUBCTJUWQZIDTBG7ZXPCCGJG/

[ovirt-users] Re: vender_id syntax UserDefinedVMProperties

[Darin Schmidt]

Seems that the system has to be running with bios Q35 UEFI. Standard bios
does not work. System is operational now.

On Mon, Mar 18, 2019, 6:30 AM Darin Schmidt  wrote:

> Still no luck getting the gtx 1080 to enable inside the VM. I see the code
> is being generated in the xml with the hook. But I still get error code 43.
> Someone mentioned doing it with eufi bios and that worked for them. So when
> I get back from work today, perhaps ill give that a try.
>
> On Mon, Mar 18, 2019, 6:10 AM Darin Schmidt 
> wrote:
>
>> I have gotten the system to see the card, its in device manager. The
>> problem seems to be that I cannot use it in the VM because from what I have
>> been finding out is that it gets and error code 43. Nvidia drivers disable
>> the card if it detects that its being used in a VM. I have found some code
>> to use to hook it into the xml before_vm_starts.
>>
>> 99_mask_kvm
>> #!/usr/bin/python2
>>
>> import hooking
>> domxml = hooking.read_domxml()
>>
>> hyperv = domxml.getElementsByTagName('hyperv')[0]
>> smm = domxml.createElement('vendor_id')
>> smm.setAttribute('state', 'on')
>> smm.setAttribute('value', '1234567890ab')
>> hyperv.appendChild(smm)
>>
>> features = domxml.getElementsByTagName('features')[0]
>> kvm = domxml.createElement('kvm')
>> hidden = domxml.createElement('hidden')
>> hidden.setAttribute('state', 'on')
>> kvm.appendChild(hidden)
>> features.appendChild(kvm)
>>
>> hooking.write_domxml(domxml)
>>
>>
>> I am currently reinstalling the drivers to see if this helps.
>>
>> kvm off and vender_id is now in the xml code that get generated when the
>> VM is started. Im going off of examples Im finding online. Perhaps I just
>> need to add the 10de to it instead of some generic # others are using.
>>
>> On Mon, Mar 18, 2019 at 6:02 AM Nisim Simsolo 
>> wrote:
>>
>>> Hi
>>>
>>> Vendor ID of Nvidia is usually 10de.
>>> You can locate 'vendor ID:product ID' by running lspci command, for
>>> example:
>>> [root@intel-vfio ~]# lspci -Dnn | grep -i nvidia
>>> :03:00.0 VGA compatible controller [0300]: NVIDIA Corporation
>>> GK104GL [Quadro K4200] [10de:11b4] (rev a1)
>>> :03:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio
>>> Controller [10de:0e0a] (rev a1)
>>> [root@intel-vfio ~]#
>>>
>>> In this example, the vendor ID of VGA controller is 10de and the product
>>> ID is 11b4
>>>
>>> Please bare in mind that you need to enable IOMMU, add pci-stub (prevent
>>> the host driver for using GPU device) and disable the default nouveau
>>> driver on the host Kernel command line.
>>> to do that:
>>> 1. Edit host /etc/sysconfig/grub and add the next to GRUB_CMDLINE_LINUX:
>>>
>>>- intel_iommu=on or amd_iommu=on
>>>- pci-stub.ids=10de:11b4,10de:0e0a
>>>- rdblacklist=nouveau
>>>
>>> 2. Regenerate the boot loader configuration using grub2-mkconfig command:
>>> # grub2-mkconfig -o /etc/grub2.cfg
>>> 3. Reboot the host.
>>> 4. Verify configuration:
>>> [root@intel-vfio ~]# cat /proc/cmdline
>>> BOOT_IMAGE=/vmlinuz-3.10.0-957.5.1.el7.x86_64
>>> root=/dev/mapper/vg0-lv_root ro crashkernel=auto rd.lvm.lv=vg0/lv_root
>>> rd.lvm.lv=vg0/lv_swap rhgb quiet pci-stub.ids=10de:11b4,10de:0e0a
>>> intel_iommu=on rdblacklist=nouveau LANG=en_US.UTF-8
>>> [root@intel-vfio ~]#
>>>
>>>
>>> After running this, you should be able to passthrough GPU to VM.
>>>
>>> BTW, why are you using engine-config and not doing it from oVirt UI or
>>> using virsh edit command?
>>>
>>> Thanks
>>>
>>>
>>> On Mon, Mar 18, 2019 at 1:52 AM Darin Schmidt 
>>> wrote:
>>>
 Hello all, im trying to figure out how to configure the custom
 properties to enable my NVIDIA card to work in the VM. Its my understanding
 that the drives dont work because it detects its in a VM..

 Im trying to do something like this:

 engine-config -s
 UserDefinedVMProperties="kvmhidden=^(true|false)$;{type=vendor_id;state={^(on|off)$;value=^([0-9])$}}"


 But thats clearly not working. If I do this:

 engine-config -s
 UserDefinedVMProperties="kvmhidden=^(true|false)$;vendor_id={state=^(on|off)$;value=^([0-9])$}"


 It works but, the options are messed up. Im not sure how to find out
 the correct syntax to get this to work. Would appreciate any advice.

>>>
>>>
>>> --
>>> Nisim Simsolo
>>> QE -Testing Engineer
>>> IRC: nsimsolo
>>> int phone - 8272305
>>> mobile - 054-4779934
>>>
>>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4UBAZ6DATBEYEISWT2N3LKXWESWA77NH/

[ovirt-users] Re: Hosted Engine I/O scheduler

[Darrell Budic]

I agree, been checking some of my more disk intensive VMs this morning, 
switching them to noop definitely improved responsiveness. All the virtio ones 
I’ve found were using deadline (with RHEL/Centos guests), but some of the 
virt-scsi were using deadline and some were noop, so I’m not sure of a 
definitive answer on that level yet. 

For the hosts, it depends on what your backend is running. With a separate 
storage server on my main cluster, it doesn’t matter what the hosts set for me. 
You mentioned you run hyper converged, so I’d say it depends on what your disks 
are. If you’re using SSDs, go none/noop as they don’t benefit from the queuing. 
If they are HDDs, I’d test cfq or deadline and see which gave better latency 
and throughput to your vms. I’d guess you’ll find deadline to offer better 
performance, but cfq to share better amongst multiple VMs. Unless you use ZFS 
underneath, then go noop and let ZFS take care of it.

> On Mar 18, 2019, at 2:05 PM, Strahil  wrote:
> 
> Hi Darrel,
> 
> Still, based on my experience we shouldn't queue our I/O in the VM, just to 
> do the same in the Host.
> 
> I'm still considering if I should keep deadline  in my hosts or to switch to 
> 'cfq'.
> After all, I'm using Hyper-converged oVirt and this needs testing.
> What I/O scheduler  are  you using on the  host?
> 
> Best Regards,
> Strahil Nikolov
> 
> On Mar 18, 2019 19:15, Darrell Budic  wrote:
> Checked this on mine, see the same thing. Switching the engine to noop 
> definitely feels more responsive.
> 
> I checked on some VMs as well, it looks like virtio drives (vda, vdb….) get 
> mq-deadline by default, but virtscsi gets noop. I used to think the tuned 
> profile for virtual-guest would set noop, but apparently not…
> 
>   -Darrell
> 
> On Mar 18, 2019, at 1:58 AM, Strahil Nikolov  > wrote:
> 
> Hi All,
> 
> I have changed my I/O scheduler to none and here are the results so far:
> 
> Before (mq-deadline):
> Adding a disk to VM (initial creation) START: 2019-03-17 16:34:46.709
> Adding a disk to VM (initial creation) COMPLETED: 2019-03-17 16:45:17.996
> 
> After (none):
> Adding a disk to VM (initial creation) START: 2019-03-18 08:52:02.xxx
> Adding a disk to VM (initial creation) COMPLETED: 2019-03-18 08:52:20.xxx
> 
> Of course the results are inconclusive, as I have tested only once - but I 
> feel the engine more responsive.
> 
> Best Regards,
> Strahil Nikolov
> 
> В неделя, 17 март 2019 г., 18:30:23 ч. Гринуич+2, Strahil 
> mailto:hunter86...@yahoo.com>> написа:
> 
> 
> Dear All,
> 
> I have just noticed that my Hosted Engine has  a strange I/O scheduler:
> 
> Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43 
> [root@engine ~]# cat /sys/block/vda/queue/scheduler
> [mq-deadline] kyber none
> [root@engine ~]#
> 
> Based on my experience  anything than noop/none  is useless and performance 
> degrading  for a VM.
> 
> Is there any reason that we have this scheduler ?
> It is quite pointless  to process (and delay) the I/O in the VM and then 
> process (and again delay)  on Host Level .
> 
> If there is no reason to keep the deadline, I will open a bug about it.
> 
> Best Regards,
> Strahil Nikolov
> 
> Dear All,
> 
> I have just noticed that my Hosted Engine has  a strange I/O scheduler:
> 
> Last login: Sun Mar 17 18:14:26 2019 from 192.168.1.43 
> [root@engine  ~]# cat /sys/block/vda/queue/scheduler
> [mq-deadline] kyber none
> [root@engine  ~]#
> 
> Based on my experience  anything than noop/none  is useless and performance 
> degrading  for a VM.
> 
> 

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MMTH6225GKYQEZ26BXDBTB52LNWMWVBH/

[ovirt-users] oVirt 4.3 - create windows2012 failed due to ovirt-imageio-proxy

[jingjie . jiang]

Hi,

I tried to create windows2012 vm on nfs data domain, but the disk was locked.
Found the error message as following:

Connection to ovirt-imageio-proxy service has failed. Make sure the service is 
installed, configured, and ovirt-engine certificate is registered as a valid CA 
in the browser.

Is this known issue?

Thanks,
Jingjie
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QBZQG553L7WYVHQFDRWUAYKYZ2HLSJKW/

[ovirt-users] Re: Host affinity hard rule doesn't work

[zodaoko]

Thank you, Paul !
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UF34V33J74D3SROBSR4G6FDBRS5KDUUT/

[ovirt-users] Where to find the hooks' print

[zodaoko]

Hi there,
I created a before_set_num_of_cpus hook:

# more /usr/libexec/vdsm/hooks/before_set_num_of_cpus/before.py
#!/usr/bin/python
import os
import sys
if os.environ.has_key('never_existed'):
sys.stderr.write('cantsetcpu: before_cpu_set: cannot set cpu.\n')
sys.exit(2)
else:
sys.stdout.write('hook ok.\n')
sys.exit(0)


But I cannot find the message "hook ok" in engine.log or vdsm.log, where to 
find it?  Thank you very much.

Thank you,
-Zhen
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WENN6E2USNISFQIZ7O34IURMKMPAX6ED/

[ovirt-users] Re: Migrate HE beetwen hosts failed.

[kiv]

All my VM's, including VM with HE:

Guest CPU Type: Intel Westmere Family

All VM migrating, excluding VM with HE.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UJNYD54C4727TXF6MN26LADGEETIYMQ4/

[ovirt-users] mcafee and norton software

[jagdish2pcexpert]

Activate McAfee using McAfee Activation Key Code. Double-click on McAfee icon 
and launch the software on the screen. On the home page, click on the activate 
option, this will connect you to the official McAfee page.

http://www.mcafeecomactivate.me/
http://how-to-activate.me/
http://www.httpnortoncomsetup.com/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QBU6MKA3DEFVJ2XR2FRLYISYJOTNPUBR/

[ovirt-users] Re: Migrate HE beetwen hosts failed.

[Strahil Nikolov]

 Dear Kiv,
It seems that you have hosts with different CPus in the same cluster - which 
shouldn't happen.In your case the HE is on host with Intel SandyBridge IBRS 
SSBD Family , but you have no other host with that CPU.
Can you power off and edit the CPU of this VM to match the rest of the Host 
CPUs ?usually the older the CPU type on the VM - the higher compatibility it 
has , but performance drops - so keep that in mind.
Best Regards,Strahil Nikolov


В понеделник, 18 март 2019 г., 8:36:01 ч. Гринуич+2, k...@intercom.pro 
 написа:  
 
 Hi all.

I have oVirt 4.3.1 and 3 node hosts.
All VM migrate beetwen all hosts successfully.
VM with HE - does not migrate.

vdsm.log:

libvirtError: operation failed: guest CPU doesn't match specification: missing 
features: xsave,avx,xsaveopt

Nodes:
1. Intel Westmere IBRS SSBD Family
2. Intel Westmere IBRS SSBD Family
3. Intel SandyBridge IBRS SSBD Family <- HE now here

Cluster CPU Type: Intel Westmere Family

Info from VM with HE:

Guest CPU Type: Intel Westmere Family

Does anyone know what needs to be done to make migration work?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJTJKPF54G5JENPDRTTHQPUG3RAMGQ2C/
  ___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7NPTNTUBX76EUQVOXBEG4Z56FSFUZ4JC/

[ovirt-users] Re: vdsm should decouple with managed glusterfs services

[Sahina Bose]

On Sun, Mar 17, 2019 at 12:56 PM  wrote:
>
> Hi, I had experience two time of 3-node hyper-converged 4.2.8 ovirt cluster 
> total outage due to vdsm reactivate the unresponsive node, and cause the 
> multiple glusterfs daemon restart. As a result, all VM was paused and some of 
> disk image was corrupted.
>
> At the very beginning, one of the ovirt node was overloaded due to high 
> memory and CPU, the hosted-engine have trouble to collect status from vdsm 
> and mark it as unresponsive and it start migrate the workload to healthy 
> node. However, when it start migrate, second ovirt node being unresponsive 
> where vdsm try reactivate the 1st unresponsive node and restart it's 
> glusterd. So the gluster domain was acquiring the quorum and waiting for 
> timeout.
>
> If 1st node reactivation is success and every other node can survive the 
> timeout, it will be an idea case. Unfortunately, the second node cannot pick 
> up the VM being migrated due to gluster I/O timeout, so second node at that 
> moment was marked as unresponsive, and so on... vdsm is restarting the 
> glusterd on the second node which cause disaster. All node are racing on 
> gluster volume self-healing, and i can't mark the cluster as maintenance mode 
> as well. What I can do is try to resume the paused VM via virsh and issue 
> shutdown for each domain, also hard shutdown for un-resumable VM.
>
> After number of VM shutdown and wait the gluster healing completed,  the 
> cluster state back to normal, and I try to start the VM being manually 
> stopped, most of them can be started normally, but number of VM was crashed 
> or un-startable, instantly I  found the image files of un-startable VM was 
> owned by root(can't explain why), and can be restarted after chmod.  Two of 
> them still cannot start with  "bad volume specification" error. One of them 
> can start to boot loader, but the LVM metadata were lost.
>
> The impact was huge when vdsm restart the glusterd without human invention.

Is this even with the fencing policies set for ensuring gluster quorum
is not lost?

There are 2 policies that you need to enable at the cluster level -
Skip fencing if Gluster bricks are UP
Skip fencing if Gluster quorum not met


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NIPHD7COR5ZBVQROOUU6R4Q45SDFAJ5K/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WL3F7PLMAGUBX6VFYKFRJE6YHWAQHFHU/

[ovirt-users] Re: vender_id syntax UserDefinedVMProperties

[Nisim Simsolo]

Hi

Vendor ID of Nvidia is usually 10de.
You can locate 'vendor ID:product ID' by running lspci command, for example:
[root@intel-vfio ~]# lspci -Dnn | grep -i nvidia
:03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL
[Quadro K4200] [10de:11b4] (rev a1)
:03:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio
Controller [10de:0e0a] (rev a1)
[root@intel-vfio ~]#

In this example, the vendor ID of VGA controller is 10de and the product ID
is 11b4

Please bare in mind that you need to enable IOMMU, add pci-stub (prevent
the host driver for using GPU device) and disable the default nouveau
driver on the host Kernel command line.
to do that:
1. Edit host /etc/sysconfig/grub and add the next to GRUB_CMDLINE_LINUX:

   - intel_iommu=on or amd_iommu=on
   - pci-stub.ids=10de:11b4,10de:0e0a
   - rdblacklist=nouveau

2. Regenerate the boot loader configuration using grub2-mkconfig command:
# grub2-mkconfig -o /etc/grub2.cfg
3. Reboot the host.
4. Verify configuration:
[root@intel-vfio ~]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-957.5.1.el7.x86_64 root=/dev/mapper/vg0-lv_root
ro crashkernel=auto rd.lvm.lv=vg0/lv_root rd.lvm.lv=vg0/lv_swap rhgb quiet
pci-stub.ids=10de:11b4,10de:0e0a intel_iommu=on rdblacklist=nouveau
LANG=en_US.UTF-8
[root@intel-vfio ~]#


After running this, you should be able to passthrough GPU to VM.

BTW, why are you using engine-config and not doing it from oVirt UI or
using virsh edit command?

Thanks


On Mon, Mar 18, 2019 at 1:52 AM Darin Schmidt 
wrote:

> Hello all, im trying to figure out how to configure the custom properties
> to enable my NVIDIA card to work in the VM. Its my understanding that the
> drives dont work because it detects its in a VM..
>
> Im trying to do something like this:
>
> engine-config -s
> UserDefinedVMProperties="kvmhidden=^(true|false)$;{type=vendor_id;state={^(on|off)$;value=^([0-9])$}}"
>
>
> But thats clearly not working. If I do this:
>
> engine-config -s
> UserDefinedVMProperties="kvmhidden=^(true|false)$;vendor_id={state=^(on|off)$;value=^([0-9])$}"
>
>
> It works but, the options are messed up. Im not sure how to find out the
> correct syntax to get this to work. Would appreciate any advice.
>


-- 
Nisim Simsolo
QE -Testing Engineer
IRC: nsimsolo
int phone - 8272305
mobile - 054-4779934
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3VN26COJRRIF7CGKY6DU5CURMQOK6X2Y/

[ovirt-users] oVirt 2019 Survey

[Sandro Bonazzola]

As we continue to develop oVirt 4.3 and future releases, the Development
and Integration teams at Red Hat would value insights on how you are
deploying the oVirt environment.
Please help us to hit the mark by completing this short survey. Survey will
close on March 31th.
If you're managing multiple oVirt deployments with very different use cases
or very different deployments you can consider answering this survey
multiple times.
Please note the answers to this survey will be publicly accessible.
This survey is under oVirt Privacy Policy available at
https://www.ovirt.org/site/privacy-policy.html

The survey is available at https://goo.gl/forms/QOl5gDJdR83dzVPT2

Thanks,
-- 

SANDRO BONAZZOLA

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LEMZQBDDZ3GR2YJJJREJM5IYGL2OQGOH/

[ovirt-users] Re: Libgfapisupport messes disk image ownership

[Arsène Gschwind]

Hi ,

I'm observing the same problem using oVirt 4.3.1 .
The ownership of the VM disk changes to root:root every reboot.

rgds,
arsene

On Sat, 2019-03-16 at 00:25 +0300, Hesham Ahmed wrote:

I had reported this here:



https://bugzilla.redhat.com/show_bug.cgi?id=1687126



Has anyone else faced this with 4.3.1?

___

Users mailing list --



users@ovirt.org


To unsubscribe send an email to



users-le...@ovirt.org


Privacy Statement:



https://www.ovirt.org/site/privacy-policy/


oVirt Code of Conduct:



https://www.ovirt.org/community/about/community-guidelines/


List Archives:



https://lists.ovirt.org/archives/list/users@ovirt.org/message/VBIASF6YXLOHVKHYRSEFGSPBKH52OSYX/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/2LH3CI6LMORUSHVJJQDLPOBUWNZC5G3M/

[ovirt-users] Re: ovn-provider-network

[Miguel Duarte de Mora Barroso]

On Fri, Mar 15, 2019 at 6:11 PM Staniforth, Paul
 wrote:
>
> I've now got the second host working, the directory /etc/openvswitch/ was 
> owned by root instead of openvswitch:openvswitch

Nice to know you've got it working.

Thanks for getting back to us.

>
>
> Thanks,
>Paul S.
> To view the terms under which this email is distributed, please go to:-
> http://leedsbeckett.ac.uk/disclaimer/email/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q4CP55BRQZNOVHOMHJ32EWXECTLWUOUN/

[ovirt-users] Re: Ovirt 4.3.1 problem with HA agent

[Николаев Алексей]

Hi all! I have a very similar problem after update one of the two nodes to version 4.3.1. This node77-02 lost connection to gluster volume named DATA, but not to volume with hosted engine.  node77-02 /var/log/messages Mar 18 13:40:00 node77-02 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config.vm ERROR Failed scanning for OVF_STORE due to Command Volume.getInfo with args {'storagepoolID': '----', 'storagedomainID': '2ee71105-1810-46eb-9388-cc6caccf9fac', 'volumeID': u'224e4b80-2744-4d7f-bd9f-43eb8fe6cf11', 'imageID': u'43b75b50-cad4-411f-8f51-2e99e52f4c77'} failed:#012(code=201, message=Volume does not exist: (u'224e4b80-2744-4d7f-bd9f-43eb8fe6cf11',))Mar 18 13:40:00 node77-02 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config.vm ERROR Unable to identify the OVF_STORE volume, falling back to initial vm.conf. Please ensure you already added your first data domain for regular VMs HostedEngine VM works fine on all nodes. But node77-02 failed witherror in webUI: ConnectStoragePoolVDS failed: Cannot find master domain: u'spUUID=5a5cca91-01f8-01af-0297-025f, msdUUID=7d5de684-58ff-4fbc-905d-3048fc55b2b1' node77-02 vdsm.log 2019-03-18 13:51:46,287+0300 WARN  (jsonrpc/7) [storage.StorageServer.MountConnection] gluster server u'msk-gluster-facility.' is not in bricks ['node-msk-gluster203', 'node-msk-gluster205', 'node-msk-gluster201'], possibly mounting duplicate servers (storageServer:317)2019-03-18 13:51:46,287+0300 INFO  (jsonrpc/7) [storage.Mount] mounting msk-gluster-facility.ipt.fsin.uis:/data at /rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_data (mount:204)2019-03-18 13:51:46,474+0300 ERROR (jsonrpc/7) [storage.HSM] Could not connect to storageServer (hsm:2415)Traceback (most recent call last):  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 2412, in connectStorageServer    conObj.connect()  File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 179, in connect    six.reraise(t, v, tb)  File "/usr/lib/python2.7/site-packages/vdsm/storage/storageServer.py", line 171, in connect    self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP)  File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 207, in mount    cgroup=cgroup)  File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__    return callMethod()  File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 53, in     **kwargs)  File "", line 2, in mount  File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod    raise convert_to_error(kind, result)MountError: (1, ';Running scope as unit run-10121.scope.\nMount failed. Please check the log file for more details.\n') -- 2019-03-18 13:51:46,830+0300 ERROR (jsonrpc/4) [storage.TaskManager.Task] (Task='fe81642e-2421-4169-a08b-51467e8f01fe') Unexpected error (task:875)Traceback (most recent call last):  File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run    return fn(*args, **kargs)  File "", line 2, in connectStoragePool  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in method    ret = func(*args, **kwargs)  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 1035, in connectStoragePool    spUUID, hostID, msdUUID, masterVersion, domainsMap)  File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 1097, in _connectStoragePool    res = pool.connect(hostID, msdUUID, masterVersion)  File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 700, in connect    self.__rebuild(msdUUID=msdUUID, masterVersion=masterVersion)  File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 1274, in __rebuild    self.setMasterDomain(msdUUID, masterVersion)  File "/usr/lib/python2.7/site-packages/vdsm/storage/sp.py", line 1495, in setMasterDomain    raise se.StoragePoolMasterNotFound(self.spUUID, msdUUID)StoragePoolMasterNotFound: Cannot find master domain: u'spUUID=5a5cca91-01f8-01af-0297-025f, msdUUID=7d5de684-58ff-4fbc-905d-3048fc55b2b1' What the bestpractice to recovery this problem?15.03.2019, 13:47, "Strahil Nikolov" : On Fri, Mar 15, 2019 at 8:12 AM Strahil Nikolov  wrote:Ok, I have managed to recover again and no issues are detected this time.I guess this case is quite rare and nobody has experienced that. >Hi,>can you please explain how you fixed it? I have set again to global maintenance, defined the HostedEngine from the old xml (taken from old vdsm log) , defined the network and powered it off.Set the OVF update period to 5 min , but it took several hours until the OVF_STORE were updated. Once this happened I restarted the ovirt-ha-agent ovirt-ha-broker on both nodes.Then I powered off the HostedEngine and undefined it from ovirt1. then I set the maintenance to 'none' and the VM powered on ovirt1.In order to 

[ovirt-users] Re: vdsm should decouple with managed glusterfs services

[levin]

Hi Sahina,

My cluster did not enabled fencing, is somewhere I can disable restart policy 
from vdsm completely? So I can observe this case next time, and giving a fist 
investigation on unresponsive node.

Regards,
Levin


On 18/3/2019, 17:40, "Sahina Bose"  wrote:

On Sun, Mar 17, 2019 at 12:56 PM  wrote:
>
> Hi, I had experience two time of 3-node hyper-converged 4.2.8 ovirt 
cluster total outage due to vdsm reactivate the unresponsive node, and cause 
the multiple glusterfs daemon restart. As a result, all VM was paused and some 
of disk image was corrupted.
>
> At the very beginning, one of the ovirt node was overloaded due to high 
memory and CPU, the hosted-engine have trouble to collect status from vdsm and 
mark it as unresponsive and it start migrate the workload to healthy node. 
However, when it start migrate, second ovirt node being unresponsive where vdsm 
try reactivate the 1st unresponsive node and restart it's glusterd. So the 
gluster domain was acquiring the quorum and waiting for timeout.
>
> If 1st node reactivation is success and every other node can survive the 
timeout, it will be an idea case. Unfortunately, the second node cannot pick up 
the VM being migrated due to gluster I/O timeout, so second node at that moment 
was marked as unresponsive, and so on... vdsm is restarting the glusterd on the 
second node which cause disaster. All node are racing on gluster volume 
self-healing, and i can't mark the cluster as maintenance mode as well. What I 
can do is try to resume the paused VM via virsh and issue shutdown for each 
domain, also hard shutdown for un-resumable VM.
>
> After number of VM shutdown and wait the gluster healing completed,  the 
cluster state back to normal, and I try to start the VM being manually stopped, 
most of them can be started normally, but number of VM was crashed or 
un-startable, instantly I  found the image files of un-startable VM was owned 
by root(can't explain why), and can be restarted after chmod.  Two of them 
still cannot start with  "bad volume specification" error. One of them can 
start to boot loader, but the LVM metadata were lost.
>
> The impact was huge when vdsm restart the glusterd without human 
invention.

Is this even with the fencing policies set for ensuring gluster quorum
is not lost?

There are 2 policies that you need to enable at the cluster level -
Skip fencing if Gluster bricks are UP
Skip fencing if Gluster quorum not met


> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NIPHD7COR5ZBVQROOUU6R4Q45SDFAJ5K/


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RY6Z5IXVQYCJBSFDP7X73BOBVBBXHVTO/

[ovirt-users] Enabled Base and Update repos?

[nico . kruger]

Hi Guys,

Should Centos Base and Update repos be enabled on ovirt hosts or only the 
dependancies and ovirt repos (the ones from rpm release) 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TRMEGP6WPFJ6WKSW5TAJM6AHLI64XE43/

[ovirt-users] Re: Cancel storage migration task?

[Alan G]

It's cold migration on 4.1.9.


So I just kill this process?



vdsm 12356 26726 21 12:01 ?    00:10:24 /usr/bin/qemu-img convert -p -t 
none -T none -f raw 
/rhev/data-center/mnt/blockSD/f8ab4c37-634b-4c01-a816-40d8eb5d0d3e/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d
 -O raw 
/rhev/data-center/mnt/blockSD/3b308f7f-f5bd-4b1e-9fea-6f91959e2dce/images/6f340d21-6690-4c51-8129-7d6345e80956/6e8545c4-73ff-4b45-a19e-4e902822959d









 On Mon, 18 Mar 2019 12:36:13 + Benny Zlotnik 
 wrote 



is this live or cold migration? 

which version?



currently the best way (and probably the only one we have) is to kill the 
qemu-img convert process (if you are doing cold migration), unless there is a 
bug in your version, it should rollback properly




On Mon, Mar 18, 2019 at 2:10 PM Alan G  wrote:




___

Users mailing list -- mailto:users@ovirt.org

To unsubscribe send an email to mailto:users-le...@ovirt.org

Privacy Statement: https://www.ovirt.org/site/privacy-policy/

oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/

List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/67XEN6AZGHRG576TOCUSA2V5HVJQ655Q/




Hi,



I accidentally triggered a storage migration for a large vdisk that will take 
some hours to complete. Is there a way to cleanly cancel the task, such that 
the vdisk will remain on the original domain?



Thanks,



Alan





___

 Users mailing list -- mailto:users@ovirt.org

 To unsubscribe send an email to mailto:users-le...@ovirt.org

 Privacy Statement: https://www.ovirt.org/site/privacy-policy/

 oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/

 List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R22NPYDFN5PMNW3NCXCXIOPFWWBSMDA4/___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NX64GJXAYZD3VJAUCLPWGKOQI2BYLEWJ/

[ovirt-users] Re: Cancel storage migration task?

[Benny Zlotnik]

is this live or cold migration?
which version?

currently the best way (and probably the only one we have) is to kill the
qemu-img convert process (if you are doing cold migration), unless there is
a bug in your version, it should rollback properly

On Mon, Mar 18, 2019 at 2:10 PM Alan G  wrote:

> Hi,
>
> I accidentally triggered a storage migration for a large vdisk that will
> take some hours to complete. Is there a way to cleanly cancel the task,
> such that the vdisk will remain on the original domain?
>
> Thanks,
>
> Alan
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/R22NPYDFN5PMNW3NCXCXIOPFWWBSMDA4/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/67XEN6AZGHRG576TOCUSA2V5HVJQ655Q/

[ovirt-users] Re: vender_id syntax UserDefinedVMProperties

[Darin Schmidt]

I have gotten the system to see the card, its in device manager. The
problem seems to be that I cannot use it in the VM because from what I have
been finding out is that it gets and error code 43. Nvidia drivers disable
the card if it detects that its being used in a VM. I have found some code
to use to hook it into the xml before_vm_starts.

99_mask_kvm
#!/usr/bin/python2

import hooking
domxml = hooking.read_domxml()

hyperv = domxml.getElementsByTagName('hyperv')[0]
smm = domxml.createElement('vendor_id')
smm.setAttribute('state', 'on')
smm.setAttribute('value', '1234567890ab')
hyperv.appendChild(smm)

features = domxml.getElementsByTagName('features')[0]
kvm = domxml.createElement('kvm')
hidden = domxml.createElement('hidden')
hidden.setAttribute('state', 'on')
kvm.appendChild(hidden)
features.appendChild(kvm)

hooking.write_domxml(domxml)


I am currently reinstalling the drivers to see if this helps.

kvm off and vender_id is now in the xml code that get generated when the VM
is started. Im going off of examples Im finding online. Perhaps I just need
to add the 10de to it instead of some generic # others are using.

On Mon, Mar 18, 2019 at 6:02 AM Nisim Simsolo  wrote:

> Hi
>
> Vendor ID of Nvidia is usually 10de.
> You can locate 'vendor ID:product ID' by running lspci command, for
> example:
> [root@intel-vfio ~]# lspci -Dnn | grep -i nvidia
> :03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL
> [Quadro K4200] [10de:11b4] (rev a1)
> :03:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio
> Controller [10de:0e0a] (rev a1)
> [root@intel-vfio ~]#
>
> In this example, the vendor ID of VGA controller is 10de and the product
> ID is 11b4
>
> Please bare in mind that you need to enable IOMMU, add pci-stub (prevent
> the host driver for using GPU device) and disable the default nouveau
> driver on the host Kernel command line.
> to do that:
> 1. Edit host /etc/sysconfig/grub and add the next to GRUB_CMDLINE_LINUX:
>
>- intel_iommu=on or amd_iommu=on
>- pci-stub.ids=10de:11b4,10de:0e0a
>- rdblacklist=nouveau
>
> 2. Regenerate the boot loader configuration using grub2-mkconfig command:
> # grub2-mkconfig -o /etc/grub2.cfg
> 3. Reboot the host.
> 4. Verify configuration:
> [root@intel-vfio ~]# cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-3.10.0-957.5.1.el7.x86_64 root=/dev/mapper/vg0-lv_root
> ro crashkernel=auto rd.lvm.lv=vg0/lv_root rd.lvm.lv=vg0/lv_swap rhgb
> quiet pci-stub.ids=10de:11b4,10de:0e0a intel_iommu=on rdblacklist=nouveau
> LANG=en_US.UTF-8
> [root@intel-vfio ~]#
>
>
> After running this, you should be able to passthrough GPU to VM.
>
> BTW, why are you using engine-config and not doing it from oVirt UI or
> using virsh edit command?
>
> Thanks
>
>
> On Mon, Mar 18, 2019 at 1:52 AM Darin Schmidt 
> wrote:
>
>> Hello all, im trying to figure out how to configure the custom properties
>> to enable my NVIDIA card to work in the VM. Its my understanding that the
>> drives dont work because it detects its in a VM..
>>
>> Im trying to do something like this:
>>
>> engine-config -s
>> UserDefinedVMProperties="kvmhidden=^(true|false)$;{type=vendor_id;state={^(on|off)$;value=^([0-9])$}}"
>>
>>
>> But thats clearly not working. If I do this:
>>
>> engine-config -s
>> UserDefinedVMProperties="kvmhidden=^(true|false)$;vendor_id={state=^(on|off)$;value=^([0-9])$}"
>>
>>
>> It works but, the options are messed up. Im not sure how to find out the
>> correct syntax to get this to work. Would appreciate any advice.
>>
>
>
> --
> Nisim Simsolo
> QE -Testing Engineer
> IRC: nsimsolo
> int phone - 8272305
> mobile - 054-4779934
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BNUKZSPXNJZSDKLX42EKTTPDOWRA362I/

[ovirt-users] Re: vender_id syntax UserDefinedVMProperties

[Darin Schmidt]

Still no luck getting the gtx 1080 to enable inside the VM. I see the code
is being generated in the xml with the hook. But I still get error code 43.
Someone mentioned doing it with eufi bios and that worked for them. So when
I get back from work today, perhaps ill give that a try.

On Mon, Mar 18, 2019, 6:10 AM Darin Schmidt  wrote:

> I have gotten the system to see the card, its in device manager. The
> problem seems to be that I cannot use it in the VM because from what I have
> been finding out is that it gets and error code 43. Nvidia drivers disable
> the card if it detects that its being used in a VM. I have found some code
> to use to hook it into the xml before_vm_starts.
>
> 99_mask_kvm
> #!/usr/bin/python2
>
> import hooking
> domxml = hooking.read_domxml()
>
> hyperv = domxml.getElementsByTagName('hyperv')[0]
> smm = domxml.createElement('vendor_id')
> smm.setAttribute('state', 'on')
> smm.setAttribute('value', '1234567890ab')
> hyperv.appendChild(smm)
>
> features = domxml.getElementsByTagName('features')[0]
> kvm = domxml.createElement('kvm')
> hidden = domxml.createElement('hidden')
> hidden.setAttribute('state', 'on')
> kvm.appendChild(hidden)
> features.appendChild(kvm)
>
> hooking.write_domxml(domxml)
>
>
> I am currently reinstalling the drivers to see if this helps.
>
> kvm off and vender_id is now in the xml code that get generated when the
> VM is started. Im going off of examples Im finding online. Perhaps I just
> need to add the 10de to it instead of some generic # others are using.
>
> On Mon, Mar 18, 2019 at 6:02 AM Nisim Simsolo  wrote:
>
>> Hi
>>
>> Vendor ID of Nvidia is usually 10de.
>> You can locate 'vendor ID:product ID' by running lspci command, for
>> example:
>> [root@intel-vfio ~]# lspci -Dnn | grep -i nvidia
>> :03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104GL
>> [Quadro K4200] [10de:11b4] (rev a1)
>> :03:00.1 Audio device [0403]: NVIDIA Corporation GK104 HDMI Audio
>> Controller [10de:0e0a] (rev a1)
>> [root@intel-vfio ~]#
>>
>> In this example, the vendor ID of VGA controller is 10de and the product
>> ID is 11b4
>>
>> Please bare in mind that you need to enable IOMMU, add pci-stub (prevent
>> the host driver for using GPU device) and disable the default nouveau
>> driver on the host Kernel command line.
>> to do that:
>> 1. Edit host /etc/sysconfig/grub and add the next to GRUB_CMDLINE_LINUX:
>>
>>- intel_iommu=on or amd_iommu=on
>>- pci-stub.ids=10de:11b4,10de:0e0a
>>- rdblacklist=nouveau
>>
>> 2. Regenerate the boot loader configuration using grub2-mkconfig command:
>> # grub2-mkconfig -o /etc/grub2.cfg
>> 3. Reboot the host.
>> 4. Verify configuration:
>> [root@intel-vfio ~]# cat /proc/cmdline
>> BOOT_IMAGE=/vmlinuz-3.10.0-957.5.1.el7.x86_64
>> root=/dev/mapper/vg0-lv_root ro crashkernel=auto rd.lvm.lv=vg0/lv_root
>> rd.lvm.lv=vg0/lv_swap rhgb quiet pci-stub.ids=10de:11b4,10de:0e0a
>> intel_iommu=on rdblacklist=nouveau LANG=en_US.UTF-8
>> [root@intel-vfio ~]#
>>
>>
>> After running this, you should be able to passthrough GPU to VM.
>>
>> BTW, why are you using engine-config and not doing it from oVirt UI or
>> using virsh edit command?
>>
>> Thanks
>>
>>
>> On Mon, Mar 18, 2019 at 1:52 AM Darin Schmidt 
>> wrote:
>>
>>> Hello all, im trying to figure out how to configure the custom
>>> properties to enable my NVIDIA card to work in the VM. Its my understanding
>>> that the drives dont work because it detects its in a VM..
>>>
>>> Im trying to do something like this:
>>>
>>> engine-config -s
>>> UserDefinedVMProperties="kvmhidden=^(true|false)$;{type=vendor_id;state={^(on|off)$;value=^([0-9])$}}"
>>>
>>>
>>> But thats clearly not working. If I do this:
>>>
>>> engine-config -s
>>> UserDefinedVMProperties="kvmhidden=^(true|false)$;vendor_id={state=^(on|off)$;value=^([0-9])$}"
>>>
>>>
>>> It works but, the options are messed up. Im not sure how to find out the
>>> correct syntax to get this to work. Would appreciate any advice.
>>>
>>
>>
>> --
>> Nisim Simsolo
>> QE -Testing Engineer
>> IRC: nsimsolo
>> int phone - 8272305
>> mobile - 054-4779934
>>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/F4RSJDPHOTCC7HW2BCNKAEMILB65W6DZ/

[ovirt-users] Cancel storage migration task?

[Alan G]

Hi,



I accidentally triggered a storage migration for a large vdisk that will take 
some hours to complete. Is there a way to cleanly cancel the task, such that 
the vdisk will remain on the original domain?



Thanks,



Alan___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/R22NPYDFN5PMNW3NCXCXIOPFWWBSMDA4/

[ovirt-users] Re: vdsm should decouple with managed glusterfs services

[Sahina Bose]

On Mon, Mar 18, 2019 at 4:15 PM levin  wrote:
>
> Hi Sahina,
>
> My cluster did not enabled fencing, is somewhere I can disable restart policy 
> from vdsm completely? So I can observe this case next time, and giving a fist 
> investigation on unresponsive node.
>
+Martin Perina - do you know if this is possible?

> Regards,
> Levin
>
>
> On 18/3/2019, 17:40, "Sahina Bose"  wrote:
>
> On Sun, Mar 17, 2019 at 12:56 PM  wrote:
> >
> > Hi, I had experience two time of 3-node hyper-converged 4.2.8 ovirt 
> cluster total outage due to vdsm reactivate the unresponsive node, and cause 
> the multiple glusterfs daemon restart. As a result, all VM was paused and 
> some of disk image was corrupted.
> >
> > At the very beginning, one of the ovirt node was overloaded due to high 
> memory and CPU, the hosted-engine have trouble to collect status from vdsm 
> and mark it as unresponsive and it start migrate the workload to healthy 
> node. However, when it start migrate, second ovirt node being unresponsive 
> where vdsm try reactivate the 1st unresponsive node and restart it's 
> glusterd. So the gluster domain was acquiring the quorum and waiting for 
> timeout.
> >
> > If 1st node reactivation is success and every other node can survive 
> the timeout, it will be an idea case. Unfortunately, the second node cannot 
> pick up the VM being migrated due to gluster I/O timeout, so second node at 
> that moment was marked as unresponsive, and so on... vdsm is restarting the 
> glusterd on the second node which cause disaster. All node are racing on 
> gluster volume self-healing, and i can't mark the cluster as maintenance mode 
> as well. What I can do is try to resume the paused VM via virsh and issue 
> shutdown for each domain, also hard shutdown for un-resumable VM.
> >
> > After number of VM shutdown and wait the gluster healing completed,  
> the cluster state back to normal, and I try to start the VM being manually 
> stopped, most of them can be started normally, but number of VM was crashed 
> or un-startable, instantly I  found the image files of un-startable VM was 
> owned by root(can't explain why), and can be restarted after chmod.  Two of 
> them still cannot start with  "bad volume specification" error. One of them 
> can start to boot loader, but the LVM metadata were lost.
> >
> > The impact was huge when vdsm restart the glusterd without human 
> invention.
>
> Is this even with the fencing policies set for ensuring gluster quorum
> is not lost?
>
> There are 2 policies that you need to enable at the cluster level -
> Skip fencing if Gluster bricks are UP
> Skip fencing if Gluster quorum not met
>
>
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> > List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/NIPHD7COR5ZBVQROOUU6R4Q45SDFAJ5K/
>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z6OBWXWFMIWILZWEMZLEJNRMHL3VLBDF/

[ovirt-users] Re: Error creating a storage domain (On Cisco UCS Only)

[nico . kruger]

hi All,

Just wanted to say that I found the issue, it was 4096k sector hard drives... 
put in some test 512k drives and this fixed it all.. 

thanks for the help
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/WBYXVKQX5QZIGYGRJ6JS6YHM6U6DRO23/

[ovirt-users] Re: Ovirt 4.3.1 problem with HA agent

[Strahil Nikolov]

 Hi Alexei,
In order to debug it check the following:
1. Check gluster:1.1 All bricks up ?1.2 All bricks healed (gluster volume heal 
data info summary) and no split-brain
2. Go to the problematic host and check the mount point is there2.1. Check 
permissions (should be vdsm:kvm) and fix with chown -R if needed2.2. Check the 
OVF_STORE from the logs that it exists2.3. Check that vdsm can extract the 
file:sudo -u vdsm tar -tvf 
/rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_data/DOMAIN-UUID/Volume-UUID/Image-ID
3 Configure virsh alias, as it's quite helpful:alias virsh='virsh -c 
qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf'
4. If VM is running - go to the host and get the xml:virsh dumpxml HostedEngine 
> /root/HostedEngine.xml4.1. Get the Network:virsh net-dumpxml vdsm-ovirtmgmt > 
/root/vdsm-ovirtmgmt.xml4.2 If not , Here is mine:[root@ovirt1 ~]# virsh 
net-dumpxml vdsm-ovirtmgmt

  vdsm-ovirtmgmt
  7ae538ce-d419-4dae-93b8-3a4d27700227
  
  


UUID is not important, as my first recovery was with different one.
5. If you Hosted Engine is down:5.1 Remove the VM (if exists anywhere)on all 
nodes:virsh undefine HostedEngine5.2 Verify that the nodes are in global 
maintenance:hosted-engine --vm-status5.3 Define the Engine on only 1 
machinevirsh define HostedEngine.xmlvirsh net-define vdsm-ovirtmgmt.xml
virsh start HostedEngine

Note: if it complains about the storage - there is no link in 
/var/run/vdsm/storage/DOMAIN-UUID/Volume-UUID to your Volume-UUIDHere is how it 
looks mine:[root@ovirt1 808423f9-8a5c-40cd-bc9f-2568c85b8c74]# ll 
/var/run/vdsm/storage/808423f9-8a5c-40cd-bc9f-2568c85b8c74
total 24
lrwxrwxrwx. 1 vdsm kvm 139 Mar 17 07:42 2c74697a-8bd9-4472-8a98-bf624f3462d5 -> 
/rhev/data-center/mnt/glusterSD/ovirt1.localdomain:_engine/808423f9-8a5c-40cd-bc9f-2568c85b8c74/images/2c74697a-8bd9-4472-8a98-bf624f3462d5
lrwxrwxrwx. 1 vdsm kvm 139 Mar 17 07:45 3ec27d6d-921c-4348-b799-f50543b6f919 -> 
/rhev/data-center/mnt/glusterSD/ovirt1.localdomain:_engine/808423f9-8a5c-40cd-bc9f-2568c85b8c74/images/3ec27d6d-921c-4348-b799-f50543b6f919
lrwxrwxrwx. 1 vdsm kvm 139 Mar 17 08:28 441abdc8-6cb1-49a4-903f-a1ec0ed88429 -> 
/rhev/data-center/mnt/glusterSD/ovirt1.localdomain:_engine/808423f9-8a5c-40cd-bc9f-2568c85b8c74/images/441abdc8-6cb1-49a4-903f-a1ec0ed88429
lrwxrwxrwx. 1 vdsm kvm 139 Mar 17 21:15 8ec7a465-151e-4ac3-92a7-965ecf854501 -> 
/rhev/data-center/mnt/glusterSD/ovirt1.localdomain:_engine/808423f9-8a5c-40cd-bc9f-2568c85b8c74/images/8ec7a465-151e-4ac3-92a7-965ecf854501
lrwxrwxrwx. 1 vdsm kvm 139 Mar 17 08:28 94ade632-6ecc-4901-8cec-8e39f3d69cb0 -> 
/rhev/data-center/mnt/glusterSD/ovirt1.localdomain:_engine/808423f9-8a5c-40cd-bc9f-2568c85b8c74/images/94ade632-6ecc-4901-8cec-8e39f3d69cb0
lrwxrwxrwx. 1 vdsm kvm 139 Mar 17 07:42 fe62a281-51e9-4b23-87b3-2deb52357304 -> 
/rhev/data-center/mnt/glusterSD/ovirt1.localdomain:_engine/808423f9-8a5c-40cd-bc9f-2568c85b8c74/images/fe62a281-51e9-4b23-87b3-2deb52357304


Once you create your link , start it again.
6. Wait till OVF is fixed (takes more than the settings in the engine :) )
Good Luck!
Best Regards,Strahil Nikolov


В понеделник, 18 март 2019 г., 12:57:30 ч. Гринуич+2, Николаев Алексей 
 написа:  
 
 Hi all! I have a very similar problem after update one of the two nodes to 
version 4.3.1. This node77-02 lost connection to gluster volume named DATA, but 
not to volume with hosted engine.  node77-02 /var/log/messages Mar 18 13:40:00 
node77-02 journal: ovirt-ha-agent 
ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config.vm ERROR Failed 
scanning for OVF_STORE due to Command Volume.getInfo with args 
{'storagepoolID': '----', 'storagedomainID': 
'2ee71105-1810-46eb-9388-cc6caccf9fac', 'volumeID': 
u'224e4b80-2744-4d7f-bd9f-43eb8fe6cf11', 'imageID': 
u'43b75b50-cad4-411f-8f51-2e99e52f4c77'} failed:#012(code=201, message=Volume 
does not exist: (u'224e4b80-2744-4d7f-bd9f-43eb8fe6cf11',))Mar 18 13:40:00 
node77-02 journal: ovirt-ha-agent 
ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config.vm ERROR Unable 
to identify the OVF_STORE volume, falling back to initial vm.conf. Please 
ensure you already added your first data domain for regular VMs HostedEngine VM 
works fine on all nodes. But node77-02 failed witherror in webUI: 
ConnectStoragePoolVDS failed: Cannot find master domain: 
u'spUUID=5a5cca91-01f8-01af-0297-025f, 
msdUUID=7d5de684-58ff-4fbc-905d-3048fc55b2b1' node77-02 vdsm.log 2019-03-18 
13:51:46,287+0300 WARN  (jsonrpc/7) [storage.StorageServer.MountConnection] 
gluster server u'msk-gluster-facility.' is not in bricks 
['node-msk-gluster203', 'node-msk-gluster205', 'node-msk-gluster201'], possibly 
mounting duplicate servers (storageServer:317)2019-03-18 13:51:46,287+0300 INFO 
 (jsonrpc/7) [storage.Mount] mounting msk-gluster-facility.ipt.fsin.uis:/data 
at /rhev/data-center/mnt/glusterSD/msk-gluster-facility.:_data 
(mount:204)2019-03-18