[PROPOSED PATCH] Change the creation of the TAP interface for generic ethernet interfaces

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

 



Currently with libvirt and qemu/kvm to use the generic ethernet
interface you have to use the workarounds listed in
http://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#Errors_using_.3Cinterface_type.3D.27ethernet.27.2F.3E
. This is required since the current method relies on qemu to create
the TAP interface. This was reported in the past as
https://bugzilla.redhat.com/show_bug.cgi?id=593903 ,
https://bugzilla.redhat.com/show_bug.cgi?id=593903 and
https://bugzilla.redhat.com/show_bug.cgi?id=559154 . The tickets were
closed with the work around stated as the fix. I have created a patch
to fix the issue above and avoid the work around from the Fedora wiki
requiring qemu to run as root, clear_emulator_capabilities = 1 to be
set in qemu.conf, and to put SELinux into permissive mode. All three
are required on Fedora 15 for a generic ethernet interface to work.
This work around places the host and guests in a much more vulnerable
state. I have written this against the version that ships with Fedora
15 (libvirt-0.8.8). I looked at the latest code and it appears not
much has changed and I should be able to clean up the patch and apply
it to the trunk. If there is interest I will clean up the patch and
submit it to the list for review.

The code changes it so that the TAP interface is created by libvirt
and then the file descriptor is passed to qemu. Much like what is done
when using bridged networking. This is done using fd= instead of
ifname= just like with the bridged networking. The script= parameter
is not supported with fd= so I will assume the old method will still
need to be supported for backwards compatibility. What would be the
best way to implement the config xml? I have not changed any xml
config code yet and am looking for input on the best method. A couple
of options I can think of are below.

Current example which uses ifname= listed for reference
(http://libvirt.org/formatdomain.html#elementsNICSEthernet)

<interface type='ethernet'>
    <target dev='tap0'/>
    <script path='/etc/qemu-ifup'/>
</interface>

Option 1:

Proposed change would be that if there is no script parameter it is
assumed that fd= is used instead of ifname= and if script= is present
then use ifname=

Would use fd= after the patch.
<interface type='ethernet'>
    <target dev='tap0'/>
</interface>

Would use ifname= after patch since it has a script= parameter. If a
script parameter is needed the work around would still need to be in
place.
<interface type='ethernet'>
    <target dev='tap0'/>
    <script path='/etc/qemu-ifup'/>
</interface>

Option 2:

Adding a mode parameter to the <target /> tag.

mode could be either fd or ifname. If the mode is ifname then <script
path=''/> would be valid. If the mode is left off and there is no
script parameter than I would propose that fd= be used. If that would
be an issue then ifname= could be used if the mode parameter is left
off.

<interface type='ethernet'>
    <target dev='tap0' mode='fd'/>
</interface>

Option 3:
Something completely different then above ;-)

I like option 1 unless anyone sees an issue with that method.

For example this would allow for use of openvswitch with libvirt and I
am sure other types of setups while still leaving sVirt enabled. I
have tested a patched libvirt with an openvswitch setup. You create
the TAP interface with libvirt in this manner and then add those TAP
interfaces to openvswitch assigning VLANs and other attributes as
needed. I am not proposing this as the long term supported method for
openvswitch integration, but this allows for much more flexible
networking with out sacrificing security or backwards compatibility.

Thanks,

Tyler Coumbes

--
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]