Qemu image over raw devices
PATCH 1/1 Qemu image over raw devices
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.
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"
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/
block.c +31 -13
@@ -226,6 +226,17 @@ static int is_windows_drive(const char *filename) }#endif +static const char *raw_filename (const char *filename) +{ +char *_filename; + + _filename =strchr (filename,':' ); +if (_filename) +return _filename +1 ; +else +return filename; +} +static BlockDriver *find_protocol (const char *filename) {BlockDriver *drv1;
@@ -267,25 +278,28 @@ static BlockDriver *find_image_format(const char *filename)recognized as a host CDROM */ if (strstart (filename,"/dev/cdrom" ,NULL ))return &bdrv_host_device; + drv =find_protocol (filename); + +if (drv == &bdrv_raw) {#ifdef _WIN32 -if (is_windows_drive (filename)) -return &bdrv_host_device; +if (is_windows_drive (filename)) +return &bdrv_host_device;#else - { -struct stat st; -if (stat (filename, &st) >=0 && - (S_ISCHR (st.st_mode) ||S_ISBLK (st.st_mode))) { -return &bdrv_host_device; - } - } + { +struct stat st; +if (stat (filename, &st) >=0 && + (S_ISCHR (st.st_mode) ||S_ISBLK (st.st_mode))) { +return &bdrv_host_device; + } + }#endif + } - drv =find_protocol (filename);/* no need to test disk image formats for vvfat */ if (drv == &bdrv_vvfat)return drv; - ret =bdrv_file_open (&bs, filename,BDRV_O_RDONLY ); + ret =bdrv_file_open (&bs,raw_filename (filename),BDRV_O_RDONLY );if (ret <0 )return NULL ; ret =bdrv_pread (bs,0 , buf,sizeof (buf));
@@ -335,6 +349,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,int ret, open_flags;char tmp_filename[PATH_MAX ];char backing_filename[PATH_MAX ]; +char const *_filename; bs->read_only =0 ; bs->is_temporary =0 ;
@@ -403,9 +418,12 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags, open_flags =BDRV_O_RDWR | (flags &BDRV_O_CACHE_MASK ); else open_flags = flags & ~(BDRV_O_FILE |BDRV_O_SNAPSHOT ); - ret = drv->bdrv_open (bs, filename, open_flags); + + _filename =raw_filename (filename); + + ret = drv->bdrv_open (bs, _filename, open_flags);if ((ret == -EACCES || ret == -EPERM ) && !(flags &BDRV_O_FILE )) { - ret = drv->bdrv_open (bs, filename, open_flags & ~BDRV_O_RDWR ); + ret = drv->bdrv_open (bs, _filename, open_flags & ~BDRV_O_RDWR ); bs->read_only =1 ; }if (ret <0 ) {
qemu-img.c +0 -0
block.c +31 -13
77 lines not on this page · raw message
qemu-img.c +0 -0
Quoted 3 lines · Shahar Frank
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.
When would I need to explicitly specify the type of a backing file?
Quoted 7 lines
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?
Quoted 12 lines
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.
Kevin
Quoted 15 lines · Shahar Frank
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.
Quoted 9 lines
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
Signature · 4 lines
|: 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 :|