-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restoring snapshot causes VM to go to suspended state #1629
Comments
This is well reproduced on oVirt >= 4.5.2 as a result of this fix oVirt/ovirt-engine#516 And specifically due to this line fix: https://github.com/ahadas/ovirt-engine/blob/6ce8656a5817302f1ce4e81cdbd5951630299e6d/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/snapshots/SnapshotsManager.java#L460-L462
Since for snapshots created via web-ui, DetailsWhen restoring a snapshot via web-ui:
SolutionIt seems that a fix should be done on web-ui by adding the |
Previously, when trying-back/restoring a snapshot that doesn't have memory while the client requested to restore memory, the VM would have switched to Suspended state. Now, the VM is set to Suspended only when the active snapshot, the snapshot that was created by the trying-back/restore operation, is set with memory volumes. Otherwise, the VM is set to Down. See: oVirt/ovirt-web-ui#1629 Signed-off-by: Arik Hadas <ahadas@redhat.com>
Since the API is also affected by this, it's better to solve it on the backend side |
Previously, when trying-back/restoring a snapshot that doesn't have memory while the client requested to restore memory, the VM would have switched to Suspended state. Now, the VM is set to Suspended only when the active snapshot, the snapshot that was created by the trying-back/restore operation, is set with memory volumes. Otherwise, the VM is set to Down. See: oVirt/ovirt-web-ui#1629 Signed-off-by: Arik Hadas <ahadas@redhat.com>
Ok so it sounds like if a VM snapshot is restored, the VM can end up with a state of:
Engine PR oVirt/ovirt-engine#516 touched it and PR oVirt/ovirt-engine#653 looks to be fixing the issue underlying this issue. @isaranova - Is that your understanding? If you restore a VM snapshot with memory on webadmin, does the VM end in the Suspended status? If you restore a VM snapshot without memory on web-ui, does the VM end in Down status? I'm guessing this issues isn't really an issue and what you're seeing is just the way it is supposed to work now. @sgratch - From web-ui, if the VM is running, a snapshot can be created with memory. That attribute does flow through the snapshot create action. The On the restore action, the service and web-ui defaults to restoring the memory (if available in the snapshot) by not explicitly specifying the parameter in the action POST. API doc: http://ovirt.github.io/ovirt-engine-api-model/master/#services/snapshot/methods/restore. I don't think it make sense to say "don't restore the memory even if it exists" just to force all restores to leave a VM down. @ahadas - I agree with your assessment. The issue, if there actually is one, is best handled on the backend/engine side. |
Previously, when trying-back/restoring a snapshot that doesn't have memory while the client requested to restore memory, the VM would have switched to Suspended state. Now, the VM is set to Suspended only when the active snapshot, the snapshot that was created by the trying-back/restore operation, is set with memory volumes. Otherwise, the VM is set to Down. See: oVirt/ovirt-web-ui#1629 Signed-off-by: Arik Hadas <ahadas@redhat.com>
@sjd78 @isaranova On webamdin it worked as expected and suspended only when memory was really included. The current behavior after the fix should be the same for webadmin and web-ui as follows:
The |
@isaranova @santos1709 the fix was done on engine backend so closing and moving the ticket to QE's verification, just to make sure that it's fixed for web-ui use case. |
Versions:
ovirt-engine-4.5.2.5-0.1.el8ev.noarch
ovirt-web-ui-1.9.1-1.el8ev.noarch
firefox-104.0-5.fc36.x86_64
Steps to Reproduce:
Actual results:
VM is suspended.
Expected results:
VM is still powered off.
Additional info:
This isn't happening in Admin Portal.
The text was updated successfully, but these errors were encountered: