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