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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list