Red Hat Bugzilla – Bug 1191729
[3.5_6.6] - VM fails to start in snapshot preview mode with a RAM snapshot
Last modified: 2016-02-10 15:02:43 EST
Description of problem: If a live snapshot of a VM is taken with 'Save Memory' selected, and that snapshot is later previewed with 'Restore Memory' selected, then the VM will fails to start. VDSM reports; Thread-49::ERROR::2015-02-11 20:06:19,190::vm::2324::vm.Vm::(_startUnderlyingVm) vmId=`3b8bd683-c75d-413b-b58c-b3ad20dada54`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2264, in _startUnderlyingVm File "/usr/share/vdsm/virt/vm.py", line 3307, in _run File "/usr/lib/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper File "/usr/lib64/python2.6/site-packages/libvirt.py", line 3225, in restoreFlags libvirtError: unsupported configuration: Target controller type ide does not match source usb If the snapshot is previewed without 'Restore Memory' selected, then the VM will start up successfully. This is not a problem in a 3.4 environment with a RHEL 6.5 host with 'vdsm-4.14.13-2' and 'libvirt-0.10.2-46'. Version-Release number of selected component (if applicable): RHEV 3.5 RC build (rhevm-3.5.0-0.29) RHEV-H 6.6 20150114.0 - vdsm-4.16.8.1-5 - libvirt-0.10.2-46.el6_6.2 How reproducible: Fails every time for me. Steps to Reproduce: 1. Take a live VM snapshot with 'Save Memory' selected. 2. Shutdown VM. 3. Preview the snapshot with 'Restore Memory' selected. 4. VM fails to start, "Target controller type ide does not match source usb". 5. Undo snapshot. 6. Preview the snapshot without 'Restore Memory' selected. 7. VM starts successfully. If steps 1-4 are performed in 3.4 on RHEL 6.5 host with 'vdsm-4.14.13-2' and 'libvirt-0.10.2-46' then the VM will start without a problem. Actual results: VM fails to start. Expected results: VM should start. Additional info:
Hi, I tried to reproduce in rhevm-3.5.0-0.31.el6ev.noarch env with several hosts: 1. same steps as in description with RHEL 7 host - vdsm-4.16.8.1-6.el7ev. libvirt-1.1.1-29.el7_0.7. bug didn't re produce. 2. same with RHEL 6.5 host on 3.4 cluster with - vdsm-4.14.18-6.el6ev libvirt-0.10.2-29.el6_5.13 bug didn't re produce. 3. same again with RHEL 6.6 host with - vdsm-4.16.8.1-6.el6ev libvirt-0.10.2-46.el6_6.3 bug didn't re produce. 4. same with RHEV Hypervisor - 6.6 - 20150128.0.el6ev vdsm-4.16.8.1-6.el6ev libvirt-0.10.2-46.el6_6.2 bug re produced with the same error as mentioned in description. In my case, the vm then migrated to the RHEL 6.6 on the same cluster and then went up. So it seems it's a RHEV-H bug only, or it's a libvirt-0.10.2-46.el6_6.2 bug which is fixed on: libvirt-0.10.2-46.el6_6.3
Changing the component according to the findings in comment 6 - this is caused by an outdated libvirt build.
see comment 6, comment 7 and comment 8 Verified this bug on rhev-hypervisor6-6.6-20150312.0 # rpm -q libvirt libvirt-0.10.2-46.el6_6.3.x86_64 # cat /etc/system-release Red Hat Enterprise Virtualization Hypervisor 6.6 (20150312.0.el6ev)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0902.html