trying 'suspend' mode instead - unable to detect lvm volume group

JustaGuy

Renowned Member
Jan 1, 2010
324
2
83
In the process of looking for why my backup jobs stopped happening, I've run some manually and found this problem with snapshot mode.

Insights & suggestions appreciated.

Code:
bascule:~# vzdump --dumpdir=/mnt/pve/Datastore11_vzdump --mailto foo@bar.com --snapshot 207
INFO: starting new backup job: vzdump --dumpdir=/mnt/pve/Datastore11_vzdump --mailto foo@bar.com --snapshot 207
INFO: Starting Backup of VM 207 (qemu)
INFO: running
INFO: status = running
INFO: mode failure - unable to detect lvm volume group
INFO: trying 'suspend' mode instead
INFO: backup mode: suspend
INFO: bandwidth limit: 10240 KB/s
INFO: suspend vm
INFO: creating archive '/mnt/pve/Datastore11_vzdump/vzdump-qemu-207-2010_08_05-14_22_50.tar'
INFO: adding '/mnt/pve/Datastore11_vzdump/vzdump-qemu-207-2010_08_05-14_22_50.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/var/lib/vz/images/207/vm-207-disk-1.raw' to archive ('vm-disk-ide0.raw')
INFO: adding '/var/lib/vz/images/207/vm-207-disk-3.raw' to archive ('vm-disk-ide1.raw')
INFO: adding '/var/lib/vz/images/207/vm-207-disk-2.raw' to archive ('vm-disk-ide2.raw')
INFO: adding '/var/lib/vz/images/207/vm-207-disk-4.raw' to archive ('vm-disk-scsi0.raw')
INFO: adding '/mnt/pve/Datastore10_images/images/207/vm-207-disk-1.raw' to archive ('vm-disk-scsi1.raw')
INFO: Total bytes written: 8531542528 (0.70 MiB/s)
INFO: archive file size: 7.95GB
INFO: delete old backup '/mnt/pve/Datastore11_vzdump/vzdump-qemu-207-2010_08_05-01_57_46.tar'
INFO: resume vm
INFO: vm is online again after 11676 seconds
INFO: Finished Backup of VM 207 (03:14:36)
INFO: Backup job finished successfuly
Logical volumes:
Code:
bascule:~# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "pve" using metadata type lvm2
Code:
bascule:~# lvscan
  ACTIVE            '/dev/pve/swap' [19.00 GB] inherit
  ACTIVE            '/dev/pve/root' [100.00 GB] inherit
  ACTIVE            '/dev/pve/data' [1.70 TB] inherit
Versions:
Code:
bascule:~# pveversion -v
pve-manager: 1.5-10 (pve-manager/1.5/4822)
running kernel: 2.6.32-2-pve
proxmox-ve-2.6.32: 1.5-7
pve-kernel-2.6.32-2-pve: 2.6.32-7
pve-kernel-2.6.18-2-pve: 2.6.18-5
qemu-server: 1.1-16
pve-firmware: 1.0-5
libpve-storage-perl: 1.0-13
vncterm: 0.9-2
vzctl: 3.0.23-1pve11
vzdump: 1.2-5
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.12.4-1
ksm-control-daemon: 1.0-3
 
What is the output of

Code:
df -P -T '/var/lib/vz'

and

Code:
lvs --units m --separator ':' --noheadings -o 'vg_name,lv_name,lv_size'
 
is this a NFS share?
Yes, it is.

Code:
bascule:~# df -P -T '/var/lib/vz'
Filesystem    Type 1024-blocks      Used Available Capacity Mounted on
/dev/mapper/pve-data ext3 1794346168 929174580 865171588      52% /var/lib/vz
Code:
bascule:~# lvs --units m --separator ':' --noheadings -o 'vg_name,lv_name,lv_size'
  pve:data:1780224.00M
  pve:root:102400.00M
  pve:swap:19456.00M
  pve:vzsnap-bascule-0:1024.00M
 
Looks quite normal. Would you mind to debug the perl code yourself? Take a look at

/usr/share/perl5/PVE/VZDump.pm

line 670, function get_lvm_device()

You need to find out why this does not return useful values.
 
I don't know how, but I'll do what I can.

Here's lines 662 through 676 of said file:
Code:
sub get_lvm_device {
    my ($dir, $mapping) = @_;

    my $info = get_mount_info ($dir);

    return undef if !$info;
   
    my $dev = $info->{device};

    my ($vg, $lv);

    ($vg, $lv) = @{$mapping->{$dev}} if defined $mapping->{$dev};

    return wantarray ? ($dev, $info->{mountpoint}, $vg, $lv, $info->{fstype}) : $dev;
}
 
btw, what version of vzdump do you use?

# dpkg -l vzdump
Code:
 bascule:~# dpkg -l vzdump
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  vzdump         1.2-5          OpenVZ backup scripts

...That doesn't look right
 
btw, seems there is a ´n old snapshot around:

pve:vzsnap-bascule-0:1024.00M

Does it help when you delete that snapshot?
 
Maybe that's the one in progress:
/var/lib/vz/dump/vzdump-qemu-203-2010_07_04-00_52_53.tmp
This one's been alive & well throughout, apparently doing snapshot mode right.
Code:
INFO: Starting Backup of VM 203 (qemu)
INFO: running
INFO: status = running
INFO: backup mode: snapshot
INFO: bandwidth limit: 10240 KB/s
INFO:   Logical volume "vzsnap-bascule-0" created
INFO: creating archive '/mnt/pve/Datastore11_vzdump/vzdump-qemu-203-2010_08_05-17_57_33.tar'
INFO: adding '/mnt/pve/Datastore11_vzdump/vzdump-qemu-203-2010_08_05-17_57_33.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/mnt/vzsnap0/images/203/vm-203-disk-1.raw' to archive ('vm-disk-ide0.raw')
INFO: adding '/mnt/vzsnap0/images/203/vm-203-disk-2.raw' to archive ('vm-disk-ide2.raw')

INFO: adding '/mnt/vzsnap0/images/203/vm-203-disk-3.raw' to archive ('vm-disk-ide3.raw')
 
Maybe that's the one in progress:
/var/lib/vz/dump/vzdump-qemu-203-2010_07_04-00_52_53.tmp
This one's been alive & well throughout, apparently doing snapshot mode right.

So what is the difference between this job and the failing job?
 
missing vg one has +2 SCSI

scsi0: local:207/vm-207-disk-4.raw
scsi1: Datastore10_images:207/vm-207-disk-1.raw
 
NFS does not support snapshot - so that would explain the behavior.
And there we have it, thank you. It's NFS.
---
Now I can move on to seeking why the backups stopped in the first place.
This means so far the manual backups are indeed behaving properly.

But I won't go further on that now, instead will let this thread be done.
-Thanks again.
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!