On Wed, Aug 8, 2012 at 2:18 PM, Laine Stump <[email protected]> wrote: > On 08/08/2012 03:43 PM, Ansis Atteka wrote: > > > > On Sat, Aug 4, 2012 at 10:16 PM, Laine Stump <[email protected]> wrote: > >> Although it's been possible (ever since openvswitch was added to >> libvirt in 0.9.11) for a libvirt network to use an openvswitch bridge >> (by adding <virtualport type='openvswitch'>), the virtualport in the >> network would always have a default random interfaceid included, which >> would be re-used for all interfaces using that network, which doesn't >> really work at all. The alternative was to not specify openvswitch in >> the <network> definition, but to do it in the guest's <interface> >> definition instead - this of course goes against the principle of not >> having host-specific config embedded in guest config. >> >> This patch series enhances the functionality of <virtualport> >> elements, to allow omitting some attributes (and even the type), and >> to merge the interface, network, and portgroup virtualports rather >> than simply picking one. This not only makes openvswitch <network>s >> more practical (because the network can specify type='openvswitch' >> without also specifying an interfaceid), but also makes <virtualport> >> in networks and portgroups more useful in general - for example, an >> interface can specify an interfaceid (used only by openvswitch) *and* >> an instanceid (used only by 802.1Qbh), while the network's virtualport >> specifies only the type, and the portgroups specify the managerid, >> typeid, profileid, or whatever is appropriate for the type of switch >> used by the network. >> >> The result is that the guest config can be completely devoid of >> knowledge about the type of switch being used on the hardware, but can >> still enjoy full configurability for whatever switch ends up being >> used. >> > If I understand correctly, then these patch series should enable > following configuration to work: > > The domain XML: > ... > <interface type='network'> > <mac address='52:54:00:25:0c:bb'/> > <source network='ovsnet'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x03' > function='0x0'/> > </interface> > ... > > The network XML: > <network> > <name>ovsnet</name> > <uuid>ad68ae68-ee26-5c65-8cff-e6c182ff3593</uuid> > <bridge name='ovs'/> > <forward mode='bridge'/> > <mac address='52:54:00:44:A4:D8'/> > <virtualport type='openvswitch'/> > </network> > > > And then I would expect that libvirt would auto generate the > interface IDs for each interface that gets added to this ovsnet > network, > > > That was (at some point anyway) my intent - if the interface has an > interface id use it, if not then generate one, but... > > > but instead I am seeing the following error: > > 2012-08-08 19:22:16.149+0000: 10840: error : > virNetDevVPortProfileCheckComplete:165 : XML error: missing interfaceid in > <virtualport type='openvswitch'> > > > Urg. In the end I forgot that part, so when it checks for completeness, it > fails. I'll make a patch to fix that. > > Thanks for catching that bug. > > (one issue about this - since it's not known until runtime that the > network is ovs, the interfaceid won't be generated until then, and at that > time it's not reasonable to update the interfaceid in the guest's > persistent config. So, if you're configured this way, the guest will get a > different new interfaceid every time it is restarted.) > That will not work well from the OpenFlow Controller perspective.
Interface ID must not change across guest restarts, otherwise OpenFlow Controller will loose the track on which interface was which. > > > I guess, it would be desirable to auto-generate interface > IDs, if the network was of type openvswitch? Otherwise > domain XML still needs to know what kind of type is > the underlying bridge in the network XML. > > > Agreed. It's okay if it *optionally* puts in that info (just in case the > network is ovs), but it shouldn't require it. > > > > Though, how would this work in Actual Config, once the > network type gets switched back from OVS to Linux > Bridge? Would the interface ID be automatically removed > from all relevant Domain XMLs? > > > Kind of. More exactly, the interface ID would be ignored when not > relevant. Similarly, you could also have an instanceid (used by 802.1Qbg), > and if the actual network type was ovs, the instanceid would be ignored. > The only thing you *can't* do is to specify <virtualport type='xyz'> in the > interface if the network is actually some other type. > >
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
