March 2018 - Users - oVirt List Archives

overt-guest-agent Failure on latest Debian 9 Sretch
by Andrei Verovski 27 Mar '18

27 Mar '18

Hi, I just installed latest Debian 9 Sretch under oVirt 4.2 and got this error: # tail -n 1000 ovirt-guest-agent.log MainThread::INFO::2018-03-26 17:09:57,400::ovirt-guest-agent::59::root::Starting oVirt guest agent MainThread::ERROR::2018-03-26 17:09:57,402::ovirt-guest-agent::141::root::Unhandled exception in oVirt guest agent! Traceback (most recent call last): File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 135, in <module> agent.run(daemon, pidfile) File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in run self.agent = LinuxVdsAgent(config) File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 472, in __init__ AgentLogicBase.__init__(self, config) File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in __init__ self.vio = VirtIoChannel(config.get("virtio", "device")) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 153, in __init__ self._stream = VirtIoStream(vport_name) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 134, in __init__ self._vport = os.open(vport_name, os.O_RDWR) OSError: [Errno 2] No such file or directory: '/dev/virtio-ports/com.redhat.rhevm.vdsm’ Followed this manual: https://bugzilla.redhat.com/show_bug.cgi?id=1472293 and run touch /etc/udev/rules.d/55-ovirt-guest-agent.rules # edit /etc/udev/rules.d/55-ovirt-guest-agent.rules SYMLINK=="virtio-ports/ovirt-guest-agent.0", OWNER="ovirtagent", GROUP="ovirtagent" udevadm trigger --subsystem-match="virtio-ports” AND this http://lists.ovirt.org/pipermail/users/2018-January/086101.html touch /etc/ovirt-guest-agent/ovirt-guest-agent.conf # <— it didn't existed so I created it. # edit /etc/ovirt-guest-agent.conf [virtio] device = /dev/virtio-ports/ovirt-guest-agent.0 reboot Yet still have same problem and error message. How to solve it ? Thanks in advance Andrei

4 4

vdi over wan optimation
by Andreas Huser 27 Mar '18

27 Mar '18

Hi, i have a question about vdi over wan. The traffic is very high when i look videos or online streams. 100% of my capacity of Internet Bandwidth is used. Does anyone an idea how can i optimise spice for wan? Thanks a lot Andreas

2 1

Host non-responsive after engine failure
by spfma.tech＠e.mail.fr 27 Mar '18

27 Mar '18

