From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1XFB-0004nX-A6 for qemu-devel@nongnu.org; Wed, 25 Nov 2015 05:24:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1XF8-0001IH-3v for qemu-devel@nongnu.org; Wed, 25 Nov 2015 05:24:09 -0500 Received: from mailout2.zih.tu-dresden.de ([141.30.67.73]:35284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1XF7-0001ID-Ts for qemu-devel@nongnu.org; Wed, 25 Nov 2015 05:24:06 -0500 References: <5654A3B5.2050101@redhat.com> From: Bohdan Trach Message-ID: <56558C43.3020106@mailbox.tu-dresden.de> Date: Wed, 25 Nov 2015 11:24:03 +0100 MIME-Version: 1.0 In-Reply-To: <5654A3B5.2050101@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC V2, PATCH 0/2] Checkpoint-assisted migration proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: amit.shah@redhat.com, thomas.knauth@googlemail.com, quintela@redhat.com Hi Eric, On 11/24/2015 06:51 PM, Eric Blake wrote: > This touches the command line, but not any QMP .json files. Is this new > feature properly discoverable using existing QMP commands, or is this > something lacking in the proposal? What exactly discoverability mechanisms must be provided? The current workflow goes like this: 1. VM is started, works for some time. This will be the migration source. 2. A migration destination is started, with -checkpoint argument passed to it (even if the checkpoint file doesn't exist). 3. A migration happens. There is no way to enable checkpoint-assisted migration at this stage, even if checkpoint file is available. But the destination computes hashes of pages that it receives. 4. The VM that was migration destination will use checkpoint-assisted migration from now on. 5. A migration source pauses after migration, and creates a checkpoint using the dump-guest-memory command. The migration destination has hashes of pages that are in the checkpoint. So the migration source uses checkpoint-assisted migration only if it previously was migration destination with -checkpoint argument. The very first migration always happens without checkpoint. We can rework this in the next revisions, if it's required. One option would not to to store hashes in the migration destination, but to load the checkpoint explicitly in the migration source before migration. -- With best regards, Bohdan Trach