On 12/8/14, 2:10 AM, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
>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.
It is created as part of openstack nova vif creation process. Nova libvirt
driver passes in the vif name to the network provider (in this case,
contrail), which in turn uses it internally for various configuration
purposes. What you are saying is that passing a preassigned name to
libvirt for tap device creation would work. In that case, it should be
fine.
Anirban
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list