[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:

                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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.