On 01/12/2013 08:00 PM, Blue Swirl wrote: > On Fri, Jan 11, 2013 at 7:27 AM, 马磊 <aware....@gmail.com> wrote: >> >> >> On Fri, Jan 11, 2013 at 2:28 PM, Wanlong Gao <gaowanl...@cn.fujitsu.com> >> wrote: >>> >>> On 01/11/2013 11:39 AM, 马磊 wrote: >>>> >>>> >>>> On Thu, Jan 10, 2013 at 8:20 PM, Daniel P. Berrange <berra...@redhat.com >>>> <mailto:berra...@redhat.com>> wrote: >>>> >>>> On Wed, Jan 09, 2013 at 09:37:54PM +0000, Blue Swirl wrote: >>>> > On Wed, Jan 9, 2013 at 7:31 AM, 马磊 <aware....@gmail.com >>>> <mailto:aware....@gmail.com>> wrote: >>>> > > >>>> > > >>>> > >>> Hi, >>>> > >>> The final effect is as follows: >>>> > >>> >>>> > >>> >>>> > >>> [malei@xentest-4-1 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 >>>> > >>> >>>> > >>> [malei@xentest-4-1 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 >
