Red Hat Bugzilla – Bug 1287066
[Cinder] Live preview fails to wake up a VM from hibernation
Last modified: 2016-02-18 06:17:17 EST
Description of problem:
VMs with cinder storage provider disks fail to perform a live preview (preview a snapshot with ram enabled) the ERROR being thrown in engine log:
"2015-12-01 12:09:31,629 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-99) [51d5c2a] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM vm_cinder_2 is down with error. Exit message: Wake up from hibernation failed:'_srcDomXML'."
After failure the machine rolled back and successfully boot from it's hd device.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.preview a live snapshot on a VM with ceph storage
Live preview fails to wake up a VM from hibernation
Live preview should be supported
Created attachment 1100862 [details]
Taking to storage to research. If we discover that Cinder is inconsequential here we may move it to the virt experts to research.
Reproduced the issue also with a VM with no disks. Seems like an old issue since the introduction of memory snapshots. Proposed a fix to vdsm.
Should we support previewing a memory snapshot without disks?
Currently, when previewing such a snapshot the VM fails to start due to an exception in vdsm (as mentioned in the description).
yeah, we do want to support that. It was not exercised too often (apparently), but there's no reason we shouldn't fix it.
However taking snapshot with RAM when the VM has direct LUNs or cinder...I don't think as a general case we should silently succeed when we don't ensure LUN/cinder is snapshot consistently as well. We should not allow resume without restoring the complete state of directly attached storage (as opposed to network-aware mounts like NFS)
oVirt 3.6.2 RC1 has been released for testing, moving to ON_QA
(In reply to Michal Skrivanek from comment #5)
> yeah, we do want to support that. It was not exercised too often
> (apparently), but there's no reason we shouldn't fix it.
> However taking snapshot with RAM when the VM has direct LUNs or cinder...I
> don't think as a general case we should silently succeed when we don't
> ensure LUN/cinder is snapshot consistently as well.
For Cinder we do, of course.