From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIIOa-0006kZ-Gb for qemu-devel@nongnu.org; Fri, 15 Aug 2014 10:22:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XIIOV-0004Vh-Hk for qemu-devel@nongnu.org; Fri, 15 Aug 2014 10:22:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XIIOV-0004VS-9f for qemu-devel@nongnu.org; Fri, 15 Aug 2014 10:22:15 -0400 Message-ID: <53EE1794.30406@redhat.com> Date: Fri, 15 Aug 2014 08:22:12 -0600 From: Eric Blake MIME-Version: 1.0 References: <1406900401-19550-1-git-send-email-lkurusa@redhat.com> <20140812132034.GM20490@stefanha-thinkpad.redhat.com> <20140812133542.GA6876@localhost.localdomain> <1643597569.19303034.1408027347194.JavaMail.zimbra@redhat.com> <20140814145733.GA2399@localhost.localdomain> <20140815105519.GC3770@noname.redhat.com> <20140815121402.GB2399@localhost.localdomain> <20140815133756.GF3770@noname.redhat.com> <53EE1273.7020303@redhat.com> <20140815141056.GA20938@localhost.localdomain> In-Reply-To: <20140815141056.GA20938@localhost.localdomain> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mavJnTapoQ21ekWtv4papiD9JhEn9PssC" Subject: Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: Kevin Wolf , Levente Kurusa , Fam Zheng , Stefan Weil , Andrew Jones , QEMU Developers , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mavJnTapoQ21ekWtv4papiD9JhEn9PssC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/15/2014 08:10 AM, Jeff Cody wrote: > On Fri, Aug 15, 2014 at 08:00:19AM -0600, Eric Blake wrote: >> On 08/15/2014 07:37 AM, Kevin Wolf wrote: >> >>> We can choose Markus's suggestion of using the file name to guess the= >>> format. I don't really like it much, but it seems like a fair comprom= ise >>> that doesn't hurt usability as much. >> >> In other words, if a user gives a file a "known suffix", then it is >> their own fault if they made that file raw and the guest then happened= >> to convert the file to the format matching the suffix? Or would this >> start giving warnings if the known suffix doesn't match the probed con= tents? >> >=20 > (Eric, I should have cc'ed you on my last email, sorry) >=20 > Image this scenario: >=20 > existing chain created a while ago, via: >=20 > qemu-img create -f qcow2 foo.img 1G > qemu-img create -f qcow2 -b foo.img bar.img 1G >=20 Libvirt refuses to create files without backing format encoded; but is still stuck dealing with files created externally (such as qemu-img create) where it was forgotten. >=20 > User launches qemu by this commandline: >=20 > qemu-kvm -drive file=3Dbar.img,format=3Dqcow2 >=20 >=20 > Old behavior: >=20 > | foo.img | <--- | bar.img | > | (qcow2) | | (qcow2) | >=20 > New behavior: >=20 > | foo.img | <--- | bar.img | > | (raw) | | (qcow2) | Libvirt already assumed raw for any image where encoding was not specified, so this scenario is already a risky one for the user. >=20 >=20 > So I think we want to make sure that we don't just fall back to raw > for unknown filename extensions. Remember, if a probe determines a file is raw, it is safe to use as raw. Falling back to raw is IDEAL. What _might_ be nice is teaching qemu-img to auto-encode the backing format during 'qemu-img create' (it can be assumed that _at creation time_, the backing file hasn't had a chance to be corrupted by the guest yet) rather than the current behavior of only encoding an explicit format given by the user. Furthermore, an explicit encoding from the user should ALWAYS be trusted, and the user can override any place where automatic heuristics would have guessed differently (whether those heuristics were based on probing, file extension, or otherwise). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --mavJnTapoQ21ekWtv4papiD9JhEn9PssC 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT7heUAAoJEKeha0olJ0NqtAUH/RSrsCyuy6xB/ZGq48QezR83 UDF+mIng7/8JQuSBE62FT/t2I1fi2b1RjXMLHNIklf8/8KKnTTGtSwKJ2lzQLGYp hnSIWpgguKRHKEOUVxxnC0vMo8PTTecsEaQC0Ub/UH/K+7PkgJroqVttCy7F1QmW ABYvio4nbE1weIO3n5r+j+8ZqiEpCooLJEfFBLju/W0rP27VUzW1QeR/xVLFUdfA Vp0Gkxr9I9qGAxWi65yf8DmZSlbRapNaai+2bfhInMuon5ywEorUA3ualsMKhBaB SyVIr/4yV+BmsRChXheR3vo4+ncA1NXBODNzFPZdCXNv/hqlGPets9otdk3aHMc= =Csrr -----END PGP SIGNATURE----- --mavJnTapoQ21ekWtv4papiD9JhEn9PssC--