From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LPEqN-0006Vm-Qk
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:32:31 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LPEqN-0006VL-3q
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:32:31 -0500
Received: from [199.232.76.173] (port=34282 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LPEqM-0006VF-SS
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:32:30 -0500
Received: from mx2.redhat.com ([66.187.237.31]:38389)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <uril@redhat.com>) id 1LPEqM-0003rV-EM
	for qemu-devel@nongnu.org; Tue, 20 Jan 2009 06:32:30 -0500
Message-ID: <4975B648.5050104@redhat.com>
Date: Tue, 20 Jan 2009 13:32:24 +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>
	<49749820.2070209@codemonkey.ws>
In-Reply-To: <49749820.2070209@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

Anthony Liguori wrote:
> 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.
>>
>> Signed-off-by: Uri Lublin <uril@redhat.com>
>> ---

>> +
>> +MigrationState *file_start_outgoing_migration(const char *filename,
>> +                                              int64_t bandwidth_limit,
>> +                                              int async)
>> +{
>> +    FdMigrationState *s;
>> +    int fd;
>> +
>> +    s = qemu_mallocz(sizeof(*s));
>> +    if (s == NULL) {
>> +        perror("file_migration: qemu_mallocz failed");
>> +        term_printf("file_migration: qemu_mallocz failed");
>> +        goto err1;
>> +    }
>> +
>> +    fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0600);
>> +    if (fd < 0) {
>> +        perror("file_migration: failed to open filename");
>> +        term_printf("file_migration: failed to open filename %s\n", 
>> filename);
>> +        goto err2;
>> +    }
>>   
> 
> The migration code assumes that the file descriptor used is 
> non-blocking.  In general, open() on a file system cannot produce a 
> non-blocking file descriptor.

I can call fcntl with F_SETFL and O_NONBLOCK.

> 
> You could either use the posix-aio code to implement migration to a file 
> or you could introduce a fork()'d process that wrote to a file from 
> stdin.  Although this is basically just exec dd of=.

We started with "exec dd..." for saving state in a file. It's obviously not the 
best solution, as it needs to fork/exec/pipe instead of just open a file.

Thanks,
    Uri.