For the last couple of years, I've used a rather manual process, involving losetup, fdisk, calculating the byte offset into the image of each partition, losetup again, and then mount.
Many times, it crossed my mind that there must be an easier way. But, meh, it worked ;-)
In the process of answering pitti's question, I stumbled across:
http://equivocation.org/node/107Much cleaner! It amounts to:
# losetup /dev/loop0 foo.img:-Dustin
# kpartx -av /dev/loop0
# mount /dev/mapper/loop0p1 /mnt
...
# unmount /mnt
# kpartx -dv /dev/loop0
# losetup -d /dev/loop0
Hey Dustin,
ReplyDeleteWould it be possible to set up a handler for that so that people could just double click on .img files and have them mounted on their desktop? That would be very cool.
Ted
Hi Ted-
ReplyDeletePersonally, I'm not too keen on that. Editing .img files is dangerous, and not for the faint of heart. Just my two cents...
:-Dustin
I don't really get the file-image-fuzz - why not just use 'storage' for the guests? LVM Volumes, iSCSI targets, whatever. IO performace with that (plus virtio) is so much higher ...
ReplyDeleteLukas-
ReplyDeleteI like disk image files because they're easier to move around, from one system to another. You can use virtio with image files, but you're right, you will get better performance out of 'storage'.
:-Dustin
Note: The 'losetup' cycle can be ommitted. kpartx will be happy to add and remove loopback devices for you:
ReplyDelete# kpartx -av foo.img
# kpartx -dv foo.img
Note: The 'losetup' cycle can be ommitted. kpartx will be happy to add and remove loopback devices for you:
ReplyDelete# kpartx -av foo.img
# kpartx -dv foo.img
Thanks for posting! Very helpful. My VM would not boot, but this allowed me to pull my files out of the image.
ReplyDeletewonderful post. This helps me a lot to work with LTSP clusters
ReplyDeleteI ran into something nasty with kpartx (version 0.4.8). I had LVM based images named the following:
ReplyDelete/dev/main/guest (containing 3 partitions)
/dev/main/guest2 (containing 3 partitions)
guest2 was running when I wanted to mount guest's partitions. I did:
#kpartx -a /dev/main/guest
Lo and behold, I had mappings for
/dev/main/guest1
/dev/main/guest2
/dev/main/guest5
The original guest2 mapping was replaced with /dev/main/guest's second partition. Worse yet, the running guest was writing on that partition, corrupting "guest". Admittedly, my naming convention caused this corruption, but it also appears that kpartx doesn't check for naming collisions.
Is it working with qcow v1&2 ?
ReplyDeleteThis was awesome - thanx !
ReplyDeleteNow, I won't have to power-up a VM to get/set/edit/put/../../ something :)
Thanks again.
All best,
Stoyan