[Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/22/2011 03:07 PM, Marcelo Tosatti wrote:
> On Tue, Feb 22, 2011 at 02:50:09PM -0600, Anthony Liguori wrote:
>    
>>> +static int write_commit_file(BdrvCopyState *s)
>>> +{
>>> +    char commit_msg[1400];
>>> +    const char *buf = commit_msg;
>>> +    int len, ret;
>>> +
>>> +    sprintf(commit_msg, "commit QEMU block_copy %s ->   %s\n", s->src_device_name,
>>> +                        s->dst_filename);
>>> +
>>> +    len = strlen(commit_msg);
>>> +    while (len>   0) {
>>> +        ret = write(s->commit_fd, buf, len);
>>> +        if (ret == -1&&   errno == EINTR) {
>>> +            continue;
>>> +        }
>>> +        if (ret<= 0) {
>>> +            return -errno;
>>> +        }
>>> +        buf += ret;
>>> +        len -= ret;
>>> +    }
>>> +
>>> +    if (fsync(s->commit_fd) == -1) {
>>> +        return -errno;
>>> +    }
>>>
>>>        
>> This is more or less black magic.  What is this commit file used for
>> and why aren't we using something like a QMP event?
>>      
> The commit file is considered reliable storage for the result of image
> switch operation. Think of the following scenario:
>
> - mgmt app requests live copy of guests ide1-hd0
> from /a/image.img to /b/image.img.
> - mgmt app dies.
> - guest switches to /b/image.img, /a/image.img is outdated.
> - guest dies.
>
> Notifying the switch via QMP would not be reliable in this case.
>    

But this is true of any number of operations in QEMU such as hotplug 
where if a management tool dies after requesting hotplug and then the 
guest dies before the management tool reconnects, it's never known 
whether it's truly connected or not.

The only way to robustly solve this is for QEMU to maintain a stateful 
config file.  A one-off for this particular command doesn't seem wise to me.

Regards,

Anthony Liguori

> Will add this as a comment in the code.
>
>