current domU lifecycle work ?

current domU lifecycle work ?

[Andrew D. Ball]

Is anyone working on supporting different types of domU
lifecycles at the moment?

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.

Having the following primitives supports more
lifecycle models than the behavior I see from xm
create and xm destroy, where xm destroy causes xend
to forget about the domU:

(1) register a domU with xend (initializes a configuration
in xenstore)
(2) turn on that domU
(3) turn off that domU (without removing it from xenstore)
(4) unregister that domU with xend (this is destroying the
domU).

The lifecycle model where domU's disappear after being
shutdown is great for lots of applications like
grid computing and build systems that leave output
and disappear.  However, it does not support nearly as
many lifecycle models as the four primitives above.

Is anyone working on stabilizing this?  Have I overlooked
anything?

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

Re: current domU lifecycle work ?

[Harry Butterworth]

On Thu, 2006-03-09 at 17:14 -0500, Andrew D. Ball wrote:

> (1) register a domU with xend (initializes a configuration
> in xenstore)
> (2) turn on that domU
> (3) turn off that domU (without removing it from xenstore)
> (4) unregister that domU with xend (this is destroying the
> domU).

> Is anyone working on stabilizing this?  Have I overlooked
> anything?

Nested within on and off there is save and restore.  Also, at any time
there is migration.  I guess there should be an option to clone.  Then
you have snapshotting and roll-back.  I expect there is more.

Harry.

Re: current domU lifecycle work ?

[Ewan Mellor]

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.