qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Regarding migration


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Regarding migration
Date: Wed, 03 Apr 2013 10:14:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]