On 08/08/2012 12:30 PM, Kyle Mestery (kmestery) wrote: > On Aug 8, 2012, at 9:49 AM, Daniel P. Berrange wrote: >> On Tue, Aug 07, 2012 at 03:50:20PM -0400, Laine Stump wrote: >>> Someone asked on IRC the other day about sending openvswitch per-port >>> data (normally stored in the switch) to the destination host during a >>> migration. I suggested maybe this could be handled by encoding the >>> information into the interface's <virtualport> prior to migration, and >>> then writing it back out to openvswitch on the destination when the >>> interface was reconnected there. >>> >>> I think there's a problem with that, though - they don't want to save >>> the port data on the source until the instant that the interface is >>> disconnected (since it is constantly changing), but by then the domain >>> XML has already long ago been formatted and sent to the destination. >>> >>> So is there some other way within the confines of the current migration >>> protocol that this information can be sent from migration source to >>> destination? >> I'd be interested to know more about just what sort of data it is that >> needs to be passed around. From what you describe though, the only >> way to pass that info would be to store it in the migration cookie >> when the 'Perform' step completes (ie QEMU now paused, no network >> I/O taking place), whereupon it will be passed into the 'Finish' >> step on the dest (which can set it and then resume QEMU) >> > This is per-port data, tied to the specific virtual port associated with the VM > itself. This data is stored in the OVS DB, and is used/could be used by an > entity controlling Open vSwitch on the host. For example, stats may be kept > here. > > >From what you indicate above, can you point me at the code which handles the > migration cookie? Look in qemu_migration.c. I notice there is also code there that calls the 802.1QbX-oriented virtualport associate function (search for qemuMigrationVPAssociatePortProfiles), and it's likely there where the port data should be unloaded from the cookie into the destination host. As for when/where to load the port data *into* the cookie on the source, I'm new to that code too, and didn't see it right away :-) I do see that the entire persistent definition can be sent in the cookie. It seems to me that "last minute (last instant) updates" to the live XML could be an issue not just for interfaces connected to ovs switches, but for other circumstances as well. Does it maybe make sense to solve this in a more generalized fashion, by resending the complete live XML? (I'm assuming that during migration libvirt is preventing any modification to the live XML that would result in invalidating the vm state contained in the memory image being transferred). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list