dm-userspace xen integration patches
PATCH 1/1 dm-userspace xen integration patches
Here are our latest dm-userspace-xen integration patches. A few things have changed since our last patch: synchronous metadata flushing and block-dmu script updates to avoid xend races, a makefile change to ensure we check for autotools, and a change to the dscow creation tool to allow for large dscow files.
I'd like to point out that having dm-userspace integrated into xen allows a user to quickly and easily specify a base device and where they'd like to store the changes. All they have to do is change one line in their xm config file, and they're good to go.
Our main focus here is really block devices, such as LVMS, nbd, iSCSI. We do support file-backed images as an experimental feature and encourage using it with care since there are some potential issues with the current loop driver.
Comments are much appreciated.
--
Thanks,
Ryan Grimm
IBM Linux Technology Center
RG> Our main focus here is really block devices, such as LVMS, nbd, RG> iSCSI. We do support file-backed images as an experimental RG> feature and encourage using it with care since there are some RG> potential issues with the current loop driver.
I think that in the past dm-userspace has been compared to blktap as a competing method for providing cow support for image files. While we do support files with the existing loop driver, we are currently most concerned with providing cow support against native block devices.
Signature · 4 lines
Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [email protected]
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Dan,
Quoted 10 lines · Dan Smith
RG> Our main focus here is really block devices, such as LVMS, nbd, RG> iSCSI. We do support file-backed images as an experimental RG> feature and encourage using it with care since there are some RG> potential issues with the current loop driver.
I think that in the past dm-userspace has been compared to blktap as a competing method for providing cow support for image files. While we do support files with the existing loop driver, we are currently most concerned with providing cow support against native block devices.
Just to clarify, the Blktap device driver supports both block devices and image files. In order to create a block device backed CoW image use the qcow-create command:
qcow-create 0 <qcow filename> <block device>
when you insert the qcow filename into the config file:
disk = [ 'tap:qcow:<qcow filename>, sda1, w' ]
it will open both the backing device handle and the qcow image. Similarly you can open a raw block device without CoW support by setting the disk parameter field to 'tap:aio:<block device> etc...'
We've been working on some improvements to the CoW architecture within the userspace blktap tools that we will push out to -unstable soon.
- Julian
JC> Just to clarify, the Blktap device driver supports both block JC> devices and image files.
Sorry, I didn't mean to imply that it only supported files.
JC> In order to create a block device backed CoW image use the JC> qcow-create command:
JC> qcow-create 0 <qcow filename> <block device>
So, this is still putting the CoW data in a file, but with the base image data in a block device, right?
JC> Similarly you can open a raw block device without CoW support
Right, but we are interested in CoW between two block devices. That's why we have created a special CoW format (qcow wastes a lot of space to do sparse allocation, which is pointless and slow on a block device). We looking to support things like using two iSCSI block devices to do CoW (i.e. with no files involved). We are also interested in doing things that have nothing to do with cow, using dm-userspace as an enabling component.
Signature · 4 lines
Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [email protected]
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel