From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCXtR-0003Uf-5k for qemu-devel@nongnu.org; Tue, 16 Dec 2008 06:15:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCXtN-0003SD-Mx for qemu-devel@nongnu.org; Tue, 16 Dec 2008 06:15:12 -0500 Received: from [199.232.76.173] (port=51730 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCXtN-0003S8-7G for qemu-devel@nongnu.org; Tue, 16 Dec 2008 06:15:09 -0500 Received: from mx1.redhat.com ([66.187.233.31]:46461) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCXtM-00032R-OG for qemu-devel@nongnu.org; Tue, 16 Dec 2008 06:15:09 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mBGBF74g031305 for ; Tue, 16 Dec 2008 06:15:07 -0500 Received: from file.fab.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBGBF6Kd020922 for ; Tue, 16 Dec 2008 06:15:06 -0500 Received: from file.fab.redhat.com (localhost.localdomain [127.0.0.1]) by file.fab.redhat.com (8.13.1/8.13.1) with ESMTP id mBGBF6D5020284 for ; Tue, 16 Dec 2008 11:15:06 GMT Received: (from berrange@localhost) by file.fab.redhat.com (8.13.1/8.13.1/Submit) id mBGBF6FE020256 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 11:15:06 GMT Date: Tue, 16 Dec 2008 11:15:06 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel][PATCH] Qemu image over raw devices Message-ID: <20081216111506.GB20024@redhat.com> References: <494663E4.3020409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494663E4.3020409@redhat.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, Dec 15, 2008 at 04:04:20PM +0200, Shahar Frank wrote: > Hi, > > The following patch enables QEMU to create and use images with any > format on top of a raw device. Note that -f is not enough for > bcking files support. > 1. The check for block devices is weaken so you can override it by > specifying a protocol > 2. If a protocol exists but not found in the protocols list, the logic > falls back to image type probing. This means use can write > "probe:filename" or just ":filename" > > Note that if regular file/device path names are used, the previous > behavior is kept. > > lvcreate -L 5G -n base store > dd bs=32k if=win.qcow2 of=/dev/store/base > ./qemu-img info :/dev/store/base > lvcreate -L 2G -n l2 store > ./qemu-img create -b :/dev/store/base -f qcow2 /dev/store/l2 > ./x86_64-softmmu/qemu-system-x86_64 -hda :/dev/store/l2 -L pc-bios/ > lvcreate -L 2G -n l3 store > ./qemu-img create -b :/dev/store/l2 -f qcow2 /dev/store/l3 > ./x86_64-softmmu/qemu-system-x86_64 -hda :/dev/store/l3 -L pc-bios/ This embedded ':' syntax is really very disgusting. The -hda/b/c/d args are all legacy options defined to use autoprobing. Since autoprobing is a potential security flaw these args should really never be used anymore where there's a possibility of using raw disk formats. The new arg "-drive" already has support for explicitly specifying the disk image format and so this doesn't need re-inventing for block devices -drive file=/dev/store/l3,format=qcow2 It is already possible to create a qcow2 file on a block device giving an explicit format # qemu-img create -f qcow2 /dev/HostVG/Guest1 100M Formatting '/dev/HostVG/Guest1', fmt=qcow2, size=102400 kB # qemu-img info -f qcow2 /dev/HostVG/Guest1 image: /dev/HostVG/Guest1 file format: qcow2 virtual size: 100M (104857600 bytes) disk size: 0 cluster_size: 4096 So the missing bit at create time is being able to specify the format of the backing store. Currently qemu-img always probes the backing store format which is not satisfactory. That's easily fixed though by adding an explicit '-F backing_fmt' arg that can be used. # qemu-img create -b /dev/HostVG/Backing -F qcow2 -f qcow2 /dev/HostVG/Guest1 The second problem is that the format of the backing file is never stored in the QCOw2 header so when the disk is used, it resorts to probing again. The most desriable way to fix this would be to encode the format of the backing file in the QCOw2 header, since we explicitly know this at time of the call which did 'qemu-img create -b backingfile'. That has compat problems though, so we should extend the -drive arg to allow probing of backing file formats to be disabled (making it assume backing store is same format as child image), or to be fixed to a specific format (eg, fix the backing store as raw). Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|