VM restore mit Error

[vikozo]

hallo
nach einem Update einer VM, hat diese nicht mehr sauber gestartet.
aus diesem Grund wollte ich ein Backup von Gestern Nacht uploaden (Restoren) dies im GUI

Leider gab es folgendes Error


()
restore vma archive: lzop -d -c /var/lib/vz/dump/vzdump-qemu-107-2019_09_16-03_26_04.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp12413.fifo - /var/tmp/vzdumptmp12413
CFG: size: 484 name: qemu-server.conf
DEV: dev_id=1 size: 375809638400 devname: drive-ide0
CTIME: Mon Sep 16 03:26:06 2019
no lock found trying to remove 'create' lock
TASK ERROR: command 'set -o pipefail && lzop -d -c /var/lib/vz/dump/vzdump-qemu-107-2019_09_16-03_26_04.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp12413.fifo - /var/tmp/vzdumptmp12413' failed: error with cfs lock 'storage-NAS-04_PVE_shared-storage': unable to create image: got lock timeout - aborting command

 

[MarWin]

Selbes Problem bei mir. Möchte mehrere VMs restoren. Einige funktionieren tadellos, manche nicht. Es ist "egal", wo die Backups liegen: Hab´s erst von einem NAS, dem Ursprungsort der Sicherung versucht (timeout), dann das Backup zuerst direkt auf dem Host abgelegt. Ebenfalls "timeout".

restore vma archive: lzop -d -c /mnt/md0/temp/dump/vzdump-qemu-100-2019_09_15-23_59_01.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp32733.fifo - /var/tmp/vzdumptmp32733
CFG: size: 456 name: qemu-server.conf
DEV: dev_id=1 size: 8589934592000 devname: drive-scsi0
CTIME: Sun Sep 15 23:59:03 2019
no lock found trying to remove 'create' lock
TASK ERROR: command 'set -o pipefail && lzop -d -c /mnt/md0/temp/dump/vzdump-qemu-100-2019_09_15-23_59_01.vma.lzo | vma extract -v -r /var/tmp/vzdumptmp32733.fifo - /var/tmp/vzdumptmp32733' failed: command '/usr/bin/qemu-img create -o 'preallocation=metadata' -f qcow2 /mnt/md0/images/100/vm-100-disk-0.qcow2 8388608000K' failed: got timeout

Das Problem entsteht dann, wenn das Backupfile einfach eine gewisse Größe überschreitet.

Werde mir jetzt die Problem-Backups zuerst auf der Konsole entpacken und dann einen weiteren Versuch starten.

 

[vikozo]

Ich hab es bisher nur im GUI Gemacht - wenn es hinweise und TIPS gibt via Konsole - dann gerne

 

[CoolTux]

Von welcher Größe sprechen wir hier? Ich habe schon erfolgreich 150 GB zurück gespielt.

 

[fiona]

Hallo vikozo,
Hallo MarWin,
kann es sein, dass zum Zeitpunkt des restore das Netzwerk überlastet ist oder die Storage von anderen Services/Prozessen exklusiv genutzt wird (z.B. mehrere Restores gleichzeitig)? Weil beim Erzeugen eines Images wird die Storage temporär clusterweit gesperrt. Könntet ihr den Output von 'pveversion -v' und eure 'storage.cfg' posten?

MarWin, du sagst es hängt von der Größe des Backups ab. Ist das konsistent so, also große Files schlagen immer fehl?
Wie ist das Verhalten vor dem Timeout? Hängt es eine Zeit lang oder kommt das Timeout schneller als es sollte? Das Entpacken beginnt gar nicht erst oder doch?

 

[vikozo]

ich habe nur ein restore gemacht und nur qemu-107
das "restore" ging soweit das fehlerhafte qemu-107 komplett zu vernichten, das anfänglich "nur" Fehler machte nach einem Update.

 

[MarWin]

Hallo vikozo,
Hallo MarWin,
kann es sein, dass zum Zeitpunkt des restore das Netzwerk überlastet ist oder die Storage von anderen Services/Prozessen exklusiv genutzt wird (z.B. mehrere Restores gleichzeitig)? Weil beim Erzeugen eines Images wird die Storage temporär clusterweit gesperrt. Könntet ihr den Output von 'pveversion -v' und eure 'storage.cfg' posten?

