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

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



On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote:
> On 27/04/18 16:35, Jason Cooper wrote:
> > 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...
> 
> domids are also used in the grant and event hypercall interfaces with Xen.

If the frontend manages to go through disconnect/reconnect cycle, grant
table and event channel aren't going to be a problem?

Wei.

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

 


Rackspace

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