10:21 a.m.
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