On 12/5/14, 10:43 AM, "Laine Stump" <laine(a)laine.org> 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
--
|: