qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [kvm-devel] [RFC][PATCH] Modify loop device to be a


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Re: [kvm-devel] [RFC][PATCH] Modify loop device to be able to manage partitions of the image disk
Date: Tue, 15 Jan 2008 23:54:38 +0000
User-agent: Mutt/1.4.1i

On Wed, Jan 16, 2008 at 12:40:06AM +0100, Laurent Vivier wrote:
> Le mardi 15 janvier 2008 à 18:27 +0000, Daniel P. Berrange a écrit :
> > On Tue, Jan 15, 2008 at 07:22:53PM +0100, Laurent Vivier wrote:
> > > As it should be useful to be able to mount partition from a 
> > > disk image, (and as I need a break in my bug hunting) I've 
> > > modified the loop driver to mount raw disk image.
> > > 
> > > To not break original loop device, as we have to change minor 
> > > numbers to manage partitions, a new parameter is added to the module:
> > 
> > I don't see the point in modifying the loop device driver when you
> > can already access the partitions with existing device mapper
> > functionality & tools.
> 
> There are two reasons:
> 
> 1- I didn't know kpartx (thank you for the tip)
> 
> but using loop device, you will be able to use all partition tables
> known by the kernel (acorn,  atari,  efi,  karma,  mac, osf, sun,
> ultrix, amiga, ibm, ldm, msdos, sgi, sysv68), whereas kpartx can use
> only partition tables it knows (bsd, dasd, dos, mac, sun, efi, sun,
> unixware).

This is an argument for extending kpartx to cope with the other
partition tables :-)  I have 50/50 split between VMs using files
vs VMs using LVM volumes - the loop driver patches only help you
access partitions within a file based image, whereas kpartx can
access the partitions within any block device, so can support 
files (via existing loop device) & LVM vols & nested partitions.

> 2- I'd like to mount qcow2 or others disk image formats, so perhaps it's
> easier to modify loop device driver (but perhaps you know another magic
> tool ?)

There has been some work in this area wrt to Xen - the DM-Userspace project
had some working code providing a device mapper target calling out to a 
userspace daemon to handle non-raw file formats like qcow. I don't
know what the state of it is now wrt to upstream kernel / device-mapper,
or even whether it is more than just 'proof of concept', but the project
page is here with some info:

  http://wiki.xensource.com/xenwiki/DmUserspace

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]