MarWin, du sagst es hängt von der Größe des Backups ab. Ist das konsistent so, also große Files schlagen immer fehl?
Wie ist das Verhalten vor dem Timeout? Hängt es eine Zeit lang oder kommt das Timeout schneller als es sollte? Das Entpacken beginnt gar nicht erst oder doch?

Zum Ersten: Nein, Netzwerk ist nicht überlastet. Es passiert ja auch, wenn das File auf dem lokalen Host liegt. Gleichzeitig stelle ich nichts her - entfällt also auch.

Zum Zweiten: Es ist komplett reproduzierbar. Es sind immer die selben VMs die sich nicht restoren lassen. Diejenigen, welche funktionieren, funktionieren auch immer und die haben ca. 10, 15 GB. Wir reden hier über z.B. eine VM, deren vmo.lzo Archiv ca. 600GB groß ist.

In der GUI beginnt der restore Prozess ohne das je eine Prozent-Angabe "kommt". Bis zum Abbruch vergehen allerdings mehrere Minuten - keine Ahnung geschätzt vielleicht 10 Minuten. In der Konsole sieht man allerdings im Filesystem, dass eine Datei angelegt wird, welche auch größer wird. Dann halt bis zum Timeout und dann ist Ende.

Den Output kann ich z.Z. nicht posten, da ich nicht mehr vor Ort bin... Folgt aber.

Das rückspielen der *.vma Datei (also der bereits entpackten Sicherung) über die GUI funktioniert allerdings auch nicht - auch hier Timeout - auch hier liegt die *.vma Datei auf dem Host selber und nicht mehr im Netz.

 

[MarWin]

Hier einmal die Ausgabe von: pveversion -v

proxmox-ve: 6.0-2 (running kernel: 5.0.15-1-pve)
pve-manager: 6.0-4 (running version: 6.0-4/2a719255)
pve-kernel-5.0: 6.0-5
pve-kernel-helper: 6.0-5
pve-kernel-5.0.15-1-pve: 5.0.15-1
ceph-fuse: 12.2.11+dfsg1-2.1
corosync: 3.0.2-pve2
criu: 3.11-3
glusterfs-client: 5.5-3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.10-pve1
libpve-access-control: 6.0-2
libpve-apiclient-perl: 3.0-2
libpve-common-perl: 6.0-2
libpve-guest-common-perl: 3.0-1
libpve-http-server-perl: 3.0-2
libpve-storage-perl: 6.0-5
libqb0: 1.0.5-1
lvm2: 2.03.02-pve3
lxc-pve: 3.1.0-61
lxcfs: 3.0.3-pve60
novnc-pve: 1.0.0-60
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.0-5
pve-cluster: 6.0-4
pve-container: 3.0-3
pve-docs: 6.0-4
pve-edk2-firmware: 2.20190614-1
pve-firewall: 4.0-5
pve-firmware: 3.0-2
pve-ha-manager: 3.0-2
pve-i18n: 2.0-2
pve-qemu-kvm: 4.0.0-3
pve-xtermjs: 3.13.2-1
qemu-server: 6.0-5
smartmontools: 7.0-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.1-pve1

 

[MarWin]

Und hier die storage-cfg

dir: local
<------>path /var/lib/vz
<------>content backup,vztmpl,iso

zfspool: local-zfs
<------>pool rpool/data
<------>content images,rootdir
<------>sparse 1

dir: md0
<------>path /mnt/md0
<------>content images
<------>shared 0

cifs: PoxmoxBackup
<------>path /mnt/pve/PoxmoxBackup
<------>server 192.168.0.3
<------>share server_backup
<------>content backup
<------>maxfiles 3

 

[MarWin]

OK, neuer Zwischenstand: Vorher war meine Konfiguration wie folgt: Kleiner Server mit 4x HDDs. 2x davon SSD, 2x HDD SATA. Proxmox Host war installiert auf zwei SSD-HDDs ZFS-Raid1. Die "große" VM lag auf einem normalen Software-Raid 1 (md0, ext4) aus 2x 10TB HDDs, welches als Verzeichnis eingebunden war. Der Restore großer VMs schlägt immer fehl.

Ich habs nun mal anders gemacht. Proxmox Clean-Install auf einem ZFS-Raid1 diesesmal auf den 2x10T HDDs. Die anderen SSD-Platten nicht mehr gesteckt. Restore angestossen und siehe da: 1%, 2%, 3%.... Jetzt mal wieder paar Stunden warten und gucken was dann passiert ist.

