On Thu, Jan 17, 2013 at 08:22:40PM +0000, Blue Swirl wrote: > On Mon, Jan 14, 2013 at 9:13 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Sat, Jan 12, 2013 at 12:00:45PM +0000, 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. > > > > 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.
Yes. The "sizelimit" option can be used together with "offset" to prevent this. It's documented on the mount(8) and losetup(8) man pages. Stefan