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

[Jason Cooper <xen@xxxxxxxxxxxxxx>]

Hi Andrew,

On Fri, Apr 27, 2018 at 04:11:39PM +0100, Andrew Cooper wrote:
> On 27/04/18 16:03, Jason Cooper wrote:
> > The problem occurs when I reboot a driver domain.  Regardless of the
> > type of guest attached to it, I'm unable to re-establish connectivity
> > between the driver domain and the re-attached guest.  e.g. I reboot
> > GW/FW, then re-attach VM1, VM2 and the rest.  No matter how I do it, I
> > get:
> >
> > $ ip link
> > ...
> > 11: vif20.1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master 
> > br10 qlen 32
> >     link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
> >
> > In the driver domain.  At this point, absolutely no packets flow between
> > the two VMs.  Not even ARP.  The only solution, so far, is to unnecessarily
> > reboot the PV guests.  After that, networking is fine.
> >
> > Any thoughts?
> 
> The underlying problem is that the frontend/backend setup in xenstore
> encodes the domid in path, and changing that isn't transparent to the
> guest at all.

Oh joy.  Would seem to make more send to use the domain name or the
uuid...

> The best idea we came up with was to reboot the driver domain and reuse
> its old domid, at which point all the xenstore paths would remain
> valid.  There is support in Xen for explicitly choosing the domid of a
> domain, but I don't think that it is wired up sensibly in xl.

hmmm, yes.  It's not wired up at all afaict.  Mind giving me a hint on
how to reuse the domid?

The solution I see with my current, limited understanding could be to
change the path for the guest via xenstore-write.  Although I suspect
there's more going on underneath the hood than I'm currently aware of.

thx,

Jason.

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