- Users - oVirt List Archives

[ANN] oVirt 4.2.2 GA Release is now available
by Lev Veyde 28 Mar '18

28 Mar '18

The oVirt Project is pleased to announce the availability of the oVirt 4.2.2 GA release, as of March 28th, 2018. This update is a GA release of the second in a series of stabilization updates to the 4.2 series. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is available - oVirt Node is available [2] Additional Resources: * Read more about the oVirt 4.2.2 release highlights: http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.2/>2 <http://www.ovirt.org/release/4.2.2/>. <http://www.ovirt.org/release/4.2.2/> 2 <http://www.ovirt.org/release/4.2.2/>/ <http://www.ovirt.org/release/4.2.2/> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.2/>2 <http://www.ovirt.org/release/4.2.2/>. <http://www.ovirt.org/release/4.2.2/> 2 <http://www.ovirt.org/release/4.2.2/>/ <http://www.ovirt.org/release/4.2.2/> [2] http://resources.ovirt.org/pub/ovirt-4. <http://resources.ovirt.org/pub/ovirt-4.2/iso/>2 <http://resources.ovirt.org/pub/ovirt-4.2/iso/>/iso/ <http://resources.ovirt.org/pub/ovirt-4.2/iso/> -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

Deploy Self-Hosted Engine in a Active Host
by FERNANDO FREDIANI 28 Mar '18

28 Mar '18

Hello As I mentioned in another thread I am migrating a 'Bare-metal' oVirt-Engine to a Self-Hosted Engine. For that I am following this documentation: https://ovirt.org/documentation/self-hosted/chap-Migrating_from_Bare_Metal_… However I think called me attention and I wanted to clarity: Must the Host that will deploy the Self-Hosted Engine be in Maintenance mode and therefore with no other VMs running ? I have a Node which is currently part of a Cluster and wish to deploy the Self-Hosted Engine to it. Must I have to put it into Maintenance mode first or can I just run the 'hosted-engine --deploy'. Note: this Self-Hosted Engine will manage the existing cluster where this Node exists. Guess that is not an issue at all and part of what Self-Hosted Engine is intended to. Thanks Fernando

1 0

oVirt Node Resize tool for local storage
by Matt Simonsen 28 Mar '18

28 Mar '18

Hello, We have a development box with local storage, running ovirt Node 4.1 It appears that using the admin interface on port 9090 I can resize a live partition to a smaller size. Our storage is a seperate LVM partition, ext4 formated. My question is, both theoretically and practically, if anyone has feedback on: #1: Does this work (ie- will it shrink the filesystem then shrink the LV)? #2: May we do this with VMs running? Thanks Matt

3 2

Re: [ovirt-users] Snapshot of the Self-Hosted Engine
by FERNANDO FREDIANI 28 Mar '18

28 Mar '18

Hello Sven and all. Yes storage does have the snapshot function and could be possibility be used, but I was wondering a even easier way through the oVirt Node CLI or something similar that can use the qcow2 image snapshot to do that with the Self-Hosted Engine in Global Maintenance. I used to run the oVirt Engine in a Libvirt KVM Virtual Machine in a separate Host and it has always been extremely handy to have this feature. There has been times where the upgrade was not successfully and just turning off the VM, starting it from snapshot saved my day. Regards Fernando 2018-03-27 14:14 GMT-03:00 Sven Achtelik <Sven.Achtelik(a)eps.aero>: > Hi Fernando, > > > > depending on where you’re having your storage you could set everything to > global maintenance, stop the vm and copy the disk image. Or if your storage > systeme is able to do snapshots you could use that function once the engine > is stopped. It’s the easiest way I can think of right now. What kind of > storage are you using ? > > > > Sven > > > > *Von:* users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] *Im > Auftrag von *FERNANDO FREDIANI > *Gesendet:* Dienstag, 27. März 2018 15:24 > *An:* users > *Betreff:* [ovirt-users] Snapshot of the Self-Hosted Engine > > > > Hello > > Is it possible to snapshot the Self-Hosted Engine before an Upgrade ? If > so how ? > > Thanks > > Fernando >

1 0

