From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCWKu-0003QW-0m for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:35:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCWKt-0003P0-5L for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:35:27 -0500 Received: from [199.232.76.173] (port=59921 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCWKt-0003Oi-1g for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:35:27 -0500 Received: from ns.suse.de ([195.135.220.2]:56856 helo=mx1.suse.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCWKs-0003Om-FZ for qemu-devel@nongnu.org; Tue, 16 Dec 2008 04:35:26 -0500 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 05B7F44C0B for ; Tue, 16 Dec 2008 10:35:23 +0100 (CET) Message-ID: <49477773.3060405@suse.de> Date: Tue, 16 Dec 2008 10:40:03 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel][PATCH] Qemu image over raw devices References: <246345442.373921229413849052.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> In-Reply-To: <246345442.373921229413849052.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: 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 Shahar Frank schrieb: > ----- "Kevin Wolf" wrote: > >> Shahar Frank schrieb: >>> 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. >> When would I need to explicitly specify the type of a backing file? > > The patch doesn't allow you to specify a type (image format). It allows you to force probing. This is done to override the default block-device => raw semantics. Ok, I see. But didn't we want to get rid of the probing whenever possible because you can't tell raw files from whatever other format reliably? >>> The patch includes the following: >>> >>> 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" >> IIUC, on qemu side this is just another syntax for -drive format=xyz? >> Wouldn't it be better to add a parameter to qemu-img then instead of >> inventing new ways of specifying the format? > > The problem is with the backing file, this format does not apply to the backing file and this is the correct behavior - the backing file can be of a different format. Note that the new way is just forcing probing. You don't specify the backing file on the command line, so that's not what I meant. I really thought only of the parameters to qemu you specify on the command line. IMHO, the really correct behaviour would be that the image doesn't only save the path but also the image format of the backing file - and then add a parameter to qemu-img to specify that type. This would need a change to qcow2 of course, but I think you can make it a compatible change: Writing something like "image.qcow2\0qcow2" as backing file to the image should do the trick. And then qcow2 would check if the driver is specified and opens the file with exactly that driver instead of guessing and possibly being fooled by a bad guest (ok, it's not that bad with a backing file because the guest can't write to it directly, but you can still commit). >>> 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/ >> Does it even make sense to store qcow2 images on raw block devices? >> qcow2 are usually growing whereas devices tend to not change their >> size. >> > > The idea is to allow QCOW2 (or similar formats) capabilities in SAN only environment, where SAN-FS is not applicable (for example because it is too expensive or too complex). > > For the size issue, Logical volumes can be extended. In the near future some patches that allow monitoring the internal space usage and then extend the LV size are going to be posted to this list. Another issue that has to be handled is out of space (out of range) scenarios. That sounds interesting. :-) How is growing LVs performance-wise? Just about the same as growing a file or does it take noticably longer? Kevin