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

Laine Stump laine at laine.org
Thu Aug 25 20:01:05 UTC 2016


On 08/25/2016 03:49 PM, Vasiliy Tolstov wrote:
>
> 25 Авг 2016 г. 21:38 пользователь "Laine Stump" <laine at laine.org 
> <mailto:laine at laine.org>> написал:
> >
> > 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'>
> >        <source>
> >           <link state='down'/>
> >        </source>
> >
> > 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...
>
> Thanks, I'm happy with this.
>

Can you ACK Patches 2/3 and 3/3?


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


More information about the libvir-list mailing list