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

[Marcelo Tosatti]

On Tue, Feb 22, 2011 at 03:11:06PM -0600, Anthony Liguori wrote:
> 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.

This is a different case. The mgmt tool should be able to safely store
the desired device tree before hotplugging a device.

And even if you consider that should be done by QEMU, in a config file,
restarting the guest with or without the device is not going to result
in data corruption/loss.

Image switch is critical because using an outdated image will result in
data corruption.

> 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.

I don't disagree the commit message could be in a config file, but since
that does not exist, a separate file is a workable solution. Also, the
separate commit file is not incompatible with future improvements.