Skip to contentSkip to conversation

Qemu image over raw devices

PATCH In review Shahar Frank 3 participants 3 messages Dec 15, 2008 – Dec 16, 2008

lore
Share & tools
lore
#0 lore raw

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
index 28d63d7..cbf9968 100644
@@ -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
#1 lore raw
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

#2 lore raw
In reply to Shahar Frank
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 :|