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@xxxxxxxxxx>: >>> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
