On 08/14/2012 02:39 PM, Ansis Atteka
What you are suggesting works completely fine with
On Mon, Aug 13, 2012 at 2:28 PM, Laine
Stump <laine laine org>
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 laine org
>> On 08/08/2012 03:43 PM, Ansis Atteka wrote:
The problem is that there is currently no method in libvirt to
>>> If I understand correctly, then these
patch series should enable
>>> following configuration to work:
>>> The domain XML:
>>> <interface type='network'>
>>> <source network='ovsnet'/>
>>> <address type='pci' domain='0x0000'
bus='0x00' slot='0x03' function='0x0'/>
>>> The network XML:
>>> <bridge name='ovs'/>
>>> <forward mode='bridge'/>
>>> <mac address='52:54:00:44:A4:D8'/>
>>> <virtualport type='openvswitch'/>
>>> And then I would expect that libvirt would
auto generate the
>>> interface IDs for each interface that gets
added to this ovsnet
>> 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
>> Urg. In the end I forgot that part, so when it
checks for completeness, it fails. I'll make a patch to
>> 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
>> That will not work well from the OpenFlow
>> Interface ID must not change across guest
>> otherwise OpenFlow Controller will loose the
>> 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.
config changes from the network driver back out to the guest's
At least until someone can come up with an elegant way to do
someone wants the interfaceid to remain constant across
reboots/migrations of the guest, it must be present in the
interface config from the beginning.
The current setup provides a way to do that - if the guest
contains an empty <virtualport/> element, that will
both an interfaceid (openvswitch) and an instanceid
generated for it. Since the virtualport has no type, it's not
the guest to use a particular type of connection, but if the
happens to be openvswitch, the interfaceid that's been
generated will be
Note that if we *do* figure out how to channel a
network-driver-generated interfaceid back to the guest config,
current patches will be compatible with that, so that
necessarily stop us from getting these patches in.
(I'm starting to wonder if every interface should just always
unique uuid associated with it, no matter what else it's
So far there have been two places where it could have been
(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
because libvirt guarantees 100% backward compatibility.)
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'
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.