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

[Wanlong Gao]

On 01/12/2013 08:00 PM, 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.

AFAIK, the loopback mount can recognize partitions like this:
# dd if=/dev/zero of=test_part.img bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0593102 s, 1.8 GB/s
# losetup /dev/loop0 test_part.img 
# parted -s /dev/loop0 mklabel "msdos"
# parted -s /dev/loop0 mkpart "primary" 1 16
# parted -s /dev/loop0 mkpart extended 17 64
# parted -s /dev/loop0 mkpart logical 18 32
Warning: The resulting partition is not properly aligned for best performance.
# kpartx  /dev/loop0
loop0p1 : 0 28672 /dev/loop0 2048
loop0p2 : 0 2 /dev/loop0 32768
loop0p5 : 0 27345 /dev/loop0 35156
# ls /dev/mapper/
control
# kpartx -a /dev/loop0
# ls /dev/mapper/
control  loop0p1  loop0p2  loop0p5


Thanks,
Wanlong Gao

>