<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/25/2016 05:41 AM, Vasiliy Tolstov
wrote:<br>
</div>
<blockquote
cite="mid:CACaajQvbhQuOfoToJW4zmF7EMyUo621EPtqM90dUyxSgTW0=Og@mail.gmail.com"
type="cite">
<p dir="ltr">25 Авг 2016 г. 8:58 пользователь "Laine Stump" <<a
moz-do-not-send="true" href="mailto:laine@laine.org">laine@laine.org</a>>
написал:<br>
><br>
> The linkstate setting of an <interface> is only meant
to change the<br>
> online status reported to the guest system by the emulated
network<br>
> device driver in qemu,</p>
<p dir="ltr">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.<br>
</p>
</blockquote>
(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)<br>
<br>
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.<br>
<br>
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).<br>
<br>
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'.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Does this all make sense, or am I missing something?<br>
<br>
</body>
</html>