On Wed, Aug 15, 2012 at 12:27:58PM -0400, 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: > > 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. Can't we just query the network at time of domain definitiion to determine what type it is, and then just fill in a interfaceid ? In any case if someon really cares about stable interfaceids they ought to just be providing that info themselves in the domain XML, because nothing can make this work with transient VMs. > 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. I would have thought this could be solved just by having a reference back to the VM that is using the device, rather than the <interface>. > 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? I'm not too sure really, though my gut feeling is to not have a UUID against the interface, and I don't think the two scenarios above really require it Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list