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

J

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'
 
tom said:
is this a NFS share?
Click to expand...
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;
}
 
dietmar said:
btw, what version of vzdump do you use?

# dpkg -l vzdump
Click to expand...
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')
 
JustaGuy said:
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.
Click to expand...

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
 
dietmar said:
NFS does not support snapshot - so that would explain the behavior.
Click to expand...
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:
You must log in or register to reply here.
Top Bottom