[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 08/08/2012 03:43 PM, Ansis Atteka wrote:


On Sat, Aug 4, 2012 at 10:16 PM, Laine Stump <laine 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.)


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]