Re: [Qemu-devel][PATCH] Qemu image over raw devices

[Daniel P. Berrange]

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 <format> 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 :|