[libvirt] [PATCH] qemu: allow to control host side link status of network device

[Laine Stump]

On 05/16/2017 06:40 PM, Laine Stump wrote:
> On 05/16/2017 04:21 AM, Vasiliy Tolstov wrote:
>> 2017-05-16 11:16 GMT+03:00 Daniel P. Berrange <berrange at redhat.com>:
>>> Shouldn't we just tie the host & guest link state together then. This
>>> doesn't seem like enough of a reason to introduce new XML elements.
>>
>>
>> Back to half year ago i'm already have such patch, but it reverted
>> with message :
>> link state only for guest side, for host side we need different element in xml.
>>
> 
> 
> I guess I should have been working through my backlog in reverse order.
> (I just responded to the message Vasiliy sent last week about this. At
> the time of the original discussion, I intended to send a patch to
> implement <source><link state='blah'/></source> as he's done here).
> 
> Setting an interface online/offline can have further reaching
> sonsequences than just turning carrier on and off. It also removes and
> adds routes, IP addresses, and can trigger DHCP to request a new
> address, etc. Since we have other things separated for host vs guest
> side, it makes sense to do this for the link state as well. (tying two
> functions to a single knob often leads to problems, and once they're
> tied together, they can't be untied once you discover one of those
> problems. If there are two separate options, modifying both of them may
> be a bit more verbose, but it can still be done).

Oh, and I forgot to point out here (although I did in the original
thread last fall) that a toplevel <link state='blah'/> historically only
affects the state of the interface in the guest. If it began affecting
the state of the tap device in the host as well, there would be
unexpected (and undesireable) consequences.

For example, if a tap device is attached to a bridge that has STP
enabled, and you set the tap device link state down and then back up,
the port will revert to "learning" mode, and won't begin forwarding
packets again until the STP forward delay timer has expired. Likewise,
if there is an IP address configured on the host side of the tap device
and you set link state to down, any route associated with that device
will also disappear, leading to route flapping if you have any sort of
routing protocol running.

Both of these would be undesirable side effects if, for example, all you
wanted to do was trigger the guest to renegotiate an address with dhcp
(by toggling the guest NIC's link state) (I'm sure there are other
reasons someone might want to set the guest-side link state to down for
a period without encountering the side effects I listed above, that's
just what comes to mind first.)

So even if we weren't concerned about the precendent of setting <link
state='down'/> not affecting the tap device, it still makes sense to
keep the two operations separate.