qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 20/20] monitor: add commands to start/stop dirty


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 20/20] monitor: add commands to start/stop dirty bitmap
Date: Fri, 21 Dec 2012 11:30:41 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/12/2012 06:46 AM, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>  blockdev.c       | 55 +++++++++++++++++++++++++++++++++++++++++++++++
>  blockdev.h       |  1 +
>  hmp-commands.hx  | 39 ++++++++++++++++++++++++++++++++++
>  hmp.c            | 27 +++++++++++++++++++++++
>  hmp.h            |  2 ++
>  qapi-schema.json | 56 ++++++++++++++++++++++++++++++++++++++++++++++++
>  qmp-commands.hx  | 65 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  7 files changed, 245 insertions(+)
> 

A bit light on the commit message.  What is the proper sequence of QMP
commands for using this feature in relation to driver-mirror and such?
For example, let's say I want to start a mirror, then shutdown qemu,
then start a new qemu -S; what is the right sequence for when to call
this to re-initialize the dirty bitmap and resume the mirror at the same
point, all prior to issuing 'cont' to the new qemu instance?  Once I
know that, then I can fix libvirt to allow disk-copy across qemu
restarts (right now, libvirt limits disk-copy to transient domains,
since those don't have to worry about restarts).

> +If the dirty bitmap is already active, or used by something else (for
> +example @command{drive_mirror}), the granularity argument must be absent
> +or equal to the active granularity.  The granularity must be a power-of-two
> +comprised between 4,096 and 67,108,864.

4k to 64M here...

> +++ b/qapi-schema.json
> @@ -3028,3 +3028,59 @@
>  # Since: 1.3.0
>  ##
>  { 'command': 'nbd-server-stop' }
> +
> +##
> +# @blockdev-dirty-enable:
> +#

> +# @granularity: #optional granularity of the dirty bitmap, default is 64K
> +#               if the image format doesn't have clusters, 4K if the clusters
> +#               are smaller than that, else the cluster size.  Must be a
> +#               power of 2 between 512 and 64M.

but 512 here.  Which is right?

> +#
> +# Returns: Nothing on success
> +#
> +# Since: 1.3

1.4, now

> +##
> +{ 'command': 'blockdev-dirty-enable',
> +  'data': {'device': 'str', 'filename': 'str', '*granularity': 'uint32' } }
> +
> +##
> +# @blockdev-dirty-disable:
> +#
> +# Stop tracking dirty blocks for a block device.  Dirty blocks will
> +# be written to an on-disk file, with one bit per block and an arbitrary
> +# granularity.
> +#
> +# If the dirty bitmap is already active, or used by something else (for
> +# example blockdev-drive-mirror), the granularity argument must be absent

You named it 'drive-mirror', not 'blockdev-drive-mirror'.

> +# or equal to the active granularity.
> +#
> +# @device: the name of the device to track dirty blocks of
> +#
> +# @force: #optional true to immediately stop writing to the dirty
> +#         bitmap file; false to do so only when the last user of the
> +#         dirty bitmap stops using it (default false)
> +#
> +# Returns: Nothing on success
> +#
> +# Since: 1.3

Again, 1.4.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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