Re: [Qemu-devel] [PATCH] migration: adding migration to/from a file

[Uri Lublin <uril@redhat.com>]

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.