Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system

[Blue Swirl]

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.

>
> Stefan