On Wed, Nov 29, 2006 at 11:22:46AM -0500, Chris wrote:
> Ewan Mellor wrote:
> > On Tue, Nov 21, 2006 at 04:45:13PM -0500, Chris wrote:
> >
> >> There's at least one additional problem (that this patch doesn't
> >> address) effecting domains that are started, suspended, resumed, and
> >> finally shutdown. Affected domains remain in the xend's list of running
> >> domains when instead they should revert back to a dormant state with
> >> domid of -1. A work around is to restart xend after the effected
> >> domains have been shutdown, which causes the domains to correctly appear
> >> as dormant, but clearly this restart shouldn't be necessary.
> >
> > I believe that this is fixed (or certainly, it's better) with xen-unstable
> > changeset 12566.
> >
> > Ewan.
> >
>
> I think you're right; seems to be fixed from what I can tell.
>
> However, I think found another problem. :) Rebooting a managed domain
> seems to fail with an exception that the rebooted domain's name already
> exists.
>
> Clearly, the managed domain's name does and should exist to Xend because
> it's hanging out in the lifecycle area.
>
> There's a call to checkName() in XendDomainInfo's __init__() method
> that's the source of the exception, though I'm debating the merits of
> where to make changes. It might be enough to relax checkName() to allow
> creation of XendDomainInfo instances with non-unique domain names if
> they only conflict with managed domains that are not running and soon to
> be replaced. Although, it would seem more safe if an existing
> XendDomainInfo instance were re-used when a reboot occurs.
>
> Any thoughts?
Yes, you're right. I think we're relying upon the fact that the
XendDomainInfo instances aren't necessarily unique, so I've put a fix in
comparing the UUIDs of the VMs as specified on that instance. That should do
the trick.
Cheers,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home