Re: [PATCH v3 2/2] qemu: Automaticly create tap device for VIR_DOMAIN_NET_TYPE_ETHERNET

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 05, 2014 at 11:37:05PM +0000, Anirban Chakraborty wrote:
> 
> 
> On 12/5/14, 10:43 AM, "Laine Stump" <laine@xxxxxxxxx> wrote:
> 
> >On 12/05/2014 06:12 AM, Michal Privoznik wrote:
> >> @@ -7374,7 +7399,8 @@ qemuBuildInterfaceCommandLine(virCommandPtr cmd,
> >>      }
> >>  
> >>      if (actualType == VIR_DOMAIN_NET_TYPE_NETWORK ||
> >> -        actualType == VIR_DOMAIN_NET_TYPE_BRIDGE) {
> >> +        actualType == VIR_DOMAIN_NET_TYPE_BRIDGE ||
> >> +        actualType == VIR_DOMAIN_NET_TYPE_ETHERNET) {
> >>          tapfdSize = net->driver.virtio.queues;
> >>          if (!tapfdSize)
> >>              tapfdSize = 1;
> >
> >So this patch causes libvirt to *always* create a tap device in the
> >traditional manner for type='ethernet'. I wonder if we can safely do
> >this without unknowingly breaking some strange functionality. In
> >particular, what if someone is using type='ethernet' and a script to
> >create some *other* kind of device that outwardly appears to be a tap
> >device, but is created in a different manner - currently you can do this
> >by using type='ethernet' and calling your strange "create my
> >Franken-tap" command from the script. Once this patch is in, you'll no
> >longer be able to do this.
> >
> >(As a matter of fact, I'm getting some sort of phantom memory about
> >someone doing that for some different kind of virtual switch, or
> >possibly some piece of hardware. I can't remember the details though,
> >and it's possible that I'm mistaken - maybe they *were* just creating a
> >standard tap device, but then doing strange things to it.)
> 
> In Open Contrail (www.opencontrail.org), we use this feature where tap
> interface is created first, so that we know the name of the tap device a
> priori, before creating the vm. So, this patch will break existing code.

Do you actally pre-create the TAP device though, or merely ask for a
particular choice of name.  AFAIK, then using  type=ethernet, QEMU
will always attempt to create the TAP device itself, honouring any
name given. Basically whatever QEMU does for type=ethernet, libvirt
should copy in a 100% functionally equivalent manner. We simply want
to move the functionality up a level. So there should be no regressions
if done correctly.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]