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

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

 



This is mainly a refresh of the initial version of the patch to
rebase, but there have also been a couple of small bugs fixed. In
particular, if not <virtualport/> is specified in the domain's
interface element, connection of the interface to an ovs switch won't
fail because of a missing interfaceid (see
http://www.redhat.com/archives/libvir-list/2012-August/msg00874.html
and it's parents)

Many of these patches are trivial or mechanical.

======

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.

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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]