Description of problem: If a VM with block based storage is put into suspend mode (hibernation) it fails to come out when run. Version-Release number of selected component (if applicable): RHV 4.4.6 How reproducible: Every time Steps to Reproduce: 1.Select a VM with block based storage and suspend it 2.Select RUN to bring the VM out of hibernation 3.Fails to exit hibernation Actual results: Fails 100% of the time to exit from being suspended. The VM must be rebooted or shutdown to come back up and even then the state in the UI never goes to UP it stays at "Powering UP" or "Rebooting" Expected results: Should resume without any failures Additional info: This works as expected with file based storage. Customer also state dthat this was working in RHV 4.4.5 but stopped working after uograding to RHV 4.4.6
same as bz 1733804 and bz 1708031 that was supposed to be resolved by the fix for bz 1503468 but for latter was closed as WORKSFORME I managed to reproduce it as well
It seems to work for snapshots with memory and the handling of the memory volumes should be the same..
See https://bugzilla.redhat.com/show_bug.cgi?id=1503468#c77
How about creating a loopback device with --sizelimit in case the memory dump resides on a block device when restoring the memory?
Verified on RHV 4.4.9-4. All looks good to me. Env: - Engine instance with RHV 4.4.9-4 (ovirt-engine-4.4.9.1-0.13.el8ev) and RHEL 8.5 installed. - 3 Hosts with RHV 4.4.9-4 and RHEL 8.5, vdsm-4.40.90.2-1.el8ev, ovirt-engine-4.4.9.1-0.13.el8ev. Steps: In Admin Portal: 1. Create a 4.6 data center and a 4.6 cluster. 2. Install the hosts. 3. Add NFS, iSCSI and GlusterFS storage domains. 4. Create 3 RHEL 8.5 VMs, Each VM has a bootable disk in 1 of those storage domains. 5. Run the VMs. 6. Suspend the VMs. 7. Run the VMs. Results (As Expected): 1. The 4.6 data center and cluster were created. 2. The hosts were installed. 3. The NFS, iSCSI and GlusterFS storage domains were added. 4. The 3 RHEL 8.5 VMs were created. 5. The VMs ran. 6. The VMs were suspended. 7. The VMs ran successfully. Snapshot test: Setup: shutdown the VMs. 1. Run the iSCSI VM. 2. Create a snapshot with all disks. 3. Stop the VM. 4. Add 2 more iSCSI disks. 5. Start the VM. 6. Snapshot it with all disks. 7. Stop the VM. 8. Preview the first snapshot. 9. Run the VM (With all the disks/part of those. I checked both cases). 10. Suspend the VM. 11. Run the VM. Results: In steps 1, 5, 9, 11 the VM is running correctly without any error. In steps 3, 7 the VM is stopped. In steps 2, 6 The snapshot was created. In step 4, The disks were added. In step 8, The first snapshot is previewed. In step 10, The VM is suspended without any errors.
Tamir, only steps 10 and 11 are relevant in this context and what we are interested in the most is where the memory dump volume is stored We need to make sure that when suspending a VM and its memory dump volume resides on any of the three storages you have (especially iSCSI since we had a problem on block storage before), we are able to resume from suspension properly (not only that the VM runs but also that the memory is restored) Can you please make sure that is covered?
Verified on RHV 4.4.9-5. Thanks for the comment Arik. Env: - Engine instance with RHV 4.4.9-5 (ovirt-engine-4.4.9.2-0.6.el8ev) and RHEL 8.5 installed. - 3 Hosts with RHV 4.4.9-5 and RHEL 8.5, vdsm-4.40.90.2-1.el8ev, ovirt-engine-4.4.9.2-0.6.el8ev. Steps: In Admin Portal: 1. Create a 4.6 data center and a 4.6 cluster. 2. Install the hosts. 3. Add NFS, iSCSI and GlusterFS storage domains. 4. Create 3 RHEL 8.5 VMs, Each VM has a bootable disk in 1 of those storage domains. 5. Run the VMs. 6. Create a mount dir (mkdir /mnt/ramdisk) 7. Mount ramfs onto the mount dir (mount -t ramfs -o size=20m ramfs /mnt/ramdisk). 8. Create a small file with content in the mount dir. 9. Run Firefox and open 3 different tabs 10. Suspend the VMs. 11. Run the VMs. 12. Check that firefox is still open with those 3 tabs. 13. Check that the file contents match to those from step 8. * The NFS and GlusterFS are tested for regression purposes. Results (As Expected): 1. The 4.6 data center and cluster were created. 2. The hosts were installed. 3. The NFS, iSCSI and GlusterFS storage domains were added. 4. The 3 RHEL 8.5 VMs were created. 5. The VMs ran. 6. The mount dir was created. 7. The ramfs was mounted. 8. The file with content was created in the mount dir. 9. Firefox is running with 3 different tabs 10. The VMs were suspended. 11. The VMs ran successfully. 12. Firefox was still open with those 3 tabs. 13. The file exists with the same data. Snapshot test: Setup: shutdown the VMs. 1. Run the iSCSI VM. 2. Open Firefox with 3 different tabs 3. Create a snapshot with all disks. 4. Add 2 more iSCSI disks. 5. Snapshot it with all disks. 6. Stop the VM. 7. Preview the first snapshot. 8. Run the VM (With all the disks/part of those. I checked both cases). 9. Open another window of Firefox with one tab. 10. Suspend the VM. 11. Run the VM. 12. Check that all the Firefox instances are open as stated before. Results: In steps 1, 8, 11, the VM is running correctly without any error. In steps 6, the VM is stopped. In steps 3, 5, The snapshot was created. In step 4, The disks were added. In step 7, The first snapshot is previewed. In step 10, The VM is suspended without any errors. In steps 2, 9, a firefox window is opened with the number of tabs specified. In step 12, The firefox instances are still open with the same tabs.
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 (RHV RHEL Host (ovirt-host) [ovirt-4.4.9]), 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://access.redhat.com/errata/RHBA-2021:4704