Re: reboot driver domain, vifX.Y = NO-CARRIER?

[Jason Cooper <xen@lakedaemon.net>]

Hi Ian,

On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?"):
> > To implement reuse_domid in a sane way, either the toolstack needs to
> > manage all domids and always sets domid when creating domain or the
> > hypervisor needs to cooperate -- to have interface to reserve /
> > pre-allocate domids.
> 
> I think this is entirely the wrong approach.

Whew.  Glad I didn't start hacking yet...

> I think the right answer is that this is simply a bug in the
> frontends.  frontends should cope if the backend path pointer in the
> frontend directory is updated, and should start reading the new
> backend instead.

Ok, so I'm new to the guts of Xen.  The bug, at a high level, is that
"When a driver domain is rebooted (domid changed), previously connected
client domUs can't gain network connectivity to/through the driver
domain via 'xl network-attach client_domu mac=... bridge=...
backend=drv_dom'"

This is due to the fact that the frontend net driver doesn't / can't
follow the backend driver to the new domid in xenstore.

Does that sound right?

> I'm a bit surprised that this doesn't already work.

I'm currently running Xen 4.9.1 as patched in the standard Gentoo
ebuild.  I've been putting off upgrading to 4.9.2, now marked stable in
portage, until I nail this down.  I'm happy to move to 4.10 if needed.

Do you think this is something that is definitely fixed in a more recent
version of Xen?  I'm happy to test if so.  Is there a commit id I can
look for?


thx,

Jason.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel