On Mon, Aug 13, 2012 at 2:28 PM, Laine Stump <la...@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 <la...@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. I will proceed with reviewing your new patches. Thanks, Ansis
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