Snapshot of the Self-Hosted Engine
by FERNANDO FREDIANI 28 Mar '18

28 Mar '18

Hello Is it possible to snapshot the Self-Hosted Engine before an Upgrade ? If so how ? Thanks Fernando

3 2

Ping::(action) Failed to ping x.x.x.x, (4 out of 5)
by info＠linuxfabrik.ch 28 Mar '18

28 Mar '18

Hi all, we randomly and constantly have this message in our /var/log/ovirt- hosted-engine-ha/broker.log: /var/log/ovirt-hosted-engine-ha/broker.log:Thread-1::WARNING::2018-03- 27 08:17:25,891::ping::63::ping.Ping::(action) Failed to ping x.x.x.x, (4 out of 5) The pinged device is a switch (not a gateway). We know that a switch might drop icmp packets if it needs to. The interesting thing about that is if it fails it fails always at "4 out of 5", but in the end (5 of 5) it always succeeds. Is there a way to increase the amount of pings or to have another way instead of ping? Regards Markus

2 1

Testing oVirt 4.2
by wodel youchi 27 Mar '18

27 Mar '18

Hi, I am testing oVirt 4.2, I am using nested KVM for that. I am using two hypervisors Centos 7 updated and the hosted-Engine deployment using the ovirt appliance. For storage I am using iscsi and NFS4 Versions I am using : ovirt-engine-appliance-4.2-20180214.1.el7.centos.noarch ovirt-hosted-engine-setup-2.2.9-1.el7.centos.noarch kernel-3.10.0-693.21.1.el7.x86_64 I have a problem deploying the hosted-engine VM, when configuring the deployment (hosted-engine --deploy), it asks for the engine's hostname then the engine's IP address, I use static IP, in my lab I used *192.168.1.104* as IP for the VM engine, and I choose to add the it's hostname entry to the hypervisors's /etc/hosts But the deployment get stuck every time in the same place : *TASK [Wait for the host to become non operational]* After some time, it gave up and the deployment fails. I don't know the reason for now, but I have seen this behavior in */etc/hosts *of the hypervisor. In the beginning of the deployment the entry *192.168.2.104 engine01.example.local* is added, then sometime after that it's deleted, then a new entry is added with this IP *192.168.122.65 engine01.wodel.wd* which has nothing to do with the network I am using. Here is the error I am seeing in the deployment log 2018-03-24 11:51:31,398+0100 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:100 TASK [Wait for the host to become non operational] 2018-03-24 12:02:07,284+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 {u'_ansible _parsed': True, u'_ansible_no_log': False, u'changed': False, u'attempts': 150, u'invocation': {u'module_args': {u'pattern': u'name=hyperv01.wodel.wd', u'fetch_nested': False, u'nested_attributes': []}}, u'ansible_facts': {u'ovirt_hosts': []}} 2018-03-24 12:02:07,385+0100 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:98 fatal: [loc alhost]: FAILED! => {"ansible_facts": {"ovirt_hosts": []}, "attempts": 150, "changed": false} 2018-03-24 12:02:07,587+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 PLAY RECAP [engine01.wodel.wd] : ok: 15 changed: 8 unreachable: 0 skipped: 4 failed: 0 2018-03-24 12:02:07,688+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 PLAY RECAP [localhost] : ok: 41 changed: 14 unreachable: 0 skipped: 3 failed: 1 2018-03-24 12:02:07,789+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:180 ansible-playbook rc: 2 2018-03-24 12:02:07,790+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:187 ansible-playbook stdou t: 2018-03-24 12:02:07,791+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:189 to retry, use: --limi t @/usr/share/ovirt-hosted-engine-setup/ansible/bootstrap_local_vm.retry 2018-03-24 12:02:07,791+0100 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:190 ansible-playbook stder r: 2018-03-24 12:02:07,792+0100 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/misc.py", line 186, in _closeup r = ah.run() File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/ansible_utils.py", line 194, in run raise RuntimeError(_('Failed executing ansible-playbook')) RuntimeError: Failed executing ansible-playbook 2018-03-24 12:02:07,795+0100 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Closing up': Failed exec uting ansible-playbook any idea???? Regards

3 3

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