Re: sending openvswitch "port db" info during libvirt migration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Aug 9, 2012, at 4:23 AM, Daniel P. Berrange wrote:
> 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


Thanks guys, I think I see how to do this now. I'll work on this and send some
patches.

Thanks,
Kyle

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]