[Qemu-devel] Regarding migration

[Qemu-devel] Regarding migration

[pavan]

Hi.. I was wondering what are the entry points for the migration at
source and destination.

My understanding is that at source the method "do_migrate" in
migrate.c file is the entry point and at the destination the method
"main" in vl.c is the entry point.

Is this correct ?

--
   Pavan Kumar M
   Software Engineer.. not anymore though..
   North Carolina State University

Re: [Qemu-devel] Regarding migration

[Shehbaz Jaffer]

[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

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"

Regards,

Shehbaz Jaffer
Grad Student, IIT Delhi.

On Wed, Apr 3, 2013 at 3:07 AM, pavan <pavu.kumar@gmail.com> wrote:

> Hi.. I was wondering what are the entry points for the migration at
> source and destination.
>
> My understanding is that at source the method "do_migrate" in
> migrate.c file is the entry point and at the destination the method
> "main" in vl.c is the entry point.
>
> Is this correct ?
>
> --
>    Pavan Kumar M
>    Software Engineer.. not anymore though..
>    North Carolina State University
>
>


-- 
Shehbaz Jaffer
Graduate Student
Department of Computer Engineering
Indian Institute of Technology, Delhi

[-- Attachment #2: Type: text/html, Size: 3246 bytes --]

Re: [Qemu-devel] Regarding migration

[Paolo Bonzini]

Il 03/04/2013 07:11, Shehbaz Jaffer ha scritto:
> 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).

This is wrong!

1) The entry points are qmp_migrate and qemu_start_incoming_migration,
respectively.  savevm/loadvm are for snapshotting, not for migration.

2) Disks are only optionally saved, and never when using savevm/loadvm.

3) RAM is saved _before_ devices, it is different because it is saved
while the VM is running.  (As you say correctly below).

4) I don't know how you get that devices are 11.

> 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:

qemu_savevm_state_begin() does not save the memory, it only marks pages
dirty.

> 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]

I don't know where you got this information.

> ==============
>  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 correct, except again RAM is saved before devices and there can
be many more than 12 devices.

> Hence, entry point for starting migration = do_savevm().  entry point
> for receiving migration = do_loadvm().

No, see above.

Paolo