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


Reply via email to