On 08/15/2012 01:05 PM, Eric Blake wrote: > On 08/15/2012 10:27 AM, Laine Stump wrote: >> A couple of situations have come up recently that could be solved by >> every interface in every domain always having a unique identifier >> associated with it: >> >> Does this sound like a reasonable idea? Any reasons *not* to do it? > I think the idea makes sense. > >> Problems we'll need to take care of if we add it (for example, existing >> guest interfaces will all need to get a uuid during the upgrade process, >> similar to the way we add a mac address to all existing networks that >> don't have one). Any other things you can think of doing with uuid if we >> add one? > I'm worried about how it gets added. Adding it to src/datatypes.h > virInterfacePtr would be most similar to how we do things for other > objects with a UUID (virDomainPtr, virNetworkPtr, virStoragePoolPtr, > virSecretPtr, virNWFilterPtr), but touching datatypes.h is a huge pain > because it would be an ABI break. How do we keep RPC protocol sane > without passing the UUID around, but client and server are still always > referring to the same object? I don't think we need to worry about that, because these aren't the interface objects that are passed around by the API (those are referring to physical host interfaces manipulated by the virInterface* API). The interfaces I'm talking about are the ones that are part of a domain's definition. - they're just a chunk of text inside the XML of a domain object (known as virDomainNetworkDef in C), and have no visibility in libvirt's public API (other than as elements of the domain XML). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list