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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel