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

Re: [Xen-devel] calling vif hotplug scripts more than once



> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Olaf Hering
> Sent: 09 July 2014 08:36
> To: Ian Jackson
> Cc: xen-devel@xxxxxxxxxxxxx; Ian Campbell; Roger Pau Monne
> Subject: Re: [Xen-devel] calling vif hotplug scripts more than once
> 
> On Tue, Jul 08, Ian Jackson wrote:
> 
> > Olaf Hering writes ("Re: calling vif hotplug scripts more than once"):
> > > On Tue, Jul 08, Ian Jackson wrote:
> > > > Surely the problem is just that the backend isn't going back to the
> > > > operational state.  I don't see why this would need the hotplug script
> > > > to run again.
> > >
> > > Something needs to reconnect the device to the bridge. There is also
> > > that hotplug-status thing, which netback reads. I have to check what it
> > > does with that.
> >
> > Why is the device removed from the bridge ?  What does that ?
> 
> Looks like netback does that, because the interface disappears.
> Before "disable":
> 

What vintage of netback are you running? This is precisely the problem I fixed 
with c/s 279f438e36c0a70b23b86d2090aeec50155034a9:

-----
commit 279f438e36c0a70b23b86d2090aeec50155034a9
Author: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Date:   Tue Sep 17 17:46:08 2013 +0100

    xen-netback: Don't destroy the netdev until the vif is shut down

    Without this patch, if a frontend cycles through states Closing
    and Closed (which Windows frontends need to do) then the netdev
    will be destroyed and requires re-invocation of hotplug scripts
    to restore state before the frontend can move to Connected. Thus
    when udev is not in use the backend gets stuck in InitWait.

    With this patch, the netdev is left alone whilst the backend is
    still online and is only de-registered and freed just prior to
    destroying the vif (which is also nicely symmetrical with the
    netdev allocation and registration being done during probe) so
    no re-invocation of hotplug scripts is required.

    Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Cc: David Vrabel <david.vrabel@xxxxxxxxxx>
    Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
    Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
-----

  Paul

> # brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.00265523e546       no              eth0
>                                                         vif1.0
>                                                         vif1.0-emu
> After "disable":
> # brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.00265523e546       no              eth0
>                                                         vif1.0-emu
> 
> dmesg has:
> [50367.178364] br0: port 2(vif1.0) entering forwarding state
> [50367.178510] device vif1.0 left promiscuous mode
> [50367.178516] br0: port 2(vif1.0) entering disabled state
> [50367.227599] frontend_changed: backend/vif/1/0: prepare for reconnect
> 
> The last message appears when the frontend is in XenbusStateInitialising and
> the backend is in XenbusStateClosed, then the backend changes to
> XenbusStateInitWait.
> 
> It looks like the backend goes back into XenbusStateConnected when I write
> /local/domain/0/backend/vif/1/0/hotplug-status connected, but nothing
> puts
> vif1.0 back into br0.
> 
> 
> Olaf
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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