[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk fo
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system |
Date: |
Fri, 18 Jan 2013 12:54:59 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Jan 17, 2013 at 08:22:40PM +0000, Blue Swirl wrote:
> On Mon, Jan 14, 2013 at 9:13 AM, Stefan Hajnoczi <address@hidden> wrote:
> > On Sat, Jan 12, 2013 at 12:00:45PM +0000, Blue Swirl wrote:
> >> On Fri, Jan 11, 2013 at 7:27 AM, 马磊 <address@hidden> wrote:
> >> >
> >> >
> >> > On Fri, Jan 11, 2013 at 2:28 PM, Wanlong Gao <address@hidden>
> >> > wrote:
> >> >>
> >> >> On 01/11/2013 11:39 AM, 马磊 wrote:
> >> >> >
> >> >> >
> >> >> > On Thu, Jan 10, 2013 at 8:20 PM, Daniel P. Berrange <address@hidden
> >> >> > <mailto:address@hidden>> wrote:
> >> >> >
> >> >> > On Wed, Jan 09, 2013 at 09:37:54PM +0000, Blue Swirl wrote:
> >> >> > > On Wed, Jan 9, 2013 at 7:31 AM, 马磊 <address@hidden
> >> >> > <mailto:address@hidden>> wrote:
> >> >> > > >
> >> >> > > >
> >> >> > > >>> Hi,
> >> >> > > >>> The final effect is as follows:
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >>> address@hidden Fri Dec 28 ~/honeypot/xen/xen-4.1.2]$
> >> >> > qemu-img-xen cat
> >> >> > > >>> -f /1/boot.ini ~/vm-check.img
> >> >> > > >>> [boot loader]
> >> >> > > >>> timeout=30
> >> >> > > >>> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
> >> >> > > >>> [operating systems]
> >> >> > > >>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft
> >> >> > Windows
> >> >> > XP
> >> >> > > >>> Professional" /noexecute=optin /fastdetect
> >> >> > > >>>
> >> >> > > >>> address@hidden Fri Dec 28 ~/honeypot/xen/xen-4.1.2]$
> >> >> > qemu-img-xen ls
> >> >> > > >>> -l -d /1/ ~/vm-check.img
> >> >> > > >>> 【name size(bytes) dir? date
> >> >> > > >>> create-time】
> >> >> > > >>> AUTOEXEC.BAT 0 file 2010-12-22
> >> >> > 17:30:37
> >> >> > > >>> boot.ini 211 file 2010-12-23
> >> >> > 01:24:41
> >> >> > > >>> bootfont.bin 322730 file 2004-11-23
> >> >> > 20:00:00
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >>> As you see above, the patch add two sub-commands for
> >> >> > qemu-img-xen:cat and
> >> >> > > >>> ls.
> >> >> > > >>>
> >> >> > > >>> For details in the patch, please check the attachment.
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >
> >> >> > > > Does anyone prefer this feature?!
> >> >> > >
> >> >> > > Nice feature, but this approach would just clutter QEMU and give
> >> >> > only
> >> >> > > readonly FAT or NTFS support. I think a more generally useful
> >> >> > approach
> >> >> > > would be to use NBD or iSCSI to export the block device data
> >> >> > from
> >> >> > the
> >> >> > > image file (qemu-nbd already exists) and then make a tool that
> >> >> > uses
> >> >> > > some combination of NBD/iSCSI client, all GRUB file systems and
> >> >> > FUSE
> >> >> > > or other user space methods to access the contents of the
> >> >> > filesystem.
> >> >> > > Probably also UML with a simple guest agent could provide
> >> >> > read/write
> >> >> > > access to any file system that Linux supports.
> >> >> >
> >> >> > The latter is what libguestfs already provides. It boots a Linux
> >> >> > kernel
> >> >> > and mini initrd containing a guest agent, to provide APIs to do
> >> >> > arbitrary
> >> >> > manipulation of guest OS images.
> >> >> >
> >> >> > The reason libguestfs used a linux guest was precisely to avoid
> >> >> > having
> >> >> > to re-implement drivers for every filesystem in existance like
> >> >> > this
> >> >> > patch is trying todo.
> >> >> >
> >> >> > I don't think QEMU wants to be in the business of maintaining
> >> >> > filesystem
> >> >> > drivers, so I'd reject this proposed patch.
> >> >> >
> >> >> > Regards,
> >> >> > Daniel
> >> >> > --
> >> >> > |: http://berrange.com -o-
> >> >> > http://www.flickr.com/photos/dberrange/ :|
> >> >> > |: http://libvirt.org -o-
> >> >> > http://virt-manager.org :|
> >> >> > |: http://autobuild.org -o-
> >> >> > http://search.cpan.org/~danberr/ :|
> >> >> > |: http://entangle-photo.org -o-
> >> >> > http://live.gnome.org/gtk-vnc :|
> >> >> >
> >> >> >
> >> >> >
> >> >> > This feature could be configured to be optional in make file
> >> >> > configuration according to individual preference.
> >> >> > _In addition, the fat32 and ntfs filesystem driver will not change
> >> >> > for a
> >> >> > long time so it needs no much maintainence once implemented._
> >> >>
> >> >> As Daniel and Stefan said, you can try to use libguestfs
> >> >> [libguestfs.org]
> >> >> and qemu-nbd.
> >> >> In libguestfs, we provide virt-cat, virt-ls, etc. And support all the
> >> >> disk
> >> >> type which QEMU supported.
> >> >>
> >> >> Thanks,
> >> >> Wanlong Gao
> >> >>
> >> >
> >> > I used libguest, it's startup takes too long to meet specific
> >> > requirements
> >> > under some time-sensitive circumstance.
> >>
> >> For maximum speed, the backing formats (QCOW etc) should be
> >> implemented in the kernel directly, somewhat like device mapper or
> >> /dev/loop device.
> >>
> >> A very simple and fast approach without any changes would be to
> >> convince the guest to not to use partitions and instead use one file
> >> system for an entire block device, then the backing file (in raw
> >> format, no QCOW etc) could be manipulated by mounting it with the
> >> loopback device.
> >>
> >> Alternatively, we could implement in QEMU a way to concatenate several
> >> separate files into one, each of the files containing a partition or
> >> some space for partition table. Then the files could be again accessed
> >> with loopback mount. The partition table could be also synthesized.
> >>
> >> I don't know why the loopback mount in the kernel does not support
> >> partitions, that would also solve the problem when using raw files.
> >
> > The loop module supports partitions through the offset= parameter.
> >
> > For example:
> >
> > # fdisk -lu /dev/sda
> > [...]
> > Device Boot Start End Blocks Id System
> > /dev/sda1 * 2048 1026047 512000 83 Linux
> > /dev/sda2 1026048 500117503 249545728 83 Linux
> > # mount -o loop,offset=$((2048 * 512)) /dev/sda /mnt/boot # mount sda1
>
> Doesn't this make also the space after sda1, up to end of the device
> accessible via the partition? It could be a problem if the file system
> in sda1 (due to a bug) referenced blocks in sda2, or someone did dd
> if=/dev/zero of=/dev/loop0 to clear the partition.
Yes.
The "sizelimit" option can be used together with "offset" to prevent
this. It's documented on the mount(8) and losetup(8) man pages.
Stefan
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, (continued)
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Daniel P. Berrange, 2013/01/10
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, 马磊, 2013/01/10
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Wanlong Gao, 2013/01/11
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, 马磊, 2013/01/11
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Stefan Hajnoczi, 2013/01/11
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Blue Swirl, 2013/01/12
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Wanlong Gao, 2013/01/13
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Stefan Hajnoczi, 2013/01/14
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Blue Swirl, 2013/01/17
- Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system,
Stefan Hajnoczi <=
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system, Stefan Hajnoczi, 2013/01/10