[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

On Mon, Apr 30, 2018 at 04:16:09PM +0000, Jason Cooper wrote:
> 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 seems to be different from what I originally understood. I thought
you were just expecting the frontend to reconnect automatically.

At the risk of asking the obvious question: drv_dom is the name not
numeric domid, right?

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

This is strange. A new udev event should be initiated in DomU. It will
then scans xenstore for a _new_ network device. There should be a new
device from DomU's PoV, which means it doesn't need to know what backend
domid is. This should be already handled by core xenbus driver.

Also "backend-id" is already in a device's xenstore tree.


Xen-devel mailing list



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