[libvirt] [PATCH 2/3] qemu: remove unnecessary setting of tap device online state

[Laine Stump]

On 08/25/2016 05:41 AM, Vasiliy Tolstov wrote:
>
> 25 Авг 2016 г. 8:58 пользователь "Laine Stump" <laine at laine.org 
> <mailto:laine at laine.org>> написал:
> >
> > The linkstate setting of an <interface> is only meant to change the
> > online status reported to the guest system by the emulated network
> > device driver in qemu,
>
> I need to set host side status of interface. Without this live 
> migration with dinamic routing software (ospf with quagga or bird) 
> bring packet drops. Because on dest interface in up state and kernel 
> try to forward packets to it, but guest  CPU is not running. Also host 
> side status needed for easy blackhole traffic to guest ip.
>
(tl;dr - it doesn't seem to me like this should be a problem, since we 
don't add the IP addresses or routes to the tap device until just before 
starting the guest CPUs)

Hmm, so a L3 analog to the problem that we have at L2 with macvtap 
interfaces (the presence of an IFF_UP interface with the same MAC 
address as the guest causes traffic for that MAC to be sent to the 
destination too soon.

When connecting a tap device to a bridge, it's important for it to be 
IFF_UP as soon as possible, because the STP forward delay timer doesn't 
start until it's IFF_UP (and since the MAC address of the tap device 
itself isn't used for forwarding any traffic, there's no harm to an L2 
forwarding tables caused by this).

Of course in the case of taps connected to bridges, we don't have any IP 
address set, and also no routes set (although I'm wondering if in the 
future we might have routes (but still no IPs)), so we never encounter 
the issue with L3 forwarding that we do for type='ethernet'.

Setting the tap device offline does have the effect of eliminating all 
IP addresses and routes in a single operation, which works properly for 
you. But if that tap happened to be connected to a bridge (outside the 
scope of libvirt), waiting to set it IFF_UP could result in a much 
longer-than-desired wait before the interface was usable.

But of course if we're not adding the routes and IPs until 
qemuInterfaceStartDevice(), the issue wouldn't exist at domain start 
time - that function isn't called until right before the CPUs are 
started, which is exactly when you want it, so there shouldn't be any 
case where either the IP address of the tap device or the routes 
associated with it are visible prior to the exact time when you want it 
to happen.

There is one issue that may still need to be addressed - there are a few 
cases where we stop the guest CPUs temporarily, and then restart them; 
qemuInterfaceStopDevice *is* called before the CPUs are stopped, but 
because we don't have anything in there to remove the routes or IPs on 
the tap device, it would still be seen as a destination for the given 
IPs during this time. I'm not sure this is really a problem though, 
because we do fully intend to start the same CPU up again and in the 
meantime there isn't any other valid destination for the traffic - 
removing and re-adding the routes during, e.g a 
qemuDomainRevertToSnapshot() would only have the effect of causing a 
mini (and single iteration) route flap. So I don't think anything needs 
to be done about this either.

Does this all make sense, or am I missing something?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160825/c9085d35/attachment-0001.htm>