<br><br><div class="gmail_quote">On Wed, Aug 8, 2012 at 2:18 PM, Laine Stump <span dir="ltr"><<a href="mailto:laine@laine.org" target="_blank">laine@laine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 08/08/2012 03:43 PM, Ansis Atteka
wrote:<br>
</div>
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">On Sat, Aug 4, 2012 at 10:16 PM, Laine
Stump <span dir="ltr"><<a href="mailto:laine@laine.org" target="_blank">laine@laine.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Although it's been possible (ever since openvswitch was added
to<br>
libvirt in 0.9.11) for a libvirt network to use an openvswitch
bridge<br>
(by adding <virtualport type='openvswitch'>), the
virtualport in the<br>
network would always have a default random interfaceid
included, which<br>
would be re-used for all interfaces using that network, which
doesn't<br>
really work at all. The alternative was to not specify
openvswitch in<br>
the <network> definition, but to do it in the guest's
<interface><br>
definition instead - this of course goes against the principle
of not<br>
having host-specific config embedded in guest config.<br>
<br>
This patch series enhances the functionality of
<virtualport><br>
elements, to allow omitting some attributes (and even the
type), and<br>
to merge the interface, network, and portgroup virtualports
rather<br>
than simply picking one. This not only makes openvswitch
<network>s<br>
more practical (because the network can specify
type='openvswitch'<br>
without also specifying an interfaceid), but also makes
<virtualport><br>
in networks and portgroups more useful in general - for
example, an<br>
interface can specify an interfaceid (used only by
openvswitch) *and*<br>
an instanceid (used only by 802.1Qbh), while the network's
virtualport<br>
specifies only the type, and the portgroups specify the
managerid,<br>
typeid, profileid, or whatever is appropriate for the type of
switch<br>
used by the network.<br>
<br>
The result is that the guest config can be completely devoid
of<br>
knowledge about the type of switch being used on the hardware,
but can<br>
still enjoy full configurability for whatever switch ends up
being<br>
used.<br>
</blockquote>
<div>If I understand correctly, then these patch series should
enable<br>
following configuration to work:<br>
<br>
The domain XML:<br>
...<br>
<interface type='network'><br>
<mac address='52:54:00:25:0c:bb'/><br>
<source network='ovsnet'/><br>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x03' function='0x0'/><br>
</interface><br>
...<br>
<br>
The network XML:<br>
<network><br>
<name>ovsnet</name><br>
<uuid>ad68ae68-ee26-5c65-8cff-e6c182ff3593</uuid><br>
<bridge name='ovs'/><br>
<forward mode='bridge'/><br>
<mac address='52:54:00:44:A4:D8'/><br>
<virtualport type='openvswitch'/><br>
</network><br>
<br>
<br>
And then I would expect that libvirt would auto generate the<br>
interface IDs for each interface that gets added to this
ovsnet<br>
network,</div>
</div>
</blockquote>
<br></div></div>
That was (at some point anyway) my intent - if the interface has an
interface id use it, if not then generate one, but...<div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div>but instead I am seeing the following error:<br>
<br>
2012-08-08 19:22:16.149+0000: 10840: error :
virNetDevVPortProfileCheckComplete:165 : XML error: missing
interfaceid in <virtualport type='openvswitch'><br>
</div>
</div>
</blockquote>
<br></div>
Urg. In the end I forgot that part, so when it checks for
completeness, it fails. I'll make a patch to fix that.<br>
<br>
Thanks for catching that bug.<br>
<br>
(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.)</div></blockquote><div>That will not work well from the OpenFlow Controller<br>perspective.<br><br>Interface ID must not change across guest restarts,<br>otherwise OpenFlow Controller will loose the track<br>
on which interface was which.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
I guess, it would be desirable to auto-generate interface<br>
IDs, if the network was of type openvswitch? Otherwise<br>
domain XML still needs to know what kind of type is<br>
the underlying bridge in the network XML.<br>
</div>
</div>
</blockquote>
<br></div>
Agreed. It's okay if it *optionally* puts in that info (just in case
the network is ovs), but it shouldn't require it.<div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
Though, how would this work in Actual Config, once the<br>
network type gets switched back from OVS to Linux<br>
Bridge? Would the interface ID be automatically removed<br>
from all relevant Domain XMLs?<br>
</div>
</div>
</blockquote>
<br></div>
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.<br>
<br>
</div>
</blockquote></div><br>