qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/6] Mirrored writes using blockdev-transacti


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v2 0/6] Mirrored writes using blockdev-transaction
Date: Mon, 05 Mar 2012 08:47:06 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]