[ovs-dev] [PATCH] xenserver: Kill bond master's dhclient when bringing up bond slave.
Ben Pfaff
blp at nicira.com
Mon Jun 28 17:42:11 UTC 2010
On Mon, Jun 28, 2010 at 09:56:20AM +0100, Ian Campbell wrote:
> On Fri, 2010-06-25 at 21:22 +0100, Ben Pfaff wrote:
> > interface-reconfigure is never explicitly called to down a bond master.
> > However, when it is called to up a slave it is implicit that we are
> > destroying the master. The "bridge" version of interface-reconfigure
> > always "ifdown"s the bond master in such a case, but until now the
> > "vswitch" version has not done so. Usually, it doesn't matter, because
> > the bond master network device disappears when the slave is brought up,
> > but one case was missed: for a bond master with an IP address obtained
> > via DHCP, the dhclient process needs to be killed, and we were not doing
> > it. This commit starts doing it (by invoking ifdown on the bond master).
>
> Looks good.
Thank you for the review.
> > The dhclient process that hangs around doesn't cause problems until the
> > bond master is brought back up, at which point "ifup" fails because it
> > refuses to start another dhclient for the same interface.
> >
> > I do not know for sure whether the converse change is needed: that is,
> > when a bond PIF is brought up, is interface-reconfigure expected to
> > implicitly take down its slave PIFs? But I do not think so. This commit
> > does not change that behavior.
>
> interface-reconfigure is expected to take down slave PIFs if they are
> up. The bridge bring_down_existing brings down:
> * vlan masters - (I think) not necessary with vswitch due to
> different behaviour wrt vlans and tagging ports instead of
> creating separate bridges etc.
> * bond masters - handled by this patch
> * the device itself - this brings down the bond slaves too due to
> the bridge version of bring_down_interface doing so. In vswitch
> this seems to be handled by extra_down_ports in the
> configure_datapath function.
>
> Unless switching from a slave w/ DHCP to a bond leaves a dhclient lying
> around (which I don't think it does) I think we are currently ok.
For completeness I checked this behavior (on 5.5.0). It already worked
correctly. So it seems that I was prematurely worried about that part
anyway.
I pushed this change out, after updating the log message.
More information about the dev
mailing list