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

[libvirt] [PATCH 0/4] support <vlan> element for interfaces and networks



The purpose of these patches is to define a data type that can
properly describe an interface's vlan configuration (including
multiple vlans for trunking), provide XML parser and formatter to
translate to and from the new data type, add the new <vlan> element to
both domain <interface> and to <network> in appropriate places, and to
provide the new vlan data to the hypervisor driver.

Once these 4 patches are applied, all that will be left to support
vlan configuration for any network connection that supports it, is to
request the vlan data for the interface with
virDomainNetGetActualVlan(netdef).  If that function returns NULL,
there is no vlan config for this interface; if it's non-zero, it is a
pointer to virNetDevVlan, and you can grab the data from there.

Since I currently know of only two types of network connection we will
be able to easily support this for (sr-iov VFs using PCI passthrough,
and openvswitch), any type other than those will refuse to start if a
vlan has been requested (see PATCH 4/4). This covers validation for
the qemu and lxc drivers (since they use common code), but I'm not
sure about xen, esx, or any other driver - they will likely require
extra code to either implement transparent vlan configuration, or log
an error if it's requested (my guess is that, in spite of our best
efforts, *many* people will misunderstand the limitations of this
functionality, and try to put all sorts of interfaces on vlans; it
will be much friendlier to inform them of the problem rather than
simply ignore the vlan config.

==

This patchset was developed on top of the 9 part patchset here:

 https://www.redhat.com/archives/libvir-list/2012-August/msg00293.html

and the 5 part set here:

 https://www.redhat.com/archives/libvir-list/2012-August/msg00293.html

It doesn't depend on any of the functionality, but not having those
patchset will probably lead to some merge conflicts.


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