All of migration code can be found in migrate.c file.
To understand migration, you can run qemu in gdb and place breakpoints in do_savevm() function on server side and do_loadvm() function on client side.
Migration consists of the following parts:
1. save device driver state (11 in number. this consists of keyboard, mouse and other device drivers on server side)
2. RAM (this is also structured like other device drivers but there is a special way in which this device driver is saved).
3. Disk (saved in the form of block device).
first you make a client to sleep over a port. i.e. client waits for server to initiate migration.
on server, you give command to savevm.
the entry point is do_savevm() from which 3 things happen:
1. qemu_savevm_state_begin() is called, ram is snapshotted for the first time, all pages are marked dirty and thus saved.
2. qemu_savevm_state_iterate() is called, from which ram is snapshotted time and again till either of the two things happen:
1. no of iterations go more than 30.
2. rate at which pages get dirty decreases in two successive iterations.
[NOTE that till here only RAM was being saved, the rest of the 12 device drivers have not been saved yet]
==============
vm_stop() is called. this leads to halt of server vm(); no more ram pages get dirty
==============
3. qemu_savevm_state_complete() is called where rest of the 12 device driver state is saved and 1 final iteration of saving ram is done.
this is device, ram and block(disk) state transferred via tcp / file to client on a port / fd. (depending on what client was listening to)
At client end, the reverse sequence is followed i,e. first you load the device driver, then the ram image and so on. and then vm_start() is called.
Hence, entry point for starting migration = do_savevm(). entry point for receiving migration = do_loadvm().
more about live migration can be read in this amazing paper by Avi Kivity ::
"www.linux-kvm.com/sites/default/files/kivity-Reprint.pdf"