Created attachment 1067759 [details] engine.log, vdsm.log Description of problem: If you preview a snapshot (with memory) and then before you start the VM you make VM properties modification like removing/adding network card, engine backend won't take this changes immediately into account and it will start VM with VM settings from snapshot. This brings surprises like having inside OS network interface with "old" hwaddr. There should be two solutions: - if previewing snapshot with memory, VM properties changes should be forbidden - if previewing snapshot with memory, VM properties changes should drop VM memory restoration and the user doing this should be informed with a dialog Version-Release number of selected component (if applicable): rhevm-backend-3.6.0-0.11.master.el6.noarch How reproducible: 100% Steps to Reproduce: 1. create a VM with a network card 2. start VM, install some OS 3. make snapshot 4. power off the VM 5. preview snapshot, check "old" nic hwaddr, select include memory (select snapshot -> right pane 'Network Interfaces/MAC') 6. remove nic 7. add nic with user defined hwaddr 9. start VM 10. check inside OS 11. check libvirt via dumpxml Actual results: old hwaddr, VM settings were restored from memory and user changes were not accepted for (first) run Expected results: either changes should be forbidden or better there should be warning that modification of previewing snapshot with memory would cause memory restore to to be dropped Additional info:
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
I would say a Preview with memory should be restored as a running VM.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
oVirt 4.0 beta has been released, moving to RC milestone.
(In reply to Michal Skrivanek from comment #2) > I would say a Preview with memory should be restored as a running VM. I suppose a "Paused" VM is even better Too late for 4.0, but it was brought up several times in similar flows, and the behavior is really difficult to predict then
Created attachment 1668454 [details] Preview with restore memory I reviewed this issue up to the following step: preview snapshot, check "old" nic hwaddr, select include memory (select snapshot -> right pane 'Network Interfaces/MAC') But as per the snap shot, the only checkbox is for restoring memory. There is also a custom preview, but it is not clear where one would check the old nic hardware, nor select the memory there.
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.
This bug has not been prioritized or updated for a long time and therefore deemed stale. Closing for now, please feel free to update and reopen, but kindly provide justification or development plan how/when to address this bug
(In reply to Michal Skrivanek from comment #5) > (In reply to Michal Skrivanek from comment #2) > > I would say a Preview with memory should be restored as a running VM. > > I suppose a "Paused" VM is even better maybe "Suspended" is the more accurate equivalent of that state (as there is no QEMU process running, and memory dump is restored when starting the VM) I think it's time to sort this out for "Suspended" state as well
sure, what do you want to do?
(In reply to Michal Skrivanek from comment #12) > sure, what do you want to do? I think the most reasonable thing to do is to set the status of the VM to suspended when it is set to restore memory state Sure, it would mean that a VM might get into suspend state when there was no 'suspend' operation before and we may need to rephrase some validation errors to cope with that, but I think that makes the most sense With that, changes to VMs that are set to preview/commit to a memory snapshot would turn into next-run configuration as those VMs that were suspended. But need to check how it affects the snapshot operations - we should still allow to cancel previewing a memory snapshots for instance and having the vm in suspend state may prevent this.
(In reply to Arik from comment #13) > With that, changes to VMs that are set to preview/commit to a memory > snapshot would turn into next-run configuration as those VMs that were > suspended. That's something I discovered after writing comment 11, I thought we have the same issue also for suspended VMs before
This BZ is referenced by https://github.com/oVirt/ovirt-engine/pull/516 ; moving to POST?
Verification builds: ovirt-engine-4.5.2.2-0.1.el8ev vdsm-4.50.2.2-1.el8ev.x86_64 libvirt-8.0.0-5.3.module+el8.6.0+16162+08e7975b.x86_64 qemu-kvm-6.2.0-11.module+el8.6.0+15668+464a1f31.2.x86_64 Verification scenario: 1. create a VM with a network card 2. start VM, install some OS 3. make snapshot 4. power off the VM 5. preview snapshot, select include memory Verify VM is now in "suspended" state Verify it's impossible to remove VM NIC while VM is suspended. 6. start VM Verify VM is running and functional.
This bugzilla is included in oVirt 4.5.2 release, published on August 10th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.