[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] current domU lifecycle work
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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our