From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Smith Subject: Re: changeset:6989 vm sticking around in shutdown state Date: Thu, 22 Sep 2005 07:22:29 -0700 Message-ID: <87br2lb2sa.fsf@us.ibm.com> References: <1127394791.23958.283.camel@pluto.linsolutions.com> <87oe6lb3xy.fsf@us.ibm.com> <1127398211.23958.315.camel@pluto.linsolutions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Ted Kaczmarek Cc: xen-devel List List-Id: xen-devel@lists.xenproject.org TK> Sound like a good starting point, you thinking about appending an TK> instance to the name? We previously discussed adding something like -zombie-X to the name, where X is the old numeric domid. That would make it evident that the domain was hanging around after death. TK> I am of the mindset that something like allow creation with the TK> same name, but invalidate the old one or vice versa. Yea, so, since Xend looks things up mostly by name, we need to create the new domain with the real name, and mangle the name of the zombie so that it mostly gets ignored. TK> This would also keep track of how many times such an issue occured TK> on a particular domU. Well, it would keep track of stuck instances, true. I don't think we want to keep track of anything that we don't have to. That's what the logs are for :) TK> Name Id Mem(MB) CPU VCPU(s) State Time(s) TK> Domain-0 0 182 - 2 r---- 970.7 TK> debian 3 128 - 2 -b--- 502.4 TK> debian.1 3.1 0 - 2 ---s- 91.1 I think it would/should look like this: Name Id Mem(MB) CPU VCPU(s) State Time(s) Domain-0 0 182 - 2 r---- 970.7 debian-zombie-3 3 0 - 2 ---s- 502.4 debian 4 128 - 2 -b--- 91.1 -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com