Re: [Xen-users] 'xm list' states

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Petersson, Mats wrote:
> > 'c' (crashed) - The domain has crashed.
> > - If i do 'echo 1 > /proc/balloon' inside a unprivileged domain, i
> >   will get a kernel panic. But the state says nothing about that? The
> >   domain is definitively crashed, but the xm list command says nothing
> >   about that. Why?
> >     
> It may be that the crash isn't detected properly by hypervisor - I think
> this may only work under some circumstances. I don't know for sure, I'm
> just guessing here.
>   
A crash is when the domain does something that it shouldn't supposed to 
do and the hypervisor has to kill it.  I imagine that an OOM condition 
in the guest will invoke the normal shutdown routines which would 
explain why the state isn't crashed.
> > 'd' (dying) - The domain is in the process of dying.
> > - Well, poor little domain, but what does that mean?
> >     
> Something has told the domain to "kill itself" (such as "xm
> shutdown/destroy", but it's not yet disappeared. It's probably there for
> the purpose of avoiding race-conditions where something is killing the
> domain, and something else is talking to it (for example disk accesses),
> and we don't want to retry operations that fail because the domain is
> disappearing - where it would make sense to retry it on a "living"
> Domain. 
>   
Actually, dying specifically means that xc_domain_destroy() has been 
invoked on a domain.  In turn, this means that the domain's resources 
have been deallocated.  The reason this state is needed is because of 
the way memory sharing works.  If another domain maps a portion of a 
guests memory, then that domain can not be completely removed from the 
system until the domain unmaps that memory (since you can not forcefully 
break that mapping).
If you ever see a domain in a dying state for more than a moment, 
chances are, it's a zombie and there's a bug somewhere keeping a domain 
from unmapping a small portion of the guests memory.
The 's' flag means the domain is in the shutdown state.  The shutdown 
state is initiated when the guest signals to the hypervisor to put 
itself in the shutdown state.  Once in the shutdown state, a domain 
cannot escape from it.  When you do something like an xm shutdown, what 
happens is that you signal to the guest to do a shutdown, it puts itself 
in the 's' state, the control tools see that the domain has entered a 
shutdown state, and signal to the appropriate backend drivers to release 
the guests memory.  Then, the control tools do a destroy() on the domain 
which will cause it to actually disappear.
There a few substates associated with the shutdown state: halt, reboot, 
and suspend.  Halt and reboot are rather obvious (a guest wishes to be 
halted or rebooted).  The suspend state is used for save/restore and 
migration.  Before the guest enteres the suspend substate, it first 
canonicalizes any of it's internal PFN references and jumps to a special 
location in the kernel.  What's special about this is that the domain's 
image can now be safely copied into a new domain shell and when 
execution begins again, the kernel will start a recovery routine that 
reinitializes devices and internal PFNs.
You cannot unsuspend a domain in place though which is certainly a 
disadvantage in the current design (as it prevents light weight 
checkpointing).  The same applies to rebooting which is a little 
unfortunate.
Regards,

Anthony Liguori

> > Maybe anybody here who can clearify the meanings of the 
> > state. The manual page is not very helpful.
> >     
> I hope this is of some help. 
>
> --
> Mats
>   
> > Many Thanks and greetings,
> > -timo
> > --
> > Timo Benk
> > PGP Public Key: http://vs241071.vserver.de/timo_benk_gpg_key.asc
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-users
> >
> >
> >     
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>   

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users