Da es sich immer um ein "Clean-Install", ohne weitere Bastell-Geschichten gehandelt hat, wird´s wohl was mit dem Restore in ein Software-Raid zu tun haben... bzw. mit der Tatsache das überhaupt ein Software-Raid angelegt war.

 

[vikozo]

und meine Version

# pveversion -v
proxmox-ve: 5.4-2 (running kernel: 4.15.18-21-pve)
pve-manager: 5.4-13 (running version: 5.4-13/aee6f0ec)
pve-kernel-4.15: 5.4-9
pve-kernel-4.15.18-21-pve: 4.15.18-47
pve-kernel-4.15.18-18-pve: 4.15.18-44
pve-kernel-4.15.18-17-pve: 4.15.18-43
pve-kernel-4.15.18-16-pve: 4.15.18-41
pve-kernel-4.15.18-15-pve: 4.15.18-40
pve-kernel-4.15.18-12-pve: 4.15.18-36
pve-kernel-4.15.18-11-pve: 4.15.18-34
pve-kernel-4.15.17-3-pve: 4.15.17-14
pve-kernel-4.4.98-5-pve: 4.4.98-105
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-12
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-54
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-14
libpve-storage-perl: 5.0-44
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-7
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
openvswitch-switch: 2.7.0-3
proxmox-widget-toolkit: 1.0-28
pve-cluster: 5.0-38
pve-container: 2.0-40
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-22
pve-firmware: 2.0-7
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-4
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-54
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3

 

[vikozo]

vi /etc/pve/storage.cfg

dir: local
path /var/lib/vz
content images,backup,vztmpl,iso,rootdir
maxfiles 2
shared 1

cifs: NAS-04_Proxmox
path /mnt/pve/NAS-04_Proxmox
server 10.147.42.73
share share_bkp-Proxmox
content iso,vztmpl,backup,images,rootdir
maxfiles 7
username ubkp-proxmox

nfs: NAS-04_PVE_shared-storage
export /mnt/NAS-04vol/share_PVE_shared-storage
path /mnt/pve/NAS-04_PVE_shared-storage
server 10.147.42.73
content rootdir,images,backup,vztmpl,iso
maxfiles 7
options vers=3

 

[vikozo]

was genau bedeutet diese Fehlermeldung

unable to restore VM 107 - can't lock file '/var/lock/qemu-server/lock-107.conf' - got timeout (500)

oder wie kann ich das unlock ?

 

[bluesite]

qm unlock 107
in der Konsole eingeben

 

[fiona]

Zum Ersten: Nein, Netzwerk ist nicht überlastet. Es passiert ja auch, wenn das File auf dem lokalen Host liegt. Gleichzeitig stelle ich nichts her - entfällt also auch.

Zum Zweiten: Es ist komplett reproduzierbar. Es sind immer die selben VMs die sich nicht restoren lassen. Diejenigen, welche funktionieren, funktionieren auch immer und die haben ca. 10, 15 GB. Wir reden hier über z.B. eine VM, deren vmo.lzo Archiv ca. 600GB groß ist.

In der GUI beginnt der restore Prozess ohne das je eine Prozent-Angabe "kommt". Bis zum Abbruch vergehen allerdings mehrere Minuten - keine Ahnung geschätzt vielleicht 10 Minuten. In der Konsole sieht man allerdings im Filesystem, dass eine Datei angelegt wird, welche auch größer wird. Dann halt bis zum Timeout und dann ist Ende.

Den Output kann ich z.Z. nicht posten, da ich nicht mehr vor Ort bin... Folgt aber.

Das rückspielen der *.vma Datei (also der bereits entpackten Sicherung) über die GUI funktioniert allerdings auch nicht - auch hier Timeout - auch hier liegt die *.vma Datei auf dem Host selber und nicht mehr im Netz.

Danke für die Info. Ich sehe im Code eine Stelle, wo wir 10 Minuten Timeout setzen, das Problem ist wohl da in der Nähe.
Könntest du nochmal das fehlschlagende 'qmrestore' ausführen und Befehl und Ausgabe posten? Welche Datei wird angelegt und wie groß ist sie nach den 10 Minuten?

 

[vikozo]

Also ich konnte im GUI das Backup starten und es lief durch, ausser das das Lokale Backup (duration 12343 sec) hat und es lange ist zum warten ;-)
ein weiteres Problem war, das im VM das Root Verzeichnis auf RO war... hat aber wohl nichts mit Proxmox zu tun...
für mich soweit [solved] vielen Dank @Fabian_E