Bug #2488
A failed resume action will destroy and recreate the VM on the next resume
| Status: | Closed | Start date: | 11/21/2013 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Carlos Martín | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | Release 4.14 | |||
| Resolution: | fixed | Pull request: | ||
| Affected Versions: | OpenNebula 4.10, OpenNebula 4.12, OpenNebula 4.6, OpenNebula 4.8 |
Description
After a resume, the VM goes through the states pending -> prolog_resume/_undeploy.
To decide that the VM should go into prolog_resume/_undeploy instead of the regular prolog, we look for the previous history action. But if the prolog fails for any reason, we move the VM back to stopped/undeployed with a new history entry, reason NONE.
The next time the VM is resumed, the core will move it to the regular prolog state, creating a new VM from scratch instead of using the existing disks and checkpoint.
Related issues
History
#1
Updated by Ruben S. Montero over 7 years ago
- Target version changed from Release 4.4 to Release 4.6
#2
Updated by Ruben S. Montero over 7 years ago
- Target version changed from Release 4.6 to Release 4.8
#3
Updated by Ruben S. Montero about 7 years ago
- Target version deleted (
Release 4.8)
#4
Updated by Carlos Martín over 6 years ago
- Related to Bug #3235: Delete --recreate coming from Stop state should not attempt a resume added
#5
Updated by Carlos Martín over 6 years ago
- Related to Feature #3654: Implement extra VM state transitions added
#6
Updated by Ruben S. Montero about 6 years ago
- Status changed from New to Closed
- Target version set to Release 4.14
- Resolution set to fixed
- Affected Versions OpenNebula 4.10, OpenNebula 4.12, OpenNebula 4.6, OpenNebula 4.8 added
Now, a VM can go to the UNDEPLOYED/STOPPED state after a successful epilog. The prolog_failed transition (that added the new history record) has been removed.