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

[Ansis Atteka]

On Wed, Aug 8, 2012 at 2:18 PM, Laine Stump <laine at laine.org> wrote:

>  On 08/08/2012 03:43 PM, Ansis Atteka wrote:
>
>
>
> On Sat, Aug 4, 2012 at 10:16 PM, Laine Stump <laine at laine.org> wrote:
>
>> Although it's been possible (ever since openvswitch was added to
>> libvirt in 0.9.11) for a libvirt network to use an openvswitch bridge
>> (by adding <virtualport type='openvswitch'>), the virtualport in the
>> network would always have a default random interfaceid included, which
>> would be re-used for all interfaces using that network, which doesn't
>> really work at all. The alternative was to not specify openvswitch in
>> the <network> definition, but to do it in the guest's <interface>
>> definition instead - this of course goes against the principle of not
>> having host-specific config embedded in guest config.
>>
>> This patch series enhances the functionality of <virtualport>
>> elements, to allow omitting some attributes (and even the type), and
>> to merge the interface, network, and portgroup virtualports rather
>> than simply picking one. This not only makes openvswitch <network>s
>> more practical (because the network can specify type='openvswitch'
>> without also specifying an interfaceid), but also makes <virtualport>
>> in networks and portgroups more useful in general - for example, an
>> interface can specify an interfaceid (used only by openvswitch) *and*
>> an instanceid (used only by 802.1Qbh), while the network's virtualport
>> specifies only the type, and the portgroups specify the managerid,
>> typeid, profileid, or whatever is appropriate for the type of switch
>> used by the network.
>>
>> The result is that the guest config can be completely devoid of
>> knowledge about the type of switch being used on the hardware, but can
>> still enjoy full configurability for whatever switch ends up being
>> used.
>>
> 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 guess, it would be desirable to auto-generate interface
> IDs, if the network was of type openvswitch? Otherwise
> domain XML still needs to know what kind of type is
> the underlying bridge in the network XML.
>
>
> Agreed. It's okay if it *optionally* puts in that info (just in case the
> network is ovs), but it shouldn't require it.
>
>
>
> Though, how would this work in Actual Config, once the
> network type gets switched back from OVS to Linux
> Bridge? Would the interface ID be automatically removed
> from all relevant Domain XMLs?
>
>
> Kind of. More exactly, the interface ID would be ignored when not
> relevant. Similarly, you could also have an instanceid (used by 802.1Qbg),
> and if the actual network type was ovs, the instanceid would be ignored.
> The only thing you *can't* do is to specify <virtualport type='xyz'> in the
> interface if the network is actually some other type.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120808/806beb5f/attachment-0001.htm>