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@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.)