Bug #335

Improve Unkown State Management

Added by Ruben S. Montero almost 11 years ago. Updated over 8 years ago.

Status:ClosedStart date:09/03/2010
Priority:NormalDue date:
Assignee:Ruben S. Montero% Done:


Category:Core & System
Target version:-
Resolution:fixed Pull request:
Affected Versions:OpenNebula 3.4


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

Revision 3448f869
Added by Ruben S. Montero almost 11 years ago

bug #335: Solves seg fault in scheduler with empty strings

Revision ac248360
Added by Vlastimil Holer about 4 years ago

Install ESX packages for VNC firewall config. into $SHARE_LOCATION (#335)


#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?


#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.

Also available in: Atom PDF