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

[Laine Stump]

danpb raised a (valid) objection about the XML format in the first
version of these patches, so I've redone it to be like this:

   <vlan trunk='yes'>
      <tag id='42'/>
      <tag id='30'/>
   </vlan>

The downside is that for a single vlan tag, it's more verbose:

   <vlan>
     <tag id='42'/>
   </vlan>

On the other hand, it's more consistent.

The rest of the patches in the series were unchanged (and even the
data definition is unchanged).

===

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.