vzdump backup problem (stop)

[scontin]

Hi to all.
I have two Proxmox setup, up to date.

In last 4 days, till last upgrades of vzdump , backup of openvz container fail.
The method (set by web interface) is vzdump --quiet --stop --compress.

/var/run/vzdump.lock and /etc/cron.d/vzdump.lock are not deleted, and the backup log end (for instance) with "May 19 02:00:10 ERROR: Backup of VM 102 failed - command 'vzctl --skiplock stop 102' failed with exit code 40".
The backups are running smoothly in the last 2 years.

What's happening? Thanks.

 

[tom]

also post the output of 'pveversion -v'.

 

[scontin]

pve-manager: 1.8-17 (pve-manager/1.8/5948)
running kernel: 2.6.32-4-pve
proxmox-ve-2.6.32: 1.8-33
pve-kernel-2.6.32-4-pve: 2.6.32-33
qemu-server: 1.1-30
pve-firmware: 1.0-11
libpve-storage-perl: 1.0-17
vncterm: 0.9-2
vzctl: 3.0.26-1pve4
vzdump: 1.2-12
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.14.0-3
ksm-control-daemon: 1.0-5

 

[dietmar]

Seems the stop command fails. Try to run manually to see why it fails:

# vzctl stop 102

any hints?

 

[scontin]

Just tried. Manually no problems at all. Stop and start like a charm

 

[scontin]

I tried also shutdown, reboot, reinstall (after a --purge) vzdump and vzctl.
I'm tryng now downgrading of these packages. The problem is that server are production server :-(

 

[scontin]

Just tried with vzctl_3.0.24-1pve4 and vzdump_1.2-11: all OK.
So it's a problem of new version/s

 

[dietmar]

Just tried. Manually no problems at all. Stop and start like a charm

and vzdump still raise the error?

 

[scontin]

old version no. Perfect as usual.
New version have the error.
"vzdump --quiet --stop --compress --storage backup_sab 102" command that launch manually (the same of /etc/cron.d/vzdump)

 

[tom]

I confirm the issue, we will take a deeper look. in the meantime think of using snapshot mode.

 

[scontin]

In the meantime downgrade of vzdump and vzctl works for chance :-D

 

[scontin]

I confirm:
Tonight, using old versions of vzdump and vzctl, backup jobs run fine as usual.

Thanks to all.

 

[tom]

Just as a reference, the corresponding bug report:
http://bugzilla.openvz.org/show_bug.cgi?id=1878

 

[tom]

I cannot see this issue with the stable OpenVZ 2.6.18 Kernel.

Can you switch to the 2.6.18 and test again?
See http://pve.proxmox.com/wiki/Proxmox_VE_Kernel#Kernel_2.6.18

 

[scontin]

No, are production machines.... I cannot test anything :-D

 

[pixelplumber]

Just thought I'd chime in and say that I have also had the same behavior with that particular version of vzctl.

pve-manager: 1.8-17 (pve-manager/1.8/5948)
running kernel: 2.6.32-4-pve
proxmox-ve-2.6.32: 1.8-33
pve-kernel-2.6.32-4-pve: 2.6.32-33
pve-kernel-2.6.24-11-pve: 2.6.24-23
pve-kernel-2.6.24-8-pve: 2.6.24-16
qemu-server: 1.1-30
pve-firmware: 1.0-11
libpve-storage-perl: 1.0-17
vncterm: 0.9-2
vzctl: 3.0.26-1pve4
vzdump: 1.2-12
vzprocps: 2.0.11-2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.14.0-3
ksm-control-daemon: 1.0-5

Although I can't test 2.6.18 at the moment as I'm running a few live KVM machines, I notice in the previously posted openvz bug report that it looks like this has been fixed in vzctl 3.0.28 just on the 7th June (http://git.openvz.org/?p=vzctl;a=commit;h=6e4108a052fb60657f799336d1389353263e7053). So I imagine it wouldn't be too long until this came downstream to proxmox?

 

[pixelplumber]

I've scheduled a backup test for 8PM tonight to see if the recently updated vzctl package (3.0.27-1pve1) fixes this issue, but I wanted to know if anyone else has had this problem fixed with this update already?

 

[scontin]

Could't be better build a package with safe 3.0.28 package?

 

[dietmar]

Could't be better build a package with safe 3.0.28 package?

What? (we do not have a vzctl 3.0.28 package)

 

[scontin]

Ah.
In http://bugzilla.openvz.org/show_bug.cgi?id=1878 Kir Kolyshkin suggested a solution "Available in vzctl >= 3.0.28".


So I thought it was yet available

3.0.27 has some kind of patch to this problem?