+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1821164 +++ ====================================================================== Description of problem: When a snapshot creation fails on timeout, the engine will trigger rollback of the operation and remove the snapshot volumes even though the snapshot is finished on the hypervisor. Version-Release number of selected component (if applicable): 4.3.7 How reproducible: 100% Steps to Reproduce: 1. Trigger live snapshot of a VM which is not running on SPM 2. Make freeze fs to get stuck for 10 min (To breach all the timeouts) Actual results: The related volumes are removed on the SPM, but the VM finished the snapshot and using it. Expected results: The snapshot is either stopped completely or the volumes are not removed without the confirmation that they are not used by any VM. Additional info: This is very dangerous situation as other VMs can allocate the extends of the removed LVs. This will cause data corruption as two VMs may write to the same are. (Originally by Roman Hodain)
This issue may get fixed by Bug 1749284 - Change the Snapshot operation to be asynchronous But there may still be potential for this behaviour if we do not handle all the corner cases properly. (Originally by Roman Hodain)
Benny, you think it will be possible to check the Domain XML dump to figure out if the VM is currently using an image that we are going to rollback and in that case roll forward? (Originally by Tal Nisan)
(In reply to Tal Nisan from comment #9) > Benny, you think it will be possible to check the Domain XML dump to figure > out if the VM is currently using an image that we are going to rollback and > in that case roll forward? It's strange because we have this check[1], I checked the logs and it seems the xml dump didn't contain the new volumes so from engine POV they weren't used (they are part of the dump later on, when live merge runs), I didn't find logs from host when the VM runs so not entirely sure what happened [1] https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/snapshots/CreateSnapshotCommand.java#L216 (Originally by Benny Zlotnik)
well, there's timing to consider between getVolumeChain() and actual removal. Would be best to have such a check on vdsm side, perhaps? As a safeguard in case engine decides to delete an active volume....for whatever reason. (Originally by michal.skrivanek)
(In reply to Michal Skrivanek from comment #11) > well, there's timing to consider between getVolumeChain() and actual > removal. Would be best to have such a check on vdsm side, perhaps? As a > safeguard in case engine decides to delete an active volume....for whatever > reason. yes, read the bug over, and if the snapshot creation didn't reach the call to libvirt we'll still see the original chain (in the previous bug freeze passed fine, the memory dump took too long)... so we can't really do this reliably in the engine (Originally by Benny Zlotnik)
Do we have a way to tell if a volume is used by a VM in vdsm though? Image removal is an SPM operation Maybe we can acquire a volume lease and inquire when trying to delete (Originally by Benny Zlotnik)
Here is one observation. The snapshot creation continued after we received: 2020-03-30 20:45:13,918+0200 WARN (jsonrpc/0) [virt.vm] (vmId='cdb7c691-41be-4f96-808c-4d4421462a36') Unable to freeze guest filesystems: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': timeout when try to receive Frozen event from VSS provider: Unspecified error (vm:4262) This is generated by the qemu agent. The agent waits for the fsFreeze even for 10s, but this message was reported minutes after the fsFreeze was initiated. So the guest agent may get stuck even before triggering the freeze. Would it be better not to rely on the agent and simply fail the fsFreeze according to a timeout suitable for the vdsm workflow? We can see that this operation can be blocking. (Originally by Roman Hodain)
The snapshot creation completed successfully and ready to be used Verified with the following steps: 1. Adding sleep to the host at /usr/lib/python2.7/site-packages/vdsm/virt/vm.py 2. Restart vdsmd 3. On the engine engine-config -s LiveSnapshotPerformFreezeInEngine=true 4. Restart ovirt-engine service 5. Run the new VM on the host [1] 6. Create a snapshot without memory **For this moment the LiveSnapshotPerformFreezeInEngine configured by default to true. ovirt-engine-4.3.10.4-0.1.el7.noarch vdsm-4.30.46-1.el7ev.x86_64 libvirt-4.5.0-33.el7_8.1.x86_64