--=_fa659c011be33add9dea7033694abeb7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI had an electrical failure on the server hosting the engine.= =0AAfter the reboot it was able to gain access to it again, log into the= GUI, but the currently online node is not leaving "not responsive" stat= us.=0AOf course, the network storage paths are still mounted, the VMs ar= e running, but I can't gain control again.=0A=0AIn vdsmd.log, I have a l= ot of messages like this one :=0A2018-03-27 12:03:11,281+0200 INFO (vmre= covery) [vds] recovery: waiting for storage pool to go up (clientIF:674)= =0A2018-03-27 12:03:16,286+0200 INFO (vmrecovery) [vdsm.api] START getCo= nnectedStoragePoolsList(options=3DNone) from=3Dinternal, task_id=3Db90f5= 50e-ee68-4a91-a7c6-3b60f11c3978 (api:46)=0A2018-03-27 12:03:16,286+0200= INFO (vmrecovery) [vdsm.api] FINISH getConnectedStoragePoolsList return= =3D{'poollist': []} from=3Dinternal, task_id=3Db90f550e-ee68-4a91-a7c6-3= b60f11c3978 (api:52)=0A2018-03-27 12:03:16,287+0200 INFO (vmrecovery) [v= ds] recovery: waiting for storage pool to go up (clientIF:674)=0A2018-03= -27 12:03:18,413+0200 INFO (periodic/3) [vdsm.api] START repoStats(domai= ns=3D()) from=3Dinternal, task_id=3D067714b4-8172-4eec-92bb-6ac16586a657= (api:46)=0A2018-03-27 12:03:18,413+0200 INFO (periodic/3) [vdsm.api] FI= NISH repoStats return=3D{} from=3Dinternal, task_id=3D067714b4-8172-4eec= -92bb-6ac16586a657 (api:52)=0A2018-03-27 12:03:18,413+0200 INFO (periodi= c/3) [vdsm.api] START multipath_health() from=3Dinternal, task_id=3De974= 21fb-5d5a-4291-9231-94bc1961cc49 (api:46)=0A2018-03-27 12:03:18,413+0200= INFO (periodic/3) [vdsm.api] FINISH multipath_health return=3D{} from= =3Dinternal, task_id=3De97421fb-5d5a-4291-9231-94bc1961cc49 (api:52)=0A2= 018-03-27 12:03:20,458+0200 INFO (jsonrpc/6) [api.host] START getAllVmSt= ats() from=3D::1,57576 (api:46)=0A2018-03-27 12:03:20,462+0200 INFO (jso= nrpc/6) [api.host] FINISH getAllVmStats return=3D{'status': {'message':= 'Done', 'code': 0}, 'statsList': (suppressed)} from=3D::1,57576 (api:52= )=0A2018-03-27 12:03:20,464+0200 INFO (jsonrpc/6) [jsonrpc.JsonRpcServer= ] RPC call Host.getAllVmStats succeeded in 0.01 seconds (__init__:573)= =0A2018-03-27 12:03:20,474+0200 INFO (jsonrpc/7) [api.host] START getAll= VmIoTunePolicies() from=3D::1,57576 (api:46)=0A2018-03-27 12:03:20,475+0= 200 INFO (jsonrpc/7) [api.host] FINISH getAllVmIoTunePolicies return=3D{= 'status': {'message': 'Done', 'code': 0}, 'io_tune_policies_dict': {'c33= a30ba-7fe8-4ff4-aeac-80cb396b9670': {'policy': [], 'current_values': [{'= ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec':= 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L},= 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07ef= a4fe-06bc-498e-8f42-035461aef900/images/593f6f61-cb7f-4c53-b6e7-617964c2= 22e9/329b2e8b-6cf9-4b39-9190-14a32697ce44', 'name': 'sda'}]}, 'e8a90739-= 7737-413e-8edc-a373192f4476': {'policy': [], 'current_values': [{'ioTune= ': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'r= ead_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path'= : '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06= bc-498e-8f42-035461aef900/images/97e078f7-69c6-46c2-b620-26474cd65929/bb= b4a1fb-5594-4750-be71-c6b55dca3257', 'name': 'vda'}]}, '3aec5ce4-691f-48= 7c-a916-aa7f7a664d8c': {'policy': [], 'current_values': [{'ioTune': {'wr= ite_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_byt= es_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhe= v/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e= -8f42-035461aef900/images/46a65a1b-d00a-452d-ab9b-70862bb5c053/a4d2ad44-= 5577-4412-9a8c-819d1f12647a', 'name': 'sda'}, {'ioTune': {'write_bytes_s= ec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L= , 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-cent= er/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-03546= 1aef900/images/0c3a13ce-8f7a-4034-a8cc-12f795b8aa17/c48e0e37-e54b-4ca3-b= 3ed-b66ead9fad44', 'name': 'sdb'}]}, '5de1de8f-ac01-459f-b4b8-6d1ed05c8c= a3': {'policy': [], 'current_values': [{'ioTune': {'write_bytes_sec': 0L= , 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'writ= e_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/= 10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900= /images/320ac81c-7db7-4ec0-a271-755e91442b6a/8bfc95c5-318c-43dd-817f-6c7= a8a7a5b43', 'name': 'sda'}, {'ioTune': {'write_bytes_sec': 0L, 'total_io= ps_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec'= : 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.13= 2:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/e7a= d86bb-3c63-466b-82cf-687164c46f7b/613ea0ce-ed14-4185-b3fd-36490441f889',= 'name': 'sdb'}]}, '5d548a09-a397-4aac-8b1f-39002e014f5f': {'policy': []= , 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec'= : 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, '= total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.132:_volu= me2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/c7421014-7= c5f-45ad-a948-caa83b8ce3e7/ae0ba893-69af-4b67-a262-b739596d5c95', 'name'= : 'sda'}]}, '168b01b1-5ec8-41dd-808e-fa9f66cea718': {'policy': [], 'curr= ent_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, '= read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_b= ytes_sec': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovi= rt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/b9b7902a-7a62-482= 6-bfda-dff260b9fcd1/d05db17c-9908-4bfb-a74b-4aa944510a56', 'name': 'vda'= }, {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_s= ec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec':= 0L}, 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1= /07efa4fe-06bc-498e-8f42-035461aef900/images/564b3848-b6d5-4deb-910f-5b6= f2fdbccc5/4f89ff25-2d3b-40b9-9bbc-9a6b6995346c', 'name': 'vdb'}, {'ioTun= e': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, '= read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path= ': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-0= 6bc-498e-8f42-035461aef900/images/738e0704-8484-483b-ae67-091715496152/2= f811423-6bab-4966-9c00-9d3b72429328', 'name': 'vdc'}]}}} from=3D::1,5757= 6 (api:52)=0A2018-03-27 12:03:20,475+0200 INFO (jsonrpc/7) [jsonrpc.Json= RpcServer] RPC call Host.getAllVmIoTunePolicies succeeded in 0.00 second= s (__init__:573)=0A2018-03-27 12:03:21,292+0200 INFO (vmrecovery) [vdsm.= api] START getConnectedStoragePoolsList(options=3DNone) from=3Dinternal,= task_id=3Da35602b2-7d5c-4e87-86cd-ede17c62488f (api:46)=0A2018-03-27 12= :03:21,292+0200 INFO (vmrecovery) [vdsm.api] FINISH getConnectedStorageP= oolsList return=3D{'poollist': []} from=3Dinternal, task_id=3Da35602b2-7= d5c-4e87-86cd-ede17c62488f (api:52)=0A2018-03-27 12:03:21,293+0200 INFO= (vmrecovery) [vds] recovery: waiting for storage pool to go up (clientI= F:674)=0A=0ASo i see no error.=0A=0ABut in messages :=0AMar 27 12:01:43= pfm-srv-virt-2 libvirtd: 2018-03-27 10:01:43.569+0000: 71793: error : q= emuDomainAgentAvailable:6030 : Guest agent is not responding: QEMU guest= agent is not connected=0A=0AI have restarted libvirtd and vdsmd service= s.=0A=0AIs there something else to do ?=0A=0ARegards =0A=0A-------------= ------------------------------------------------------------------------= ------------=0AFreeMail powered by mail.fr --=_fa659c011be33add9dea7033694abeb7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <div>Hi, I had an electrical failure on th= e server hosting the engine. After the reboot it was able to gain a= ccess to it again, log into the GUI, but the currently online node is no= t leaving "not responsive" status. Of course, the network storage p= aths are still mounted, the VMs are running, but I can't gain control ag= ain. In vdsmd.log, I have a lot of messages like this one :<b= r />2018-03-27 12:03:11,281+0200 INFO  (vmrecovery) [vds] recovery:= waiting for storage pool to go up (clientIF:674) 2018-03-27 12:03:= 16,286+0200 INFO  (vmrecovery) [vdsm.api] START getConnectedStorage= PoolsList(options=3DNone) from=3Dinternal, task_id=3Db90f550e-ee68-4a91-= a7c6-3b60f11c3978 (api:46) 2018-03-27 12:03:16,286+0200 INFO = (vmrecovery) [vdsm.api] FINISH getConnectedStoragePoolsList return=3D{'= poollist': []} from=3Dinternal, task_id=3Db90f550e-ee68-4a91-a7c6-3b60f1= 1c3978 (api:52) 2018-03-27 12:03:16,287+0200 INFO  (vmrecovery= ) [vds] recovery: waiting for storage pool to go up (clientIF:674) = 2018-03-27 12:03:18,413+0200 INFO  (periodic/3) [vdsm.api] START re= poStats(domains=3D()) from=3Dinternal, task_id=3D067714b4-8172-4eec-92bb= -6ac16586a657 (api:46) 2018-03-27 12:03:18,413+0200 INFO  (per= iodic/3) [vdsm.api] FINISH repoStats return=3D{} from=3Dinternal, task_i= d=3D067714b4-8172-4eec-92bb-6ac16586a657 (api:52) 2018-03-27 12:03:= 18,413+0200 INFO  (periodic/3) [vdsm.api] START multipath_health()= from=3Dinternal, task_id=3De97421fb-5d5a-4291-9231-94bc1961cc49 (api:46= ) 2018-03-27 12:03:18,413+0200 INFO  (periodic/3) [vdsm.api] F= INISH multipath_health return=3D{} from=3Dinternal, task_id=3De97421fb-5= d5a-4291-9231-94bc1961cc49 (api:52) 2018-03-27 12:03:20,458+0200 IN= FO  (jsonrpc/6) [api.host] START getAllVmStats() from=3D::1,57576 (= api:46) 2018-03-27 12:03:20,462+0200 INFO  (jsonrpc/6) [api.ho= st] FINISH getAllVmStats return=3D{'status': {'message': 'Done', 'code':= 0}, 'statsList': (suppressed)} from=3D::1,57576 (api:52) 2018-03-2= 7 12:03:20,464+0200 INFO  (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC c= all Host.getAllVmStats succeeded in 0.01 seconds (__init__:573) 201= 8-03-27 12:03:20,474+0200 INFO  (jsonrpc/7) [api.host] START getAll= VmIoTunePolicies() from=3D::1,57576 (api:46) 2018-03-27 12:03:20,47= 5+0200 INFO  (jsonrpc/7) [api.host] FINISH getAllVmIoTunePolicies r= eturn=3D{'status': {'message': 'Done', 'code': 0}, 'io_tune_policies_dic= t': {'c33a30ba-7fe8-4ff4-aeac-80cb396b9670': {'policy': [], 'current_val= ues': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_io= ps_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_se= c': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms= __1/07efa4fe-06bc-498e-8f42-035461aef900/images/593f6f61-cb7f-4c53-b6e7-= 617964c222e9/329b2e8b-6cf9-4b39-9190-14a32697ce44', 'name': 'sda'}]}, 'e= 8a90739-7737-413e-8edc-a373192f4476': {'policy': [], 'current_values': [= {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec'= : 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}= , 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07e= fa4fe-06bc-498e-8f42-035461aef900/images/97e078f7-69c6-46c2-b620-26474cd= 65929/bbb4a1fb-5594-4750-be71-c6b55dca3257', 'name': 'vda'}]}, '3aec5ce4= -691f-487c-a916-aa7f7a664d8c': {'policy': [], 'current_values': [{'ioTun= e': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, '= read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path= ': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-0= 6bc-498e-8f42-035461aef900/images/46a65a1b-d00a-452d-ab9b-70862bb5c053/a= 4d2ad44-5577-4412-9a8c-819d1f12647a', 'name': 'sda'}, {'ioTune': {'write= _bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_= sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/d= ata-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f= 42-035461aef900/images/0c3a13ce-8f7a-4034-a8cc-12f795b8aa17/c48e0e37-e54= b-4ca3-b3ed-b66ead9fad44', 'name': 'sdb'}]}, '5de1de8f-ac01-459f-b4b8-6d= 1ed05c8ca3': {'policy': [], 'current_values': [{'ioTune': {'write_bytes_= sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0= L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-cen= ter/mnt/10.100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-0354= 61aef900/images/320ac81c-7db7-4ec0-a271-755e91442b6a/8bfc95c5-318c-43dd-= 817f-6c7a8a7a5b43', 'name': 'sda'}, {'ioTune': {'write_bytes_sec': 0L, '= total_iops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_i= ops_sec': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/10.= 100.2.132:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/im= ages/e7ad86bb-3c63-466b-82cf-687164c46f7b/613ea0ce-ed14-4185-b3fd-364904= 41f889', 'name': 'sdb'}]}, '5d548a09-a397-4aac-8b1f-39002e014f5f': {'pol= icy': [], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_i= ops_sec': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec= ': 0L, 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.1= 32:_volume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/c7= 421014-7c5f-45ad-a948-caa83b8ce3e7/ae0ba893-69af-4b67-a262-b739596d5c95'= , 'name': 'sda'}]}, '168b01b1-5ec8-41dd-808e-fa9f66cea718': {'policy': [= ], 'current_values': [{'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec= ': 0L, 'read_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L,= 'total_bytes_sec': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.132:_vo= lume2_ovirt__vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/b9b7902a= -7a62-4826-bfda-dff260b9fcd1/d05db17c-9908-4bfb-a74b-4aa944510a56', 'nam= e': 'vda'}, {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 're= ad_iops_sec': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_byt= es_sec': 0L}, 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt= __vms__1/07efa4fe-06bc-498e-8f42-035461aef900/images/564b3848-b6d5-4deb-= 910f-5b6f2fdbccc5/4f89ff25-2d3b-40b9-9bbc-9a6b6995346c', 'name': 'vdb'},= {'ioTune': {'write_bytes_sec': 0L, 'total_iops_sec': 0L, 'read_iops_sec= ': 0L, 'read_bytes_sec': 0L, 'write_iops_sec': 0L, 'total_bytes_sec': 0L= }, 'path': '/rhev/data-center/mnt/10.100.2.132:_volume2_ovirt__vms__1/07= efa4fe-06bc-498e-8f42-035461aef900/images/738e0704-8484-483b-ae67-091715= 496152/2f811423-6bab-4966-9c00-9d3b72429328', 'name': 'vdc'}]}}} from=3D= ::1,57576 (api:52) 2018-03-27 12:03:20,475+0200 INFO  (jsonrpc= /7) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmIoTunePolicies succeed= ed in 0.00 seconds (__init__:573) 2018-03-27 12:03:21,292+0200 INFO=   (vmrecovery) [vdsm.api] START getConnectedStoragePoolsList(option= s=3DNone) from=3Dinternal, task_id=3Da35602b2-7d5c-4e87-86cd-ede17c62488= f (api:46) 2018-03-27 12:03:21,292+0200 INFO  (vmrecovery) [vd= sm.api] FINISH getConnectedStoragePoolsList return=3D{'poollist': []} fr= om=3Dinternal, task_id=3Da35602b2-7d5c-4e87-86cd-ede17c62488f (api:52)<b= r />2018-03-27 12:03:21,293+0200 INFO  (vmrecovery) [vds] recovery:= waiting for storage pool to go up (clientIF:674) So i see no= error. But in messages : Mar 27 12:01:43 pfm-srv-virt-2= libvirtd: 2018-03-27 10:01:43.569+0000: 71793: error : qemuDomainAgentA= vailable:6030 : Guest agent is not responding: QEMU guest agent is not c= onnected I have restarted libvirtd and vdsmd services.<= br /> Is there something else to do ? Regards</di= v>=0A <hr>FreeMail powered by <a href=3D"https:/= /mail.fr" target=3D"_blank">mail.fr</a>=0A --=_fa659c011be33add9dea7033694abeb7--

1 0

Workflow after restoring engine from backup
by Sven Achtelik 27 Mar '18

27 Mar '18

--_000_831f30ed018b4739a2491cbd24f2429depsaero_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I had issue with the storage that hosted my engine vm. The disk got corrupt= ed and I needed to restore the engine from a backup. That worked as expecte= d, I just didn't start the engine yet. I know that after the backup was tak= en some machines where migrated around before the engine disks failed. My q= uestion is what will happen once I start the engine service which has the r= estored backup on it ? Will it query the hosts for the running VMs or will = it assume that the VMs are still on the hosts as they resided at the point = of backup ? Would I need to change the DB manual to let the engine know whe= re VMs are up at this point ? What will happen to HA VMs ? I feel that it m= ight try to start them a second time. My biggest issue is that I can't get= a service Windows to shutdown all VMs and then lat them restart by the eng= ine. Is there a known workflow for that ? Thank you, Sven --_000_831f30ed018b4739a2491cbd24f2429depsaero_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"DE" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi All, <o:p></o:p> <o:p> </o:p> I had issue with the storage th= at hosted my engine vm. The disk got corrupted and I needed to restore the = engine from a backup. That worked as expected, I just didn’t start th= e engine yet. I know that after the backup was taken some machines where migrated around before the engine disks fail= ed. My question is what will happen once I start the engine service which h= as the restored backup on it ? Will it query the hosts for the running VMs = or will it assume that the VMs are still on the hosts as they resided at the point of backup ? Would I need t= o change the DB manual to let the engine know where VMs are up at this poin= t ? What will happen to HA VMs ? I feel that it might try to start them a s= econd time.  My biggest issue is that I can’t get a service Windows to shutdown all VMs and then lat = them restart by the engine.<o:p></o:p> <o:p> </o:p> Is there a known workflow for t= hat ? <o:p> </o:p> <o:p> </o:p> Thank you, <o:p></o:p></= p> Sven <o:p></o:p> </div> </body> </html> --_000_831f30ed018b4739a2491cbd24f2429depsaero_--

2 6

[graph.y:363:graphyyerror] 0-parser: syntax error: line 19 (volume 'management'): "cluster.server-quorum-type:", allowed tokens are 'volume', 'type', 'subvolumes', 'option', 'end-volume'()
by TomK 27 Mar '18

27 Mar '18

Hey All, Wondering if anyone see this happen and can provide some hints. After numerous failed attempts to add a physical host to an oVirt VM engine that already had a gluster volume, I get this errors and I'm unable to start up gluster anymore: [2018-03-27 07:01:37.511304] E [MSGID: 101021] [graph.y:363:graphyyerror] 0-parser: syntax error: line 19 (volume 'management'): "cluster.server-quorum-type:" allowed tokens are 'volume', 'type', 'subvolumes', 'option', 'end-volume'() [2018-03-27 07:01:37.511597] E [MSGID: 100026] [glusterfsd.c:2403:glusterfs_process_volfp] 0-: failed to construct the graph [2018-03-27 07:01:37.511791] E [graph.c:1102:glusterfs_graph_destroy] (-->/usr/sbin/glusterd(glusterfs_volumes_init+0xfd) [0x55f06827d0cd] -->/usr/sbin/glusterd(glusterfs_process_volfp+0x150) [0x55f06827cf60] -->/lib64/libglusterfs.so.0(glusterfs_graph_destroy+0x84) [0x7f519a816c64] ) 0-graph: invalid argument: graph [Invalid argument] [2018-03-27 07:01:37.511839] W [glusterfsd.c:1393:cleanup_and_exit] (-->/usr/sbin/glusterd(glusterfs_volumes_init+0xfd) [0x55f06827d0cd] -->/usr/sbin/glusterd(glusterfs_process_volfp+0x163) [0x55f06827cf73] -->/usr/sbin/glusterd(cleanup_and_exit+0x6b) [0x55f06827c49b] ) 0-: received signum (-1), shutting down [2018-03-27 07:02:52.223358] I [MSGID: 100030] [glusterfsd.c:2556:main] 0-/usr/sbin/glusterd: Started running /usr/sbin/glusterd version 3.13.2 (args: /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO) [2018-03-27 07:02:52.229816] E [MSGID: 101021] [graph.y:363:graphyyerror] 0-parser: syntax error: line 19 (volume 'management'): "cluster.server-quorum-type:" allowed tokens are 'volume', 'type', 'subvolumes', 'option', 'end-volume'() [2018-03-27 07:02:52.230125] E [MSGID: 100026] [glusterfsd.c:2403:glusterfs_process_volfp] 0-: failed to construct the graph [2018-03-27 07:02:52.230320] E [graph.c:1102:glusterfs_graph_destroy] (-->/usr/sbin/glusterd(glusterfs_volumes_init+0xfd) [0x55832612b0cd] -->/usr/sbin/glusterd(glusterfs_process_volfp+0x150) [0x55832612af60] -->/lib64/libglusterfs.so.0(glusterfs_graph_destroy+0x84) [0x7f9a1ded4c64] ) 0-graph: invalid argument: graph [Invalid argument] [2018-03-27 07:02:52.230369] W [glusterfsd.c:1393:cleanup_and_exit] (-->/usr/sbin/glusterd(glusterfs_volumes_init+0xfd) [0x55832612b0cd] -->/usr/sbin/glusterd(glusterfs_process_volfp+0x163) [0x55832612af73] -->/usr/sbin/glusterd(cleanup_and_exit+0x6b) [0x55832612a49b] ) 0-: received signum (-1), shutting down -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun.

1 0

Network interface persistence
by Sverker Abrahamsson 27 Mar '18

27 Mar '18

I have a number of vm's running under Ovirt 4.2, most are CentOS 7 and one Debian. Issue is that when multiple network interfaces are assigned they don't persist but it variates at boot which interface will be which. I've tried various methods, setting UUID and HWADDRESS in the ifcfg file and a file /etc/udev/rules.d/70-persistent-net.rules file like the below: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:4a:16:01:63", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:4a:16:01:6d", KERNEL=="eth*", NAME="eth1" I've also tried in the gui to change the network profile each virtual card is attached, but even then the interfaces in vm will be oposide of what I had intended. How to accomplish with Ovirt to get network interface persistence? The Debian vm is an appliance so I can't log in to it to change network interfaces. /Sverker

1 1

novnc_websocket_proxy_fqdn
by 董青龙 27 Mar '18

27 Mar '18

------=_Part_152734_1156022334.1522057002223 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgYWxsLAogICAgICAgIEkgYW0gdXNpbmcgbm92bmMgdG8gY29ubmVjdCB2bXMgaW4gbXkgb3Zp cnQ0LjEgZW52aXJvbm1lbnQuIE15IGVuZ2luZSBmcWRuIGhhcyBiZWVuIHNldCB0byAiZW5naW5l MS50ZXN0Lm9yZyIgYmVmb3JlIEkgZXhjdXRlZCAiZW5naW5lLXNldHVwIi4gSSBjb3VsZCBjb25u ZWN0IHZtcyB1c2luZyAiZW5naW5lMS50ZXN0Lm9yZyIgb24gY2xpZW50MSB3aGljaCAiZW5naW5l MS50ZXN0Lm9yZyIgY2FuIGJlIHJlc292ZWQuIE5vdyBJIHdhbnQgdG8gY29ubmVjdCB2bXMgdXNp bmcgImVuZ2luZTIudGVzdC5vcmciIG9uIGNsaWVudDIgd2hpY2ggb25seSAiZW5naW5lMi50ZXN0 Lm9yZyIgY2FuIGJlIHJlc29sdmVkLiBJIGhhdmUgc2V0ICJTU09fQUxURVJOQVRFX0VOR0lORV9G UUROUz0iZW5naW5lMi50ZXN0Lm9yZyIiIGluIC9ldGMvb3ZpcnQtZW5naW5lL2VuZ2luZS5jb25m LmQvOTktYWx0ZXJuYXRlLWVuZ2luZS1mcWRucy5jb25mLiBCdXQgSSBmYWlsZWQuIEl0IHNhaWQg dGhhdCAiY2FuJ3QgY29ubmVjdCB0byB3ZWJzb2NrZXQgcHJveHkgc2VydmVyIHdzczovL2VuZ2lu ZTEudGVzdC5vcmc6NjEwMCIuIFNvIHdoZXJlIGNhbiBJIG1vZGlmeSB0aGlzIHdlYnNvY2tldCBw cm94eSBwYXJhbWV0ZXI/CiAgICAgICAgQW55b25lIGNhbiBoZWxwPyBUaGFua3Mh ------=_Part_152734_1156022334.1522057002223 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgYWxsLDwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEkgYW0gdXNpbmcgbm92bmMgdG8gY29ubmVjdCB2bXMgaW4gbXkgb3ZpcnQ0 LjEgZW52aXJvbm1lbnQuIE15IGVuZ2luZSBmcWRuIGhhcyBiZWVuIHNldCB0byAiZW5naW5lMS50 ZXN0Lm9yZyIgYmVmb3JlIEkgZXhjdXRlZCAiZW5naW5lLXNldHVwIi4gSSBjb3VsZCBjb25uZWN0 IHZtcyB1c2luZyAiZW5naW5lMS50ZXN0Lm9yZyIgb24gY2xpZW50MSB3aGljaCAiZW5naW5lMS50 ZXN0Lm9yZyIgY2FuIGJlIHJlc292ZWQuIE5vdyBJIHdhbnQgdG8gY29ubmVjdCB2bXMgdXNpbmcg ImVuZ2luZTIudGVzdC5vcmciIG9uIGNsaWVudDIgd2hpY2ggb25seSAiZW5naW5lMi50ZXN0Lm9y ZyIgY2FuIGJlIHJlc29sdmVkLiBJIGhhdmUgc2V0ICJTU09fQUxURVJOQVRFX0VOR0lORV9GUURO Uz0iZW5naW5lMi50ZXN0Lm9yZyIiIGluJm5ic3A7L2V0Yy9vdmlydC1lbmdpbmUvZW5naW5lLmNv bmYuZC85OS1hbHRlcm5hdGUtZW5naW5lLWZxZG5zLmNvbmYuIEJ1dCBJIGZhaWxlZC4gSXQgc2Fp ZCB0aGF0ICJjYW4ndCBjb25uZWN0IHRvIHdlYnNvY2tldCBwcm94eSBzZXJ2ZXIgd3NzOi8vZW5n aW5lMS50ZXN0Lm9yZzo2MTAwIi4gU28gd2hlcmUgY2FuIEkgbW9kaWZ5IHRoaXMgd2Vic29ja2V0 IHByb3h5IHBhcmFtZXRlcj88L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBB bnlvbmUgY2FuIGhlbHA/IFRoYW5rcyE8L2Rpdj48L2Rpdj48YnI+PGJyPjxzcGFuIHRpdGxlPSJu ZXRlYXNlZm9vdGVyIj48cD4mbmJzcDs8L3A+PC9zcGFuPg== ------=_Part_152734_1156022334.1522057002223--

1 0

Re: [ovirt-users] VDSM SSL validity
by Punaatua PAINT-KOUI 26 Mar '18

26 Mar '18

I just tried, it works ! Thank for your help. Here are the steps that i followed: connect to the engine database using psql - use the request as you give it select fn_db_update_config_value(' VdsCertificateValidityInYears','2','general'); - verify the option by running select * from vdc_options where option_name like '%VdsCer%'; - restart ovirt-engine New host would have their certificates with the validity under 2 years. I tested with an existing host by put it in maintenance then reinstall Thanks ! those links helped me also: https://www.ovirt.org/develop/developer-guide/db-issues/dbupgrade/ https://www.ovirt.org/documentation/internal/database-upgrade-procedure/ 2018-03-23 17:52 GMT-10:00 Punaatua PAINT-KOUI <punaatua.pk(a)gmail.com>: > I just tried, it works ! Thank for your help. > > Here are the steps that i followed: > > connect to the engine database using psql > > - use the request as you give it select fn_db_update_config_value(' > VdsCertificateValidityInYears','2','general'); > > - verify the option by running select * from vdc_options where option_name > like '%VdsCer%'; > > - restart ovirt-engine > > New host would have their certificates with the validity under 2 years. I > tested with an existing host by put it in maintenance then reinstall > > Thanks ! > > those links helped me also: > > https://www.ovirt.org/develop/developer-guide/db-issues/dbupgrade/ > > https://www.ovirt.org/documentation/internal/database-upgrade-procedure/ > > > > 2018-03-22 0:49 GMT-10:00 Yedidyah Bar David <didi(a)redhat.com>: > >> On Thu, Mar 22, 2018 at 11:58 AM, Sahina Bose <sabose(a)redhat.com> wrote: >> > Didi, Sandro - Do you know if this option VdsCertificateValidityInYears >> is >> > present in 4.2? >> >> I do not think it ever was exposed to engine-config - I think it's a >> bug in that page. >> >> You should be able to update it with psql, if needed - something like >> this: >> >> select fn_db_update_config_value('VdsCertificateValidityInYears',' >> 2','general'); >> >> I didn't try this myself. >> >> To get an sql prompt, you can use engine-psql, which should be >> available in 4.2.2, >> or simply copy the script from the patch page: >> >> https://gerrit.ovirt.org/#/q/I4d9737ea72df0d7e654776a1085901284a523b7f >> >> Also, some people claim that the use of certificates for communication >> between >> the engine and the hosts is an internal implementation detail, which >> should not >> be relevant to PCI DSS requirements. See e.g.: >> >> https://ovirt.org/develop/release-management/features/infra/pkireduce/ >> >> > >> > On Mon, Mar 19, 2018 at 4:43 AM, Punaatua PAINT-KOUI < >> punaatua.pk(a)gmail.com> >> > wrote: >> >> >> >> Up >> >> >> >> 2018-02-17 2:57 GMT-10:00 Punaatua PAINT-KOUI <punaatua.pk(a)gmail.com>: >> >>> >> >>> Any idea someone ? >> >>> >> >>> Le 14 févr. 2018 23:19, "Punaatua PAINT-KOUI" <punaatua.pk(a)gmail.com> >> a >> >>> écrit : >> >>>> >> >>>> Hi, >> >>>> >> >>>> I setup an hyperconverged solution with 3 nodes, hosted engine on >> >>>> glusterfs. >> >>>> We run this setup in a PCI-DSS environment. According to PCI-DSS >> >>>> requirements, we are required to reduce the validity of any >> certificate >> >>>> under 39 months. >> >>>> >> >>>> I saw in this link >> >>>> https://www.ovirt.org/develop/release-management/features/infra/pki/ >> that i >> >>>> can use the option VdsCertificateValidityInYears at engine-config. >> >>>> >> >>>> I'm running ovirt engine 4.2.1 and i checked when i was on 4.2 how to >> >>>> edit the option with engine-config --all and engine-config --list >> but the >> >>>> option is not listed >> >>>> >> >>>> Am i missing something ? >> >>>> >> >>>> I thing i can regenerate a VDSM certificate with openssl and the CA >> conf >> >>>> in /etc/pki/ovirt-engine on the hosted-engine but i would rather >> modifiy the >> >>>> option for future host that I will add. >> >>>> >> >>>> -- >> >>>> ------------------------------------- >> >>>> PAINT-KOUI Punaatua >> >> >> >> >> >> >> >> >> >> -- >> >> ------------------------------------- >> >> PAINT-KOUI Punaatua >> >> Licence Pro Réseaux et Télecom IAR >> >> Université du Sud Toulon Var >> >> La Garde France >> >> >> >> _______________________________________________ >> >> Users mailing list >> >> Users(a)ovirt.org >> >> http://lists.ovirt.org/mailman/listinfo/users >> >> >> > >> >> >> >> -- >> Didi >> > > > > -- > ------------------------------------- > PAINT-KOUI Punaatua > Licence Pro Réseaux et Télecom IAR > Université du Sud Toulon Var > La Garde France > -- ------------------------------------- PAINT-KOUI Punaatua Licence Pro Réseaux et Télecom IAR Université du Sud Toulon Var La Garde France

1 0

Juniper vSRX Cluster on oVirt/RHEV
by Charles Kozler 26 Mar '18

26 Mar '18

Hi All - Recently did this and thought it would be worth documenting. I couldnt find any solid information on vsrx with kvm outside of flat KVM. This outlines some of the things I hit along the way and how to fix. This is my one small way of giving back to such an incredible open source tool https://ckozler.net/vsrx-cluster-on-ovirtrhev/

4 6

Re: [ovirt-users] Problem to upgrade level cluster to 4.1
by Arik Hadas 26 Mar '18

26 Mar '18

On Sun, Mar 25, 2018 at 3:06 PM, Marcelo Leandro <marceloltmm(a)gmail.com> wrote: > Good morning, > follow the log: > > The real name of vms : > VPS-Jarauto > VPS-Jarauto-Firewall > VPS-Varejo-Mais > > Thanks, > Thanks for sharing the log. Two of these VMs are configured with the custom-property 'macspoof'. That property is not supposed to be used since 4.0 (IIRC). Nevertheless, defining this property for version 4.1 should solve this problem, see [1]. The third VM is in a weird state - it cannot be updated because the host it runs on doesn't support the number of CPUs defined for this VM. You can either shut this VM down during the cluster upgrade or try to migrate it to another host with more CPUs available. Unfortunately, I can't correlate those issues with the VMs you mentioned, but if you'll start with with the first issue you'll find which one of them is that 'third VM'. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1373573 > > 2018-03-25 3:29 GMT-03:00 Arik Hadas <ahadas(a)redhat.com>: > >> >> >> On Fri, Mar 23, 2018 at 9:09 PM, Marcelo Leandro <marceloltmm(a)gmail.com> >> wrote: >> >>> Hello, >>> I am try update the cluster level but i had this menssage erro: >>> >>> Erro durante a execução da ação: Update of cluster compatibility version >>> failed because there are VMs/Templates [VPS-NAME01, VPS-NAME02, >>> VPS-NAME03] with incorrect configuration. To fix the issue, please go >>> to each of them, edit and press OK. If the save does not pass, fix the >>> dialog validation. >>> >>> >>> 23/03/2018 15:03:07 >>> Cannot update compatibility version of Vm/Template: [VPS-NAME01], >>> Message: [No Message] >>> 23/03/2018 15:03:07 >>> Cannot update compatibility version of Vm/Template: [VPS-NAME02], >>> Message: [No Message] >>> 23/03/2018 15:03:07 >>> Cannot update compatibility version of Vm/Template: [VPS-NAME03], >>> Message: [No Message] >>> >>> >>> I am already open the edit box vm and close with ok button how show in >>> the erro menssagem: >>> To fix the issue, please go to each of them, edit and press OK. If the >>> save does not pass, fix the dialog validation. >>> >>> But not return error when save. >>> >>> Anyone can help me ? >>> >> >> Can you please share the engine.log? >> >> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> >

2 1