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.
Anirban
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list