From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10xM-0007CS-Mu for qemu-devel@nongnu.org; Fri, 24 Feb 2012 14:37:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S10xK-0003dN-TD for qemu-devel@nongnu.org; Fri, 24 Feb 2012 14:37:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10xK-0003d6-LM for qemu-devel@nongnu.org; Fri, 24 Feb 2012 14:37:26 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1OJbPkl031013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Feb 2012 14:37:25 -0500 Message-ID: <4F47E6F4.6040501@redhat.com> Date: Fri, 24 Feb 2012 12:37:24 -0700 From: Eric Blake MIME-Version: 1.0 References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> <1330102144-14491-2-git-send-email-fsimonce@redhat.com> <4F47CCF2.1090007@redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig3851A48F065A74ADA39EA440" Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3851A48F065A74ADA39EA440 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/24/2012 11:57 AM, Paolo Bonzini wrote: > On 02/24/2012 06:46 PM, Eric Blake wrote: >> I think you need to be more explicit that @new-image-file MUST have >> identical contents as the current image file, for this to be useful, a= nd >> that qemu does not validate whether the new image met those conditions= =2E >> Possible ways to achieve this: >=20 > Not necessarily, you could always do this on a paused machine. You lost me; I think you snipped too much. Was it about this statement in my original? >> 1. Freeze all guest I/O, so that you know the current image file is >> stable, To which I have a counter-question: Is pausing a machine guaranteed to flush all I/O out to the image prior to returning control to the controlling app, or do we have to rely on the qemu-ga agent command to actually freeze I/O within the guest? Overall, I was arguing that from a usability perspective, if new-image-file does not have the same contents (from the guest's perspective) as the current image, then when you resume the machine, you will be injecting arbitrary disk changes into the guest's disk, probably with disastrous results. I'm not arguing that new-image-file has to be identical to the current image (in fact, converting between raw or qcow2 via drive-reopen seems like great use cases for this new command). So documenting this distinction (guest data must be consistent across the reopen), as part of the contract of the monitor command, would be useful.= >=20 >>>> +# @destination: the destination of the block migration. >> Where do you list what format the destination is? Shouldn't this have= >> an optional format, defaulting to qcow2? Does qemu create the >> destination file, or must it already be existing? >=20 > I think no default, raw makes as much or more sense in the > non-incremental case. Anyway either autodetect, or no default. So if there is no default, then how do I specify the format? Libvirt _cannot_ rely on autodetect, ever since we had to solve a CVE where relying on autodetect would allow the guest to cause libvirt to mislabel files on the host. >> I know that this patch is only implementing the case where incremental= >> is true and new-image-file is provided; but I'm not quite sure what >> semantics are intended if incremental is false. Is that still a case >> where this sets up mirroring (writes go to two images) but additionall= y >> the contents from the current image are (asynchronously) streamed into= >> the destination? >=20 > Yes. The image should already be there also in this case, and > new-image-file will usually be omitted. If the image to be opened must already exist, then explicitly state that in the command documentation. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig3851A48F065A74ADA39EA440 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 Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPR+b1AAoJEKeha0olJ0NqcecH/3YysJkqRns0C08cnFUorIBf pIdOTl7A8Rh4H01JminY/B1zhoJ6JEVKIjblNNGatQDNNG0v+eQuoPga/vaZPbpA 9bJHBb+YhHL9g0WZR1f/a32UtWPJBx0OEMjOFZsK1fa04JAKmoAPmefF98PomjH1 2LbDHXwQDBU2oe5NmDP7keXqMBk4HwcRvwrYpxY+Ck+o0iwM2qnC40pN4k8T+Y7d emIvYdG/sc4LZsq0h2GPCC1KfE61JQqY0hjgwCJUGsGAvtC1KTgxk45Dn3sy2wC+ Rd9IiBI0jso18x+TPCHvlUXFyw9aDk18bs7KIX8M1xJzsaaA8N8Bg/8p3oICOcQ= =epVy -----END PGP SIGNATURE----- --------------enig3851A48F065A74ADA39EA440--