From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiqPQ-0001Vx-UN for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:47:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiqPK-0003ef-En for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:47:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiqPK-0003eE-6I for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:47:46 -0500 Message-ID: <50C8C33F.1050304@redhat.com> Date: Wed, 12 Dec 2012 10:47:43 -0700 From: Eric Blake MIME-Version: 1.0 References: <1354267354-1028712-1-git-send-email-dietmar@proxmox.com> <1354267354-1028712-3-git-send-email-dietmar@proxmox.com> In-Reply-To: <1354267354-1028712-3-git-send-email-dietmar@proxmox.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig9FE4C517A5488E52C9681775" Subject: Re: [Qemu-devel] [PATCH v2 3/6] add backup related monitor commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9FE4C517A5488E52C9681775 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/30/2012 02:22 AM, Dietmar Maurer wrote: > We use a generic BackupDriver struct to encaplulated all archive format= s/encaplulated/encapsulated/ > related function. >=20 > Another option would be to simply dump = to > the output fh (pipe), and an external binary saves the data. That way w= e > could move the whole archive format related code out of qemu. I'm coming into this review late, so I'm not sure what your series is adding that cannot already be done with external snapshots and migration to file. But any time someone proposes new QMP commands that libvirt might have to interact with, I try to chime in: >=20 > Signed-off-by: Dietmar Maurer > --- > backup.h | 14 +++ > blockdev.c | 337 ++++++++++++++++++++++++++++++++++++++++++++++= ++++++++ > hmp-commands.hx | 31 +++++ > hmp.c | 63 ++++++++++ > hmp.h | 3 + > monitor.c | 7 + > qapi-schema.json | 81 +++++++++++++ > qmp-commands.hx | 27 +++++ > 8 files changed, 563 insertions(+), 0 deletions(-) >=20 > +++ b/qapi-schema.json > @@ -358,6 +358,39 @@ > { 'type': 'EventInfo', 'data': {'name': 'str'} } > =20 > ## > +# @BackupStatus: > +# > +# Detailed backup status. > +# > +# @status: #optional string describing the current backup status. > +# Tthis can be 'active', 'done', 'error'. If this field is no= t s/Tthis/This/ > +# returned, no backup process has been initiated > +# > +# @errmsg: #optional error message (only returned if status is 'error'= ) > +# > +# @total: #optional total amount of bytes involved in the backup proce= ss > +# > +# @transferred: #optional amount of bytes already backed up. > +# > +# @zero-bytes: #optional amount of 'zero' bytes detected. > +# > +# @start-time: #optional time (epoch) when backup job started. Should you account for sub-second resolution here > +# > +# @end-time: #optional time (epoch) when backup job finished. and here? > +# > +# @backupfile: #optional backup file name > +# > +# @uuid: #optional uuid for this backup job > +# > +# Since: 1.4.0 > +## > +{ 'type': 'BackupStatus', > + 'data': {'*status': 'str', '*errmsg': 'str', '*total': 'int', > + '*transferred': 'int', '*zero-bytes': 'int', > + '*start-time': 'int', '*end-time': 'int', > + '*backupfile': 'str', '*uuid': 'str' } } > + > +## > # @query-events: > # > # Return a list of supported QMP events by this server > @@ -1764,6 +1797,54 @@ > 'data': { 'path': 'str' }, > 'returns': [ 'ObjectPropertyInfo' ] } > =20 > + > +## > +# @backup: > +# > +# Starts a VM backup. > +# > +# @backupfile: the backup file name I guess the fdset mechanism is how libvirt would pass in a pipe fd rather than supplying an actual file name. Does your implementation allow for pipes, or must it be seekable? > +# > +# @format: format of the backup file Rather than letting this be a free-form string, it would be nicer as an enum of actually supported formats. > +# > +# @config-filename: #optional name of a configuration file to include = into > +# the backup archive. > +# > +# @speed: #optional the maximum speed, in bytes per second > +# > +# Returns: the uuid of the backup job UUID in raw byte format, or in ASCII format? (Assuming the latter) > +# > +# Since: 1.4.0 > +## > +{ 'command': 'backup', 'data': { 'backupfile': 'str', '*format': 'str'= , backupfile sounds like a run-on; is it any better to name it backup-file?= > + '*config-filename': 'str', especially when compared with config-filename --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig9FE4C517A5488E52C9681775 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQyMM/AAoJEKeha0olJ0NqSUsH/0XPevGAia7Y+fU7X7gR2szo h7MmYjXLeQrkNIJO77e+FXjzob3UXUw9zyghTIyrCCQa3yevIaVsHFGEq6TPgfht Ovx+4b1a4baDMmnXm7ZBXcJpaLSfVrDGEpx2DjYZxQlGVLFmimzjD4Z6fe5AZAY3 9r7awLYmt+9DjqDN+gzVuea9rh+O7EyRrUoZpunhQgUHVaxdA74ue7GtPqmDe7S8 s/gibx163k8EKRpvDJNTIalYQgXS/PYE9GSHupvKeSb2eUMK6ALy+/WdVYSTAGmk YzE3msscYCIK1/yNhRJY6zswBZ3O3POKln2jcnk2ejynf2InWXxqq7cLfvxAVC0= =I/yr -----END PGP SIGNATURE----- --------------enig9FE4C517A5488E52C9681775--