Bug #4056
Snapshot revert problems
| Status: | Closed | Start date: | 10/14/2015 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Ruben S. Montero | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | Release 4.14.2 | |||
| Resolution: | fixed | Pull request: | ||
| Affected Versions: | OpenNebula 4.14 |
Description
- revert procedure completes, although TM_MAD/snap_revert is returning error exit code. So I've implemented extra measure to have proper VM disk/checkpoint for the rest of the process
- From this state I can not PowerOff(hard) the VM to re-restore from a snapshot - hard PowerOff not woring when VM is stuck in VM BIOS.
- in oned.log DISKSNAPSHOTCREATE is logged at the end of the restore procedure:
Related issues
Associated revisions
bug #4056: return correct action in disk snap revert
bug #4056: return correct action in disk snap revert
(cherry picked from commit ea53ff904b4dbab80cbf7e77a0cbc8f05b26b51d)
History
#1
Updated by Ruben S. Montero over 5 years ago
- Related to Bug #4055: disk snapshot restore while VM is running is leading to broken VM added
#2
Updated by Anton Todorov over 5 years ago
... VM is stuck in VM BIOS.
For example when the root disk is not booting for some reason.
#3
Updated by Ruben S. Montero over 5 years ago
- Assignee set to Ruben S. Montero
#4
Updated by Ruben S. Montero over 5 years ago
- Status changed from Pending to Closed
- Resolution set to fixed
Hi
About the issues described here:
- DISKSNAPSHOTCREATE, has been fixed
- The BIOS issue seems not related with OpenNebula
- TM_MAD/snap exit code has been fixed for snap_create_live
We still have this issue when the :detach or :suspend strategy are used. We are proposing to remove those alternatives and either relay on snap_create_live (for VMs in RUNNING) or use snap_create (you need to manually move the VM to POWEROFF). We believe this is a more robust approach, and safer for the user. I am opening a separate issue for 5.0 for the latter.
Updated by