Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Thu, Jan 17, 2013 at 08:22:40PM +, 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 +, 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 +, 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 0file 2010-12-22 17:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Mon, Jan 14, 2013 at 9:13 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Jan 12, 2013 at 12:00:45PM +, 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 +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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 *
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Sat, Jan 12, 2013 at 12:00:45PM +, 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 +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
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 +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
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 +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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.
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Fri, Jan 11, 2013 at 03:27:52PM +0800, 马磊 wrote: On Fri, Jan 11, 2013 at 2:28 PM, Wanlong Gao gaowanl...@cn.fujitsu.comwrote: On 01/11/2013 11:39 AM, 马磊 wrote: On Thu, Jan 10, 2013 at 8:20 PM, Daniel P. Berrange berra...@redhat.commailto: berra...@redhat.com wrote: On Wed, Jan 09, 2013 at 09:37:54PM +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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. * Then use qemu-nbd instead. It's fast and you can use all the file systems supported by your host (ext4, xfs, fat, ntfs, etc), as well as LVM or encrypted volumes. Stefan
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Thu, Jan 10, 2013 at 4:03 PM, 马磊 aware@gmail.com wrote: On Thu, Jan 10, 2013 at 5:37 AM, Blue Swirl blauwir...@gmail.com wrote: On Wed, Jan 9, 2013 at 7:31 AM, 马磊 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 2004-11-2320: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. Signed-off-by: Lei Ma (ma...@360.cn) diff --exclude=.svn -rpN -U8 xen-4.1.2-a/tools/ioemu-qemu-xen/debug.c Patches sent to qemu-devel should be based on qemu.git. Please also read CODING_STYLE and HACKING files. Do you mean the git of *git:// xenbits.xen.org/staging/qemu-upstream-unstable.git?* ./configure reports: glib-2.12 required to compile QEMU; but the latest version is glib-1.2.10-20.el5.x86_64 for kernel 2.6.18-274.3.1.el5xen. How to make and use the latest qemu from qemu.git? Besides, the patch is a little big and the patch now can't be completely inserted into the latest qemu-upstream so that fully conforming to the CODING_STYLE is not a little work, if anyone is interested in the feature, welcome to join in the work.
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
Do you mean the git of git://xenbits.xen.org/staging/qemu-upstream-unstable.git ? ./configure reports: glib-2.12 required to compile QEMU; but the latest version is glib-1.2.10-20.el5.x86_64 for kernel 2.6.18-274.3.1.el5xen. How to make and use the latest qemu from qemu.git? Please against git://git.qemu-project.org/qemu.git , you can see the link from [1]. You will need to install packages required by QEMU before you building it. Besides, the patch is a little big and the patch now can't be completely inserted into the latest qemu-upstream so that fully conforming to the CODING_STYLE is not a little work, if anyone is interested in the feature, welcome to join in the work. That might be a hint that you need to split your patch into smaller pieces. :) Regards, chenwj [1] http://wiki.qemu.org/Download -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
Il 10/01/2013 09:04, 马磊 ha scritto: Do you mean the git of _git://xenbits.xen.org/staging/qemu-upstream-unstable.git http://xenbits.xen.org/staging/qemu-upstream-unstable.git?_ No, git://git.qemu-project.org/qemu.git ./configure reports: glib-2.12 required to compile QEMU; but the latest version is glib-1.2.10-20.el5.x86_64 for kernel 2.6.18-274.3.1.el5xen. How to make and use the latest qemu from qemu.git? The package is probably called glib2 in your distribution. Besides, the patch is a little big and the patch now can't be completely inserted into the latest qemu-upstream so that fully conforming to the CODING_STYLE is not a little work, if anyone is interested in the feature, welcome to join in the work. Unfortunately, that's not how things work. If you do not do this, the patch will likely be ignored. Paolo
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Thu, Jan 10, 2013 at 4:33 PM, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: Do you mean the git of git:// xenbits.xen.org/staging/qemu-upstream-unstable.git ? ./configure reports: glib-2.12 required to compile QEMU; but the latest version is glib-1.2.10-20.el5.x86_64 for kernel 2.6.18-274.3.1.el5xen. How to make and use the latest qemu from qemu.git? Please against git://git.qemu-project.org/qemu.git , you can see the link from [1]. You will need to install packages required by QEMU before you building it. I need to be against qemu-xen source tree who will exist in xen source tree as ioemu-qemu-xen. Some packages can't be found by yum at cenos5. Besides, the patch is a little big and the patch now can't be completely inserted into the latest qemu-upstream so that fully conforming to the CODING_STYLE is not a little work, if anyone is interested in the feature, welcome to join in the work. That might be a hint that you need to split your patch into smaller pieces. :) Regards, chenwj [1] http://wiki.qemu.org/Download The entire patch is for only a feature and has no need to be splitted.
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
I need to be against qemu-xen source tree who will exist in xen source tree as ioemu-qemu-xen. Some packages can't be found by yum at cenos5. Not familiar with qemu-xen, but from this link [1] I think qemu-xen also use the same upstream I mentioned before? If you can install that packages with yum, then download and build it yourself. You can download glib from here [2]. Regards, chenwj [1] http://wiki.xen.org/wiki/QEMU_Upstream [2] http://ftp.gnome.org/pub/gnome/sources/glib/2.34/ -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Thu, Jan 10, 2013 at 4:49 PM, 马磊 aware@gmail.com wrote: On Thu, Jan 10, 2013 at 4:37 PM, Paolo Bonzini pbonz...@redhat.comwrote: Il 10/01/2013 09:04, 马磊 ha scritto: Do you mean the git of _git://xenbits.xen.org/staging/qemu-upstream-unstable.git http://xenbits.xen.org/staging/qemu-upstream-unstable.git?_ No, git://git.qemu-project.org/qemu.git ./configure reports: glib-2.12 required to compile QEMU; but the latest version is glib-1.2.10-20.el5.x86_64 for kernel 2.6.18-274.3.1.el5xen. How to make and use the latest qemu from qemu.git? The package is probably called glib2 in your distribution. I have glib2-2.12.3-4.el5_3.1 instlled, but the the error was still reported. Some packages can't be found by yum at cenos5. I need to be against qemu-xen source tree who will exist in xen source tree as ioemu-qemu-xen. Besides, the patch is a little big and the patch now can't be completely inserted into the latest qemu-upstream so that fully conforming to the CODING_STYLE is not a little work, if anyone is interested in the feature, welcome to join in the work. Unfortunately, that's not how things work. If you do not do this, the patch will likely be ignored. Paolo I will have a try after successfully making and installing qemu from qemu-git. After all installing is for debugging.
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Thu, Jan 10, 2013 at 4:50 PM, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: I need to be against qemu-xen source tree who will exist in xen source tree as ioemu-qemu-xen. Some packages can't be found by yum at cenos5. Not familiar with qemu-xen, but from this link [1] I think qemu-xen also use the same upstream I mentioned before? If you can install that packages with yum, then download and build it yourself. You can download glib from here [2]. Regards, chenwj [1] http://wiki.xen.org/wiki/QEMU_Upstream [2] http://ftp.gnome.org/pub/gnome/sources/glib/2.34/ -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj I got the glib from http://ftp.gnome.org/pub/gnome/sources/glib/2.12/glib-2.12.12.tar.bz2 . After installing, it appears as glib2-2.12.3-4.el5_3.1 in rpm query info and it didn't work for making qemu when run configure.
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Wed, Jan 09, 2013 at 03:31:50PM +0800, 马磊 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 0file 2010-12-2217:30:37* *boot.ini 211file 2010-12-23 01:24:41* *bootfont.bin 322730file 2004-11-2320: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?!* This is already possible with http://libguestfs.org/. Or you can use qemu-nbd to mount the image on the host as explained here: http://blog.vmsplice.net/2011/02/how-to-access-virtual-machine-image.html Although adding file system code to qemu-img integrates this feature more closely, I think the maintenance overhead and duplication of having read-only file system implementations is too much. Therefore, I'm against merge a patch like this. Stefan
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Wed, Jan 09, 2013 at 09:37:54PM +, Blue Swirl wrote: On Wed, Jan 9, 2013 at 7:31 AM, 马磊 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-2301:24:41 bootfont.bin 322730file 2004-11-2320: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 :|
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Thu, Jan 10, 2013 at 8:20 PM, Daniel P. Berrange berra...@redhat.comwrote: On Wed, Jan 09, 2013 at 09:37:54PM +, Blue Swirl wrote: On Wed, Jan 9, 2013 at 7:31 AM, 马磊 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 2004-11-2320: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.*
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
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 +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 2004-11-2320: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
Re: [Qemu-devel] [PATCH] reading files from qcow2-formated image disk for windows system
On Fri, Jan 11, 2013 at 2:28 PM, Wanlong Gao gaowanl...@cn.fujitsu.comwrote: On 01/11/2013 11:39 AM, 马磊 wrote: On Thu, Jan 10, 2013 at 8:20 PM, Daniel P. Berrange berra...@redhat.commailto: berra...@redhat.com wrote: On Wed, Jan 09, 2013 at 09:37:54PM +, 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 0file 2010-12-2217:30:37 boot.ini 211file 2010-12-23 01:24:41 bootfont.bin 322730file 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. *
