From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MoJ64-0005bM-QF
	for qemu-devel@nongnu.org; Thu, 17 Sep 2009 11:40:36 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MoJ60-0005Wb-8t
	for qemu-devel@nongnu.org; Thu, 17 Sep 2009 11:40:36 -0400
Received: from [199.232.76.173] (port=52591 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MoJ60-0005WL-2y
	for qemu-devel@nongnu.org; Thu, 17 Sep 2009 11:40:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:55504)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1MoJ5z-00031Z-F5
	for qemu-devel@nongnu.org; Thu, 17 Sep 2009 11:40:31 -0400
Message-ID: <4AB25813.8040604@redhat.com>
Date: Thu, 17 Sep 2009 17:38:59 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 0/3 v3] Live migration without shared
	storage
References: <1253194297802-git-send-email-lirans@il.ibm.com>
	<4AB24198.5070707@siemens.com>
In-Reply-To: <4AB24198.5070707@siemens.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: lirans@il.ibm.com
Cc: qemu-devel@nongnu.org

Am 17.09.2009 16:03, schrieb Jan Kiszka:
> lirans@il.ibm.com wrote:
>> This series adds support for live migration without shared storage, means 
>> copy the storage while migrating. It was tested with KVM. Supports 2 ways 
>> to replicate the storage during migration:
>>  1. Complete copy of storage to destination 
>>  2. Assuming the storage is cow based, copy only the allocated 
>>     data, time of the migration will be linear with the amount of allocated 
>>     data (user responsibility to verify that the same backend file reside 
>>     on src and destination).
> 
> For my understanding: Does it require the use of qcow[2] or does it also
> work with raw images?

This leads me to the question what the block migration is doing with
qcow2 images (or better: images in any format but raw). What happens
with non-standard image options (like cluster size)? Are snapshots
copied over or won't they be available any more on the destination host?

Kevin