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

Reply via email to