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

[Laine Stump <laine@xxxxxxxxx>]

On 08/14/2012 02:39 PM, Ansis Atteka wrote:

On Mon, Aug 13, 2012 at 2:28 PM, Laine Stump <laine@xxxxxxxxx> 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@xxxxxxxxx> 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.

So in the case that a site is using OpenFlow, they can just make sure every guest has <virtualport/> in all their interfaces' XML.

Alternately, the more I think about the idea of each <interface> having its own autogenerated <uuid> at the toplevel, the more I like it. Another example of its usefulness - I've been considering how to allow live updates to the <network> config (i.e. without requiring a destroy/start of the network), and one of the problems is that, in the cases where a physical interface can't be removed from the interface pool due to a guest currently using it, the network driver has no unique information available to provide to the user so they'll know *which* guest is preventing their config change. If each guest interface (no matter what type), the network driver could just snag the uuid and attach it to the item in the physical interface pool list. Then when the network driver later failed some operation due to a guest being connected, it could include the uuid in the error message, and that uuid could be cross-referenced with all the guest configs to find the specific guest+interface causing the problem.

Anyway, if every guest interface has a uuid, then the ovs driver (or network driver) could look first in the virtualport for a specific interfaceid, and if it wasn't found, just use the uuid.

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?

That was the behavior prior in the first revision of the patches.

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.

Okay. I think we should leave it as is, and discuss adding a pervasive uuid that's always present for every interface.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list