I have a logical volume which serves as the filesystem for a virtual guest OS. I'm happy with the state of my guest OS and would like to make a backup of it. I created a snapshot using lvcreate and I'm attempting to mount the snapshot so I can tar up the data for backup.

What's really weird is that I absolutely cannot get the LVM snapshot mounted.

$> mount /dev/guest_images_lvm/cvfunc_vol1_ss /mnt/ops/backup/
mount: you must specify the filesystem type

Using the -t parameter of mount I've tried ext3 and ext4 for the file system type, but in each case I get the following error:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/guest_images_lvm-cvfunc_vol1

Here's the output from lvs for the snapshot volume:

LV             VG                  Attr   LSize  Origin      Snap%  Move Log Copy%  Convert
cvfunc_vol1_ss guest_images_lvm    swi-a-  1.00g cvfunc_vol1   0.00

What is the right parameters I need to give to mount to get the LVM snapshot mounted? Is there another way I can determine the filesystem type of the snapshot? For what it's worth, I let the RedHat KVM virt-manager GUI tool create the volume.

EDIT More info as requested.

Output of lvs

LV             VG                  Attr   LSize  Origin      Snap%  Move Log Copy%       Convert
cvfunc_vol1    guest_images_lvm    owi-a- 20.00g                                           
cvfunc_vol1_ss guest_images_lvm    swi-a-  1.00g cvfunc_vol1   0.00                        
cvfunc_vol2    guest_images_lvm    -wi-ao 20.00g                                           
lv_home        vg_softrekcvdev0100 -wi-ao 25.68g                                           
lv_root        vg_softrekcvdev0100 -wi-ao 32.34g                                           
lv_swap        vg_softrekcvdev0100 -wi-ao  9.81g

Output of lvdisplay for the volume in question

--- Logical volume ---
LV Name                /dev/guest_images_lvm/cvfunc_vol1_ss
VG Name                guest_images_lvm
LV UUID                YA4m5i-yf7R-hO95-gb0F-iXqQ-PQjU-tXhAp0
LV Write Access        read/write
LV snapshot status     active destination for /dev/guest_images_lvm/cvfunc_vol1
LV Status              available
# open                 0
LV Size                20.00 GiB
Current LE             5120
COW-table size         1.00 GiB
COW-table LE           256
Allocated to snapshot  0.00% 
Snapshot chunk size    4.00 KiB
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:5

Output of dd command suggested by comment below:

# dd if=/dev/guest_images_lvm/cvfunc_vol1_ss bs=1024 count=1 | file -
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 1.6909e-05 s, 60.6 MB/s
/dev/stdin: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x19041; partition 1: ID=0x83, active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 208845, 41720805 sectors, code offset 0x48
  • Try running blkid /dev/guest_images_lvm/cvfunc_vol1. – Zoredache Apr 19 '12 at 21:16
  • 1
    At a guess, cvfunc_vol1 is a disk image, not a partition. See e.g. andremiller.net/content/… – Bittrance Apr 19 '12 at 21:17
  • @Zoredache I ran that command and it just returned to the prompt with no output. I also ran it w/ the -c /dev/null and got the same (empty) result. – Andre Apr 19 '12 at 21:20
  • Hrm, I am tempted to believe that you created your snapshot wrong or something. What command did you run? Maybe provide the full output of lvs/vgdisplay? – Zoredache Apr 19 '12 at 21:21
  • @Zoredache lvcreate -L1G -s -n cvfunc_vol1_ss /dev/guest_images_lvm/cvfunc_vol1 – Andre Apr 19 '12 at 21:23

With the caveat that I don't know much about kvm, I would guess that the partition is a full disk image. If that is the case, you should get a meaningful partition table if you do:

fdisk -l /dev/guest_images_lvm/cvfunc_vol1

If this is the case, you need to do something like this article suggests: http://www.andremiller.net/content/mounting-hard-disk-image-including-partitions-using-linux

If it is indeed just a partition, fdisk complains like so:

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xe3a5124c.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

EDIT: Using -l options as per Andre's suggestion, to reduce grief for future readers.

  • You may be onto something, in so much that according to fdisk my snapshot appears to have two partitions within it . Not sure if that's normal or not though.... – Andre Apr 19 '12 at 21:49

What filesystem is contained in the logical volume? Find out using dd if=/dev/SOMETHING bs=1024 count=1 | file -.

Does the logical volume contain an XFS filesystem? XFS filesystems have unique identifiers, and Linux will balk at mounting the "same" filesystem twice, unless you use mount -o nouuid on the snapshot.

  • I edited my original posting with the output of the dd command as you suggested. I don't know if it's XFS, sadly I made the mistake of letting a RHEL tool create the volume and format it. – Andre Apr 19 '12 at 21:53
  • I think @Bittrance has the right answer then. – 200_success Apr 19 '12 at 21:57
  • dmesg isn't complaining about XFS duplicate UUIDs, for what it's worth. – Andre Apr 19 '12 at 21:58

That LVM partition has been used by the guest as disk. On that disk it created one or more partitions. What you want to do is extract these partition information and make it available to your host system.

The easiest way to do this is to losetup the LVM:

losetup /dev/loop0 /dev/guest_images_lvm/cvfunc_vol1_ss

And tell your Linux kernel about these partitons:

partx -a /dev/loop0

To mount:

mount  /dev/loop0 /mnt/vm

To cleanup again:

umount /mnt/vm
partx -d /dev/loop0p*
losetup -d /dev/loop0

Why is it that you cannot just add the partitions from the LVM and need to take the extra step via losetup? Since you certainly can list the partitions on the LVM, and it will be the same:

% sudo losetup -a
/dev/loop0: [0005]:19633989 (/dev/mapper/vg0-mail01--root)
 % sudo partx -s /dev/loop0 ; sudo partx -s /dev/vg0/mail01-root
 1  2048 20969471 20967424  10G      
 1  2048 20969471 20967424  10G      

The reason is that LVM is managed by the dm, the device manager, and it sure won't have anyone tell it that it's wrong about the partition setup.

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.