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

Laine Stump laine at laine.org
Thu Aug 25 18:38:37 UTC 2016

On 08/25/2016 02:19 PM, Vasiliy Tolstov wrote:
> 25 Авг 2016 г. 19:18 пользователь "Laine Stump" <laine at laine.org 
> <mailto: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 <mailto:v.tolstov at selfip.ru>> написал:
> >> >
> >> > 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.
> >
> >
> > 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.

Yeah, I can see the utility of that. And as long as the default is up, 
then nobody is surprised by the results.

So what we're talking about is a new subelement of <source> for any 
tap-based interface type (at least):

     <interface type='ethernet|bridge|network'>
           <link state='down'/>

Since it also needs to be supported for qemuDomainChangeNet(), I'm 
doubtful this can be done prior to the freeze  tonight or early 
tomorrow, since DV is in China) though. So will it be okay to have the 
patches I've made in this release (which should handle proper operation 
for everything except the "need to modify the state while the guest is 
running" case)? I don't think any of that will need to be *un*done to 
support this new attribute, and it would be nice to have something in 
the next release that works at least in the default situation...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160825/99172dbb/attachment-0001.htm>

More information about the libvir-list mailing list