[libvirt] [PATCH 1/1] Add vlantag parameter for openvswitch ports

[Kyle Mestery (kmestery)]

On Aug 9, 2012, at 3:14 PM, Laine Stump wrote:
> On 08/08/2012 03:47 PM, Kyle Mestery wrote:
>> Add the ability to specify a "vlantag" parameter for bridge
>> networks with a virtualport type of openvswitch. This
>> allows for specifying the port is on a single VLAN, and
>> should receive untagged traffic (e.g. vlantag=10), or that
>> a port should receive tagged traffic and is a trunk port
>> (e.g. vlantag=10,11).
> 
> Ha! We must have a telepathic link!
> 
Well, we're at least thinking in the same general direction. :)

> I'm just about to add vlan support for SR-IOV VFs in PCI passthrough
> (aka "hostdev") and macvtap passthrough modes (the only thing that's
> kept me from action is indecision about where to put the vlan tag in the
> xml), and since at least one of those modes doesn't use <virtualport> at
> all, I was planning to add a <vlan tag='x'/> element at the toplevel of
> interface. There would also be a similar element at the toplevel of
> <network>, and another within <portgroup>.
> 
> Something like this:
> 
> <interface type='hostdev'>
>  <mac address='52:54:00:11:22:33'/>
>  <vlan tag='42'/>
>  ...
> </interface>
> 
> In this case, there is no <network> involved. Here's a case that uses a
> network:
> 
> 
> <interface type='network'>
>  <mac address='52:54:00:11:22:33'/>
>  <source network='net42'/>
>  ...
> </interface>
> 
> <network>
>  <name>net42</name>
>  <vlan tag='42'/>
>  <forward mode='passthrough'>
>    <interface dev='eth5'/>
>    <interface dev='eth6'/>
>    <interface dev='eth7'/>
>  </forward>
> </network>
> 
> In this second case, when the interface was brought up, it would
> allocate a physical device from the pool, and inherit the vlan tag,
> which would be set in the SR-IOV card's hardware as it's assigned to the
> guest. Note that hostdev passthrough would behave similarly (except
> forward mode would be 'hosted')
> 
Those cases both look good. I think the formatting works just fine for
virtualport type=openvswitch as well, something like this:

Single VLAN (no trunk):
<interface type='bridge'>
 <mac address='52:54:00:30:23:a6'/>
 <source bridge='data-br'/>
 <vlan tag='70'/>
 <virtualport type='openvswitch'> 
   <parameters interfaceid='cdbbbc31-b7fe-16ca-a715-cc7cc76e18b2'>
 </virtualport>                    
 <model type='virtio'/>                  
 <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Single VLAN (trunk):
<interface type='bridge'>
 <mac address='52:54:00:30:23:a6'/>
 <source bridge='data-br'/>
 <vlan tag='70'/ trunk=yes>
 <virtualport type='openvswitch'> 
   <parameters interfaceid='cdbbbc31-b7fe-16ca-a715-cc7cc76e18b2'>
 </virtualport>                    
 <model type='virtio'/>                  
 <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Multiple VLANs (trunk):
<interface type='bridge'>
 <mac address='52:54:00:30:23:a6'/>
 <source bridge='data-br'/>
 <vlan trunk='yes'>
  <tag id='70'>
  <tag id='71'>
 </vlan>
 <virtualport type='openvswitch'> 
   <parameters interfaceid='cdbbbc31-b7fe-16ca-a715-cc7cc76e18b2'>
 </virtualport>                    
 <model type='virtio'/>                  
 <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>


> Finally, there may be a network with multiple vlans. portgroups could be
> used for that:
> 
> <interface type='network'>
>  <mac address='52:54:00:11:22:33'/>
>  <source network='physnet' portgroup='production'/>
>  ...
> </interface>
> 
> <network>
>  <name>net42</name>
>  <forward mode='passthrough'>
>    <interface dev='eth5'/>
>    <interface dev='eth6'/>
>    <interface dev='eth7'/>
>  </forward>
>  <portgroup name='production' default='yes'>
>    <vlan tag='42'/>
>    <bandwidth>
>      ..
>    </bandwidth>
>  </portgroup>
>  <portgroup name='test'>
>    <vlan tag='666'/>
>    <bandwidth>
>      ..
>    </bandwidth>
>  </portgroup>
> </network>
> 
> Selecting a different portgroup would put you on a difference vlan of
> the same switch. We would need to make a decision about which would take
> precedence if the vlan tag was given in multiple places - should the
> domain's request be honored, in order to allow it to made individual
> modifications to the general config in the <network>? Or should the
> network, as an entity of higher authority, be allowed to override what
> the domain asks for?
> 
I think this is the most elegant solution, and dovetails nicely with the fact that
virtualport type='openvswitch' ports already support port-profiles. I think in general,
my feeling here is the domain XML should override the network element. This is
similar to an interface override of a port-profile on a Cisco switch, for example, where
you define configuration in a port-profile, but allow configuration directly on the
interface itself to override the port-profile configuration.

> I've never used vlan trunk groups, but I'm guessing whatever information
> you needed could be added as attributes to the <vlan> element. BTW, in
> general we don't like to have multiple pieces of data in a single
> element. We would prefer that they be in separate elements. So maybe if
> you wanted a single vlan tag, you could do it as above, but when you
> wanted a trunk group, you could do something like:
> 
>   <vlan trunk='yes'>
>     <tag id='23'/>
>     <tag id='24'/>
>     <tag id='25'/>
>   </vlan>
> 
> (you might allow omitting the "trunk='yes'") Or possibly put them all at
> the top level:
> 
>   <vlan tag='23'/>
>   <vlan tag='24'/>
>   <vlan tag='25'/>
> 
> and if you wanted a vlan trunk with only a single vlan in it:
> 
>   <vlan tag='23' trunk='yes'/>
> 
> (actually, having multiple toplevel elements could get messy if we
> started talking about merging the elements from
> network/portgroup/interface together, so maybe that's not such a good idea).
> 
> *Still another* possibility would be to put the vlan element as
> described above inside <virtualport>, then allow <virtualport> with no
> type to contain a <vlan> element. This would require a change to my
> recent <virtualport> merging patches, but they haven't been pushed yet.
> I'm not convinced I like that option, though.
> 
> I think this needs a day or so to stew...

So I guess the question is, are you going to role this up into your patches? If so, you
can likely make use of some pieces of the patches I posted. Let me know, and I can
also work with you on this as well.

Thanks,
Kyle