I have a logical volume what's used for a xen disk:

Disk /dev/d0_vg/backup: 10.7 GB, 10737418240 bytes
1 heads, 1 sectors/track, 20971520 cylinders, total 20971520 sectors
Units = cylinders of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00001b22

                    Device Boot      Start         End      Blocks   Id  System
/dev/d0_vg/backup1   *          64      208839      104388   83  Linux
/dev/d0_vg/backup2          208846    19406517     9598836   83  Linux
/dev/d0_vg/backup3        19406521    20964808      779144   82  Linux swap / Solaris

How can I specify the right offset to mount backup2, the root filesystem somewhere?

I tried to follow this article and calculate the starting position:



mount -o loop,offset=106929152 /dev/d0_vg/backup2 /mnt/

I always get "mount: you must specify the filesystem type" error, so it's not trying to read it from where it should. Anyone knows what's the problem here?


If I read your question correctly you have a Linux hypervisor (a Xen dom0) with Linux LVM volumes which are used as virtual disks for your Xen guests (domU). And you want to access the data in that LVM directly from the hypervisor, bypassing the Xen guest.

I don't use Xen anymore but I imagine the process is similar to what I do with KVM guests:

Shut the guest domU down. (accessing a filesystem from two different locations is asking for data corruption)

On the hypervisor run kpartx which will scan the LVM for a partition table and create device entries for each partition found (where I assume have a Volume Group Guests and a LVM guestname-diskname which is the virtual hard disk for your domU)

[root@dom0 ]# kpartx -a /dev/Guests/guestname-diskname

If you had three partitions in your Xen guest this should result in 3 new device entries: /dev/Guests/guestname-diskname[1-3]

Then you should be able to mount a partition with a file-system simply with:

[root@dom0 ]# mount -t ext3 /dev/Guests/guestname-diskname2 /mnt

It becomes a little bit more complex if you used LVM inside the domU as well; then the partitions are of the type 8e Linux LVM and formatted as physical volumes which you can't simply mount yet and LVM trickery is needed. Instead of the mount command the steps become:

Hopefully you can detect the volume group that existed within the domU:

[root@dom0 ]# vgscan
    Found volume group "Guests" using metadata type lvm2
    Found volume group "VG-guestname" using metadata type lvm2     <== NEW!

Next you need to enable the volume group "VG-guestname" :

[root@dom0 ]# vgchange -a y guestname 

And a lvscan should show the logical volumes that were created in your domU and the device mapper entries are typically created now as well, allowing you to do something like:

[root@dom0 ]# mount -t ext3 /dev/VG-guestname/guest-lvname /mnt

IIRC it wasn't possible in Xen but can happen with KVM, the inconvenient case where the name of a volume group used in the hypervisor is the same as one assigned in the guest.


No way, probably your mount doesn't have the needed capability to use this tricky loopback mount.

If you are mounting something so, the mount command first calls a losetup, and finally mounts this losetup device. It is normally /dev/loop0 (or bigger).

With the losetup command you can mount a file, or a part of a file as if it were a normal partition. It is practically the same as daemon tool for the windowsers' tribe. This time we use this losetup to map a part of /dev/d0_vg to a new block device, to /dev/loop0.

You can do this in two steps:

losetup /dev/loop0 /dev/d0_vg --offset=$[208846*512]
mount /dev/loop0 /mnt

After the losetup command, you can check if you found a real filesystem with the command file -szL /dev/loop0.

After the unmount, you had to remove the loop0 device with the command losetup -d.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.