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
|
Home