[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] 15142:78389dbb08bb and domain state
On Tue, Nov 13, 2007 at 07:45:38PM +0000, Keir Fraser wrote: > > bash-3.00# xm list > > Name ID Mem VCPUs State > > Time(s) > > Domain-0 0 6718 4 r----- > > 119.7 > > sxc13 1024 1 > > 52.0 > > sxc15 1 900 1 ------ > > 37.8 > > > > The domain is not listed in the 'q' output at this point. Is there another > > way > > to fix the bug that regressed this behaviour? > > Is it explicable how this happens for you but not for me? I haven't been > seeing domains hang around in 'cm list' after domain destruction at all. Just to double-check, I'm testing with a managed domain, and not using xen-api for xm - same for you? I'm surprised it works every time for you, although since it appears to be a race, it's possible (I suspect it might be because my domain is still page-flipping). Here's what I see: We call destroyDomain(), and do: xc.domain_destroy(self.domid) for state in DOM_STATES_OLD: self.info[state] = 0 Now, this has attempted to force the states to be zero, but then something comes along and does XenDomain:_refresh(): running = self._running_domains() for dom in running: domid = dom['domid'] if domid in self.domains: self.domains[domid].update(dom, refresh_shutdown) This immediately gets an up-to-date hypervisor version of the state, over-riding the forced state setting above. Previously, we'd delete the domid, so we wouldn't get this update happening, as can be seen. I haven't quite worked out when domID gets cleaned out when this race doesn't happen though - what code resets domid in your case? Any suggestions for a fix? regards john _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |