From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LPERt-0007o8-5Q
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:07:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LPERr-0007nf-Tj
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:07:12 -0500
Received: from [199.232.76.173] (port=47592 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LPERr-0007nZ-J4
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:07:11 -0500
Received: from mx2.redhat.com ([66.187.237.31]:37967)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <uril@redhat.com>) id 1LPERr-0000S0-3X
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:07:11 -0500
Message-ID: <4975AFE3.4050708@redhat.com>
Date: Tue, 20 Jan 2009 13:05:07 +0200
From: Uri Lublin <uril@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file
References: <1232324325-25060-1-git-send-email-uril@redhat.com>
	<200901190055.57922.paul@codesourcery.com>
In-Reply-To: <200901190055.57922.paul@codesourcery.com>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

Paul Brook wrote:
> On Monday 19 January 2009, Uri Lublin wrote:
>> Migration to file, reuses migration-to-fd.
>> Migration from file, uses qemu-fopen directly.
>>
>> The saved state-file should be used only once and removed (or used
>> with -snapshot, or a the disk-image should be copied), as the
>> disk image is not saved, only the VM state.
>>
>> Also there is not point of doing a _live_ migration to file (except
>> for debugging migration code), so I recommend to stop the VM before
>> migrating its state to a file.
>>
>> An advantage migration-to-file over savevm/loadvm is that for the latter
>> a qcow2 is a requirement, while the former works for any image-format.
> 
> Wouldn't it be better to just implement savevm to file?
> 
> Paul

It sure is simpler.

The possible advantage of migration-to-file (over savevm-to-file) is that in the 
future we may want to implement vm-snapshoting (live save to file + snapshot 
disk-image).

I've implemented a savevm_file, and will send it in a separate email.

Thanks,
    Uri.