From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNIpi-0007Gm-P7 for qemu-devel@nongnu.org; Wed, 03 Apr 2013 04:14:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNIpe-0002dV-Qr for qemu-devel@nongnu.org; Wed, 03 Apr 2013 04:14:14 -0400 Received: from mail-qe0-f46.google.com ([209.85.128.46]:51807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNIpe-0002dK-N5 for qemu-devel@nongnu.org; Wed, 03 Apr 2013 04:14:10 -0400 Received: by mail-qe0-f46.google.com with SMTP id a11so730797qen.33 for ; Wed, 03 Apr 2013 01:14:10 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <515BE4CA.30909@redhat.com> Date: Wed, 03 Apr 2013 10:14:02 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Regarding migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Shehbaz Jaffer Cc: qemu-devel@nongnu.org, pavan 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