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.
