On 03/05/2012 02:53 AM, Kevin Wolf wrote:
Am 01.03.2012 22:10, schrieb Anthony Liguori:
On 03/01/2012 05:21 AM, Paolo Bonzini wrote:
This implements all ingredients to establish mirrored writes.
The drive-reopen command that is used to terminate mirrored writes
is not included in this series.
Tested with the following scenarios:
a) mirror only
1) create base.qcow2 and start QEMU with it
2) Execute the following QMP command
{ "execute": "qmp_capabilities" }
{ "execute": "blockdev-transaction", "arguments":
{'actions': [
{ 'type': 'mirror', 'data' :
{ 'device': 'ide0-hd0', 'target': '/home/pbonzini/mirror.qcow2' } } ] }
}
{ "execute": "cont" }
3) hibernate the guest (this requires an IDE disk and -cpu kvm64,-kvmclock)
4) restart the guest with mirror.qcow2
b) atomic snapshot+mirror
1) start QEMU with an existing image test.img
2) Execute the following QMP command
{ "execute": "qmp_capabilities" }
{ "execute": "blockdev-transaction", "arguments":
{'actions': [
{ 'type': 'snapshot', 'data' :
{ 'device': 'ide0-hd0', 'snapshot-file': '/home/pbonzini/base.qcow2' }
},
{ 'type': 'mirror', 'data' :
{ 'device': 'ide0-hd0', 'target': '/home/pbonzini/mirror.qcow2' } } ] }
}
{ "execute": "cont" }
We don't have schema introspection today. How would one determine when new
transaction types are available?
I think we need some sort of introspection method too in order for clients to
figure out when the command is extended.
How about coupling the types with independently available commands for
now? We would rename 'snapshot' to 'blockdev-snapshot-sync', which does
the same thing outside of transactions. The mirror patches would then
introduce a 'drive-mirror' top-level command at the same time as they
introduce a 'drive-mirror' transaction type.
I think it's reasonable but we need to make sure to document the relationship
here explicitly in the schema.
Regards,
Anthony Liguori
Kevin
