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: 1) In order to properly track information as a guest is disconnected and reconnected to an Open vSwitch bridge, the initial Open vSwitch support added an "interfaceid" parameter to virtualport. If the interfaceid isn't specified by the user when the interface is defined, one is automatically generated and placed into the persistent definition. But if the guest interface is just <interface type='network'>, it isn't known at the time of definition whether this interface will be using an Open vSwitch connection, or something else. Then, by the time we get into the network driver and decide that we're going to use Open vSwitch, it's too late to conveniently/cleanly generate an interfaceid and plug it back into the <virtualport> of the interface's persistent config. The result is that each time the guest is restarted, Open vSwitch gets a new interfaceid for it, and can't properly track things. If every interface had a uuid, the code that connects to an Open vSwitch network could just use the interface's uuid if interfaceid wasn't specified. 2) I'm about to write some patches that will allow enacting config changes to a network without needing to destroy/re-start the network. One thing that came up while I was mulling over what could and couldn't be modified without a restart is that it will be possible to allow removing physical interfaces from a network's interface pool (used for macvtap and hostdev modes), but only if that physical interface isn't currently in use. There is a use counter on each interface so we can easily tell when that situation occurs, but once we know of the failure, we have no way of pointing to which guest is causing the problem. If each interface had a uuid, we could save a list of the uuid's of all interfaces currently connected to a particular physical interface, and report that in the failure message. It would then be a fairly mechanical task to find that uuid in the guests' config. Does this sound like a reasonable idea? Any reasons *not* to do it? 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?