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

Vasiliy Tolstov v.tolstov at selfip.ru
Thu Aug 25 18:19:21 UTC 2016


25 Авг 2016 г. 19:18 пользователь "Laine Stump" <laine at laine.org> написал:
>
> On 08/25/2016 05:42 AM, Vasiliy Tolstov wrote:
>>
>> 25 Авг 2016 г. 12:34 пользователь Vasiliy Tolstov <v.tolstov at selfip.ru>
написал:
>> >
>> > 25 Авг 2016 г. 8:58 пользователь "Laine Stump" <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.
>
>
> That shouldn't be a problem, since the IPInfo isn't added to the tap
device until immediately before the guest CPU is started on the destination
(that's the purpose of qemuInterfaceStartDevice()).
>
>
>
>> Also host side status needed for easy blackhole traffic to guest ip.
>
>
> Is this something you need to do while the guest is already running? If
not, then I think we don't need anything extra.
>
>
>
>> May be create inside the source link state attribute for host side link
status? So it consistent with ip and route elements?
>
>
> If necessary, that might be the right solution, although I still think
it's better to not set the tap device offline, in case it's connected to a
bridge - we wouldn't want to trigger an STP forward delay. Maybe just
delete (and later re-add) the IPInfo would be less disruptive? (Or it might
be *more* disruptive, we'd have to try both).
>
>
Thanks for info.
Why not add ability to specify device state from host side? If attribute is
empty think that device is up. This is reasonable default. I'm use link
status when vm running, for example if we have ddos - I down tap and via
ospf route deleted and traffic blackholed.

>
>> >
>> > > but when support for auto-creating tap devices
>> > > for <interface type='ethernet'> was added in commit 9717d6, a chunk
of
>> > > code was also added to qemuDomainChangeNetLinkState() that sets the
>> > > online status of the tap device (i.e. the *host* side of the
>> > > interface) for type='ethernet'. This was never done for tap devices
>> > > used in type='bridge' or type='network' interfaces, nor was it done
in
>> > > the past for tap devices created by external scripts for
>> > > type='ethernet', so we shouldn't be doing it now.
>> > >
>> > > This patch removes the bit of code in qemuDomainChangeNetLinkState()
>> > > that modifies online status of the tap device.
>> > > ---
>> > >  src/qemu/qemu_hotplug.c | 15 ---------------
>> > >  1 file changed, 15 deletions(-)
>> > >
>> > > diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
>> > > index 00e4a75..5300bc1 100644
>> > > --- a/src/qemu/qemu_hotplug.c
>> > > +++ b/src/qemu/qemu_hotplug.c
>> > > @@ -2324,21 +2324,6 @@ int
qemuDomainChangeNetLinkState(virQEMUDriverPtr driver,
>> > >      if (ret < 0)
>> > >          goto cleanup;
>> > >
>> > > -    if (virDomainNetGetActualType(dev) ==
VIR_DOMAIN_NET_TYPE_ETHERNET) {
>> > > -        switch (linkstate) {
>> > > -            case VIR_DOMAIN_NET_INTERFACE_LINK_STATE_UP:
>> > > -            case VIR_DOMAIN_NET_INTERFACE_LINK_STATE_DEFAULT:
>> > > -                if ((ret = virNetDevSetOnline(dev->ifname, true)) <
0)
>> > > -                    goto cleanup;
>> > > -                break;
>> > > -
>> > > -            case VIR_DOMAIN_NET_INTERFACE_LINK_STATE_DOWN:
>> > > -                if ((ret = virNetDevSetOnline(dev->ifname, false))
< 0)
>> > > -                    goto cleanup;
>> > > -                break;
>> > > -            }
>> > > -    }
>> > > -
>> > >      /* modify the device configuration */
>> > >      dev->linkstate = linkstate;
>> > >
>> > > --
>> > > 2.7.4
>> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160825/2699f82f/attachment-0001.htm>


More information about the libvir-list mailing list