Migration in QEMU
For a long time, I've thought about QEMU migration. For KVM, Qumranet added a static form of migration to QEMU. I've been working with Xen migration for a while now (mostly in the scope of IBM products) and I certainly have learned a lot from it. Honestly, I don't really like how KVM is doing migration so after spending a weekend heads down on V2E, I decided to take some time and implement migration for QEMU.
The biggest problem I have with KVM and Xen's migration is that it uses open TCP ports. This is just such a bad idea. It's a security nightmare to transfer the contents of memory over an unencrypted channel. For QEMU, I decided to allow the user to spawn an external program to setup the channel to send the migration traffic over. This lets a user just use SSH or RSH if they want something that works. This also let's management tools implement their own mechanism. This may use OpenSSL, CIM, or any other mechanisms out there. It also provides a mechanism for implementing some interesting things like light weight checkpointing (although that's another topic).
This does make things a bit more complicated though. Instead of just saying 'migrate hostname' you now have to construct a rather long command like 'migrate "ssh hostname qemu -loadvm -"'. A nice side effect though is that you can completely change the command line arguments in case you have NFS mounts at different locations.
At the moment, I have a static migration patch. I'd like to implement live migration real soon. I think it will be pretty easy. It's just a matter of adding a new set of callbacks to allow devices that may take a long time to save/restore to instead, provide a "live" save/restore callback. We'll just run through the live callbacks first and when they've signaled that they're done, we'll go ahead and activate the non-live callbacks. This probably will only touch the RAM save/restore code at first which seems more than okay to me.
If you're interested in taking a peak, you can just take a look in my QEMU patch queue.