[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v11 20/27] Support colo mode for qemu disk
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |