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

Tue Aug 14 18:56:50 UTC 2012

On 08/14/2012 02:39 PM, Ansis Atteka wrote:
>
>
> On Mon, Aug 13, 2012 at 2:28 PM, Laine Stump <laine at laine.org
> <mailto:laine at laine.org>> wrote:
>
>     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 at laine.org
>     <mailto:laine at 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.)
>
>
> What you are suggesting works completely fine with
> standalone bridge (i.e. one that does not use OpenFlow
> Controller). But what I am more concerned is that,
> if the bridge is managed by Controller and iface-id
> will be regenerated each time a reboot or migration
> happens, then we might receive bogus bug reports,
> because external applications will incorrectly think
> that this is a new interface.

So in the case that a site is using OpenFlow, they can just make sure
every guest has <virtualport/> in all their interfaces' XML.

Alternately, the more I think about the idea of each <interface> having
its own autogenerated <uuid> at the toplevel, the more I like it.
Another example of its usefulness - I've been considering how to allow
live updates to the <network> config (i.e. without requiring a
destroy/start of the network), and one of the problems is that, in the
cases where a physical interface can't be removed from the interface
pool due to a guest currently using it, the network driver has no unique
information available to provide to the user so they'll know *which*
guest is preventing their config change. If each guest interface (no
matter what type), the network driver could just snag the uuid and
attach it to the item in the physical interface pool list. Then when the
network driver later failed some operation due to a guest being
connected, it could include the uuid in the error message, and that uuid
could be cross-referenced with all the guest configs to find the
specific guest+interface causing the problem.

Anyway, if every guest interface has a uuid, then the ovs driver (or
network driver) could look first in the virtualport for a specific
interfaceid, and if it wasn't found, just use the uuid.

>
> Perhaps, if we can't generate persistent iface-id for
> interfaces that are attached to OVS networks, then
> we should rather prevent libvirt from generating one at
> all for now?

That was the behavior prior in the first revision of the patches.

>
> Anyway, I will leave this call up to you, because, I
> guess, OpenStack and others specify iface-id explicitly
> in the Domain XML file, and that will still work.

Okay. I think we should leave it as is, and discuss adding a pervasive
uuid that's always present for every interface.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120814/88560acd/attachment-0001.htm>