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

Re: [Xen-devel] A migration framework for external devices

Hi Stefan,

Thanks for sending this note out.  Comments inlined.

Stefan Berger wrote:


As part of our off-list discussion on how to migrate the virtual TPM in support of virtual machine migration (live migration), we came up with the idea of having a migration framework that could be used for general migration of 'external devices' such as disk images and possibly serialized state of device models. I was going to look into this now and was wondering whether a framework like this is the right approach, particularly since it would exist next to XenD, which I believe is handling live migration ?
I'm immediately wary of any framework for migration. There's been talk (at least) of moving to a push/pull migration model which would avoid having to constantly listen for incoming migrations (and also add a bit of security too). Any sort of framework seems like its just going to make those sort of changes harder.
To be a bit clearer on the idea of the framework: It would consist of a deamon running on the target machine whose different plug-ins know how to handle the migration of different pieces of state information and know how to de-serialize them (which mere 'scp' would not do).
Plug-ins concern me even more as it implies a stable interface. There's a lot of churning going on in Xend right now and we're just not there yet. Also, I'd like to see us move away from using a daemon for migration anyway.

I'm assuming TPM migration requires bidirectional communication right? Is it static throughout the lifetime of the domain or does it change? How much state are we talking about migrating?

I think simple patches that introduce TPM migration would be a preferable start. If we end up having a lot of code that handles individual device migration than we can abstract it.


Anthony Liguori
Clients on the source machine would communicate with that daemon and transfer the state. The clients would have to be triggered by XenD after a partition is not scheduled anymore and be given the IP address of the target machine. Afterwards there needs to be some synchronization on resuming the scheduling on the target machine after all state has been deserialized. The plugable deamon itself would handle the communication sockets, a low-level protocol which the plugins and clients would use, have support for timing and protocol time-outs and provide threading. The plugins would have to do the rest of what's necessary to communicate with the infrastructure and the higher-level protocol shared with the clients.


Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.