Re: [libvirt] [PATCH 0/9] network: properly support openvswitch in <network>

On Mon, Aug 13, 2012 at 2:28 PM, Laine Stump <laine(a)laine.org <mailto:laine@laine.org>> wrote: On 08/08/2012 09:35 PM, Kyle Mestery (kmestery) wrote: > On Aug 8, 2012, at 7:06 PM, Ansis Atteka wrote: >> On Wed, Aug 8, 2012 at 2:18 PM, Laine Stump <laine(a)laine.org <mailto:laine@laine.org>> wrote: >> On 08/08/2012 03:43 PM, Ansis Atteka wrote: >>> 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. The problem is that there is currently no method in libvirt to feed config changes from the network driver back out to the guest's config. At least until someone can come up with an elegant way to do this, if someone wants the interfaceid to remain constant across reboots/migrations of the guest, it must be present in the guest's interface config from the beginning. The current setup provides a way to do that - if the guest <interface> contains an empty <virtualport/> element, that will automatically have both an interfaceid (openvswitch) and an instanceid (802.1Qbg/VEPA) generated for it. Since the virtualport has no type, it's not forcing the guest to use a particular type of connection, but if the connection happens to be openvswitch, the interfaceid that's been generated will be used. Note that if we *do* figure out how to channel a network-driver-generated interfaceid back to the guest config, the current patches will be compatible with that, so that shouldn't necessarily stop us from getting these patches in. (I'm starting to wonder if every interface should just always have a unique uuid associated with it, no matter what else it's configured for. So far there have been two places where it could have been used (interfaceid and instanceid), and it's possible more will come up in the future. If we were to add that, what would we then do with the interfaceid and instanceid, though? We must continue to support them because libvirt guarantees 100% backward compatibility.) What you are suggesting works completely fine with standalone bridge (i.e. one that does not use OpenFlow Controller). But what I am more concerned is that, if the bridge is managed by Controller and iface-id will be regenerated each time a reboot or migration happens, then we might receive bogus bug reports, because external applications will incorrectly think that this is a new interface.

Perhaps, if we can't generate persistent iface-id for interfaces that are attached to OVS networks, then we should rather prevent libvirt from generating one at all for now?

Anyway, I will leave this call up to you, because, I guess, OpenStack and others specify iface-id explicitly in the Domain XML file, and that will still work.