Re: current domU lifecycle work

["Andrew D. Ball" <aball@us.ibm.com>]

Thanks for your detailed reply.

I think the configuration file based persistence is part
of stage 3 of Anthony Liguori's XML-RPC work for xend.  I hope
to see some XSDL schemas for domU configurations and would be
glad to help organize/write these if I can.

I'll let you know if I can get some time to work on the /vm
cleanup.  Probably not, but I'll try to find some.

Thanks again for your help!
Andrew
===========
Andrew D. Ball <aball@us.ibm.com>

Ewan Mellor wrote:
> On Thu, Mar 09, 2006 at 05:14:08PM -0500, Andrew D. Ball wrote:
> 
> 
>>Is anyone working on supporting different types of domU
>>lifecycles at the moment?
> 
> 
> No, not really.  I'm doing general Xend maintenance, but other than the bug
> discussed below, I'm not looking at this problem in particular, and I'm not
> aware of anyone else doing so.
> 
> 
>>Ignoring configuration file based domU persistence, I'm
>>told that it's possible to have a domU stay around in xenstore
>>after shutting it down, but that I ought not to do
>>that because it's buggy.
> 
> 
> There are two parts to a domU -- the "domain" and the "VM" in Xend parlance.
> The VM is the guest, as far as we might expect a user to see it, and the
> domain is an actual running instance of a VM.  A VM persists across a reboot
> or a migration, a domain does not.
> 
> As far as I am aware, everything wrt the domain is swept up properly.
> 
> Because the VM must outlive a reboot, sweeping up after the VM is more
> complicated, and at the moment, it's buggy -- the VM details are left in the
> store forever.  I consider this a bug precisely because no-one has put any
> effort into VM lifecycles as you suggest.  The details live on in the store,
> but there's no way to clean them up, or even make use of them given that they
> are there.
> 
> The easiest way to solve this problem is to say that the VM lives on a
> particular host between xm create and one of xm migrate, xm shutdown, or xm
> destroy.  Then, if you want the VM to outlive those operations, then you
> should manage that externally, since you probably want it to interact with
> your cluster management software and whathaveyou anyway.  You seem to name
> this "config file persistence".  This is the easiest way to solve the problem,
> but it's not necessarily the best, of course.
> 
> That model is the one being used at the moment, modulo the bug that entries in
> the store often don't go away properly.  If you want to improve this model,
> allowing for in-store persistence of VMs, then you are more than welcome to do
> so.  Bear in mind that although the store can technically persist across a
> reboot at the moment, many people delete the store on reboot anyway, precisely
> because it has a tendency to get crufty at the moment, and people have given
> thought in the past as to whether we ought to make that the default.  Perhaps
> VM config is better in some other database...
> 
> If you want to fix the cleanup of the store after a VM dies, then you're
> welcome to do that at the same time (though let me know because it's on my
> list, and I might get around to it some day soon!)
> 
> Ewan.