Bug #335
Improve Unkown State Management
| Status: | Closed | Start date: | 09/03/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Ruben S. Montero | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | - | |||
| Resolution: | fixed | Pull request: | ||
| Affected Versions: | OpenNebula 3.4 |
Description
Currently if a machine is shutdown from within the machine (e.g. via halt), the VM lands eventually in the "unknown" state in OpenNebula. It would be more useful if some more descriptive tag were used for this, such as "halted". This would also help distinguish normal situations from abnormal ones. The virt-manager show machines halted internally as "stopped", so it appears that this information is available from libvirt.
This issue was originally reported by Charles Loomis from StratusLab
Associated revisions
bug #335: Solves seg fault in scheduler with empty strings
Install ESX packages for VNC firewall config. into $SHARE_LOCATION (#335)
History
#1
Updated by Shi Jin almost 11 years ago
I just started a VM using OpenNebula and run halt from the VM.
"virsh list --all" gives me nothing. How do I find the same information virt-manager has as you described.
In fact, I opened up my virt-manager and couldn't see anything.
Maybe it only has the information if the VM is started/shutdown by virt-manager?
Thanks.
Shi
#2
Updated by Carsten Friedrich over 10 years ago
It would also be good if CPU and memory allocations would be marked as free when a VM is in this state. E.g. I have very limited computing resources here and my users tend to use the VM internal shutdown rather than Stop when they don't need the VM. This leaves me with cloud nodes appearing as fully allocated in OpenNebula while in reality they don't have any work.
#3
Updated by Ruben S. Montero over 8 years ago
- Status changed from New to Closed
- Resolution set to fixed
- Affected Versions OpenNebula 3.4 added
Since 4.0 we have a couple more states like poweroff that may help with this. Also unknown state is better handled when a VM is restarted from unknown, finally the VM probes should be now capable of moving the VM to the right state (if not really unknown).
I think is better not to free resources until the VM is actually removed from the host.