From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51652)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <grhookatwork@gmail.com>) id 1Xqm0M-0007oz-LS
	for qemu-devel@nongnu.org; Tue, 18 Nov 2014 11:51:59 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <grhookatwork@gmail.com>) id 1Xqm0D-0002Fx-KO
	for qemu-devel@nongnu.org; Tue, 18 Nov 2014 11:51:50 -0500
Received: from mail-oi0-x243.google.com ([2607:f8b0:4003:c06::243]:44591)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <grhookatwork@gmail.com>) id 1Xqm0D-0002FZ-G2
	for qemu-devel@nongnu.org; Tue, 18 Nov 2014 11:51:41 -0500
Received: by mail-oi0-f67.google.com with SMTP id u20so485555oif.2
	for <qemu-devel@nongnu.org>; Tue, 18 Nov 2014 08:51:40 -0800 (PST)
Received: from Gary.local (67-198-50-36.static.grandenetworks.net.
	[67.198.50.36]) by mx.google.com with ESMTPSA id
	fv9sm15434735oeb.10.2014.11.18.08.51.40 for <qemu-devel@nongnu.org>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 18 Nov 2014 08:51:40 -0800 (PST)
Message-ID: <546B791B.6040908@gmail.com>
Date: Tue, 18 Nov 2014 10:51:39 -0600
From: Gary R Hook <grhookatwork@gmail.com>
MIME-Version: 1.0
References: <546B781B.3070309@gmail.com>
In-Reply-To: <546B781B.3070309@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [Qemu-devel] Tunneled Migration with Non-Shared Storage
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

What I really need to figure out is why, when performing a migration
using non-shared storage, an entire VM is copied into memory before it’s 
sent across the wire using this method. A copy-on-read operation
is performed first, then the disk is sent, then the dirty pages, then
the RAM.

The odd thing is that non-tunneled migrations use a completely different
code path that does _not_ execute a copy-on-read first.

The problem: VMs (VM disks) that are larger than available memory can't
be migrated due to space constraints.

I'd like to disable this COR opration but I think it's important to
understand why the code is written this way. I've yet to run across any
comments that explain the need for this "extra" copy, and am looking
for background and advice.

Any insights are welcome.

-- 
Gary R Hook
Senior Kernel Engineer
NIMBOXX, Inc