From: Paolo Bonzini <pbonzini@redhat.com>
To: Shehbaz Jaffer <shehbazjaffer007@gmail.com>
Cc: qemu-devel@nongnu.org, pavan <pavu.kumar@gmail.com>
Subject: Re: [Qemu-devel] Regarding migration
Date: Wed, 03 Apr 2013 10:14:02 +0200 [thread overview]
Message-ID: <515BE4CA.30909@redhat.com> (raw)
In-Reply-To: <CAPLK-i9tx-TghCGpHjGv70GyTH3mtrBF4zV9fRkLTQnbpXNzsQ@mail.gmail.com>
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
prev parent reply other threads:[~2013-04-03 8:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 21:37 [Qemu-devel] Regarding migration pavan
2013-04-03 5:11 ` Shehbaz Jaffer
2013-04-03 8:14 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=515BE4CA.30909@redhat.com \
--to=pbonzini@redhat.com \
--cc=pavu.kumar@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=shehbazjaffer007@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.