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?

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?

On Wed, Aug 08, 2012 at 10:58:28PM -0400, Laine Stump wrote: > 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). No, at that point the VM is already started on the dest host, so you can't just re-send the live XML there. You can put any other data into the cookie though, it doesn't have to be passed in the persistent XML directly. Daniel