On Aug 8, 2012, at 7:06 PM, Ansis Atteka wrote: > > On Wed, Aug 8, 2012 at 2:18 PM, Laine Stump <la...@laine.org> wrote: > On 08/08/2012 03:43 PM, Ansis Atteka wrote: >> >> >> On Sat, Aug 4, 2012 at 10:16 PM, Laine Stump <la...@laine.org> 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 agree with Ansis here. If this UUID changes each time the VM is started, it's effectively useless for something external to libvirt/OVS to utilize to recognize the interface. It needs to remain the same for the life of the interface on the VM.
> > >> >> 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 libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
