Re: [Xen-devel] [PATCH v11 20/27] Support colo mode for qemu disk

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Wen Congyang writes ("Re: [PATCH v11 20/27] Support colo mode for qemu disk"):
> How does block replication work:

Thanks for this explanation, which is reallt helpful.

I would like to repeat back to you what I think I have understood:

Between resynchs, you allow each VM to run in parallel and to generate
possibly-divergent disk writes.

So on host B you retain both the A and B disk writes.  They are
stored as differences (qcow2) for performance reasons.

If A fails and it becomes necessary to resume the VM only on B, you
use B's version of the VM (both disk and memory).

If B fails then A can use the A version (disk and memory).

If the two are still up, but they diverge in network traffic, you
resynch the memory from A to B, and drop B's disk and replace it with
a copy of A's.

Have I understood correctly ?


If so, what software, where, arranges for the management of the
different qcow2 `layers' ?  Ie, what creates the layers; what resynchs
them, etc. ?

The reason I started asking all these questions is because of these
parameters in your disk config:

 +    ("colo_enable", libxl_defbool),
 +    ("colo_restore_enable", libxl_defbool),
 +    ("colo_host", string),
 +    ("colo_port", string),
 +    ("colo_export", string),
 +    ("active_disk", string),
 +    ("hidden_disk", string)

For COLO to work properly it is necessary that the `active_disk' and
`hidden_disk' to relate in a specific way to the main disk: they must
be related snapshots (qcow2, currently).

Would it be possible for these disk names to have formulaic,
predicatable, names, so that they wouldn't need to be specified
separately ?

Is there any value in being able to specify them separately ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel