From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: Why QCOW1? Date: Fri, 15 Apr 2011 14:17:05 +0200 Message-ID: <4DA83741.80602@redhat.com> References: <1302722762-30517-1-git-send-email-prasadjoshi124@gmail.com> <4DA6AA2F.2020306@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , Markus Armbruster , Prasad Joshi , mingo@elte.hu, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, levinsasha928@gmail.com, stefanha@linux.vnet.ibm.com To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50284 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751205Ab1DOMOv (ORCPT ); Fri, 15 Apr 2011 08:14:51 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Am 15.04.2011 14:05, schrieb Stefan Hajnoczi: > On Fri, Apr 15, 2011 at 12:17 PM, Pekka Enberg wrote: >> On Fri, Apr 15, 2011 at 1:14 PM, Stefan Hajnoczi wrote: >>> Why even use a non-raw image format? The current implementation only >>> does sparse files, but POSIX sparse raw files gives you the same >>> feature. >> >> Because people have existing images they want to boot to? > > People don't have existing QCOW1 images they want to boot from :). > > They have vmdk, vhd, vdi, or qcow2. You can use qemu-img to convert > them to raw. You can use qemu-nbd if you are desperate to boot from > or inspect them in-place. > > But I think the natural path for a native Linux KVM tool is to fully > exploit file systems and block layer features in Linux instead of > implementing a userspace block layer. As a normal user, I can deal with files, but I can't write to block devices or mount file systems. I'm sure that there are use cases that don't require file-based formats, but I'm also relatively sure that they are a minority (at least if you also take convenience into consideration). Kevin