From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew D. Ball" Subject: Re: current domU lifecycle work Date: Mon, 13 Mar 2006 16:58:51 -0500 Message-ID: <4415EB1B.60903@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 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.