(Refactored) provide vhd support to qemu

[PATCH 1/4] (Refactored) provide vhd support to qemu qemu-vhd-support.patch
Provides integration of vdisk library, and implementation of block-vhd into qemu.

diff -r 005dd6b1cf8e tools/ioemu/Makefile.target
@@ -18,6 +18,8 @@ CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(S
 CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH)
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc
 CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore
+CPPFLAGS+= -I$(XEN_ROOT)/tools/vdisk -I$(XEN_ROOT)/tools/blktap/drivers
+CPPFLAGS+= -I$(XEN_ROOT)/tools/libaio/src
 ifdef CONFIG_DARWIN_USER
 VPATH+=:$(SRC_PATH)/darwin-user
 CPPFLAGS+=-I$(SRC_PATH)/darwin-user -I$(SRC_PATH)/darwin-user/$(TARGET_ARCH)

@@ -198,6 +200,7 @@ LIBS+=-L../../libxc -lxenctrl -lxenguest
 LIBS+=-L../../libxc -lxenctrl -lxenguest
 LIBS+=-L../../xenstore -lxenstore
 LIBS+=-lpthread
+LIBS+=-L$(XEN_ROOT)/tools/vdisk -lvdisk -L$(XEN_ROOT)/tools/libaio/src -laio -ldl
 ifndef CONFIG_USER_ONLY
 LIBS+=-lz
 endif

@@ -345,6 +348,7 @@ VL_OBJS+=cutils.o
 VL_OBJS+=cutils.o
 VL_OBJS+=block.o block-raw.o
 VL_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o
+VL_OBJS+=block-vhd.o
 ifdef CONFIG_WIN32
 VL_OBJS+=tap-win32.o
 endif

diff -r 005dd6b1cf8e tools/ioemu/block.c
@@ -1246,6 +1246,7 @@ void bdrv_init(void)
     bdrv_register(&bdrv_vpc);
     bdrv_register(&bdrv_vvfat);
     bdrv_register(&bdrv_qcow2);
+    bdrv_register(&bdrv_vhd);
 }
 
 void *qemu_aio_get(BlockDriverState *bs, BlockDriverCompletionFunc *cb,

diff -r 005dd6b1cf8e tools/ioemu/vl.c
@@ -7223,14 +7223,23 @@ int main(int argc, char **argv)
             case QEMU_OPTION_hdb:
             case QEMU_OPTION_hdc:
             case QEMU_OPTION_hdd:
-                {
-                    int hd_index;
-                    hd_index = popt->index - QEMU_OPTION_hda;
-                    hd_filename[hd_index] = optarg;
-                    if (hd_index == cdrom_index)
-                        cdrom_index = -1;
-                }
-                break;
+	    {
+		int hd_index;
+		char *fname;
+		
+		fname = strchr(optarg, ':');
+		if (fname == NULL)
+		    fname = optarg;
+		else
+		    fname++;
+		
+		hd_index = popt->index - QEMU_OPTION_hda;
+		hd_filename[hd_index] = fname;
+		if (hd_index == cdrom_index)
+		    cdrom_index = -1;
+	    }
+	    
+	    break;
 #endif /* !CONFIG_DM */
             case QEMU_OPTION_snapshot:
                 snapshot = 1;

diff -r 005dd6b1cf8e tools/ioemu/vl.h
@@ -589,6 +589,7 @@ extern BlockDriver bdrv_vpc;
 extern BlockDriver bdrv_vpc;
 extern BlockDriver bdrv_vvfat;
 extern BlockDriver bdrv_qcow2;
+extern BlockDriver bdrv_vhd;
 
 typedef struct BlockDriverInfo {
     /* in bytes, 0 if irrelevant */

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Hi Ben,

Thanks very much for these patches -- it would be great to see VHD
support added to blktap. I've taken a high-level pass over your patches and have a few comments/suggestions:

1. Your patches add a vdisk abstraction. It's not clear that adding
another virtual disk interface (in addition to what is already presented with tapdisk and used by the existing drivers) is a big win -- especially since VHD is the only consumer of the new abstraction. If the tapdisk interface falls short, can we evolve it to address deficiencies rather than add another parallel interface?

2. Having both qemu and tapdisk instances go directly at the disk
isn't ideal. It would be much better to plumb qemu through tapdisk, say through a dom0 block-attach, so that we implement drivers in a single place, cache image metadata in a single entity at runtime, etc.

3. It doesn't look like your VHD implementation does chained disks.
Am I missing something, or is this future work?

a.

The vdisk abstraction was mainly designed to allow qemu & tapdisk to share the same format translation code. Existing formats seemed to duplicate code between the two consumers.

I'm confused here, are you saying that the current disk format decoders are not duplicated in both qemu and tapdisk? I didn't think upstream qemu even knew about tapdisk.

In any case, I would think Qemu performance overhead is significant enough without adding another hop through tapdisk.

Disk chaining (parent/child relationships) is currently handled by the vdisk layer, not the VHD format translation directly.

Steve

Steve Ofsthun - Virtual Iron Software, Inc.