VZDump Ignoriert --tmpdir Parameter

[Paulo Gobbato]

Guten Morgen liebe Community

Ich bzw. Unser Unternehmen hat folgendes Problem:

Wir müssen aktuell unsere Backups auf ein "langsameres" NFS System schreiben.
Um Dies zu verbessern habe wir in der Vergangenheit immer mit --tmpdir bzw. dem entsprechenden vzdump.conf Parametern gearbeitet und dies hat auch bisher wunderbar funktioniert.

Leider funktioniert dies nun nicht mehr nach dem neusten Update (Stand Gestern Abend 16.05.2019 20 Uhr).
Sämtliche Versuche es wieder zum Laufen zu bekommen sind gescheitert (verschiedene Modi etc)

pveversion ist:

proxmox-ve: 5.4-1 (running kernel: 4.15.18-14-pve)
pve-manager: 5.4-5 (running version: 5.4-5/c6fdb264)
pve-kernel-4.15: 5.4-2
pve-kernel-4.15.18-14-pve: 4.15.18-39
pve-kernel-4.15.18-13-pve: 4.15.18-37
pve-kernel-4.15.18-9-pve: 4.15.18-30
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-9
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-51
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-42
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-26
pve-cluster: 5.0-37
pve-container: 2.0-37
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-20
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-2
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-51
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.13-pve1~bpo2

Habt ihr da vielleicht noch eine Idee?

 

[t.lamprecht]

Leider funktioniert dies nun nicht mehr nach dem neusten Update (Stand Gestern Abend 16.05.2019 20 Uhr).

War das ein großes Update oder bleibt ihr eh immer recht zeitig am "Update Ball", damit wir wissen wo am besten nach dem Schudligen suchen.

Könntest du auch so einen verwendeten VZDump command hier posten?

 

[Paulo Gobbato]

War das ein großes Update oder bleibt ihr eh immer recht zeitig am "Update Ball", damit wir wissen wo am besten nach dem Schudligen suchen.

Könntest du auch so einen verwendeten VZDump command hier posten?

Das war das neueste "immer rechtzeitig am Update Ball" Update auch bzgl. Zombieload.

Der VZDump Command war

 vzdump 139 --storage backup --tmpdir /mnt/tempstor/

Der Output war wie Folgt:

root@vhost01:~# vzdump 139 --storage backup --tmpdir /mnt/tempstor/
INFO: starting new backup job: vzdump 139 --tmpdir /mnt/tempstor/ --storage backup
INFO: Starting Backup of VM 139 (qemu)
INFO: Backup started at 2019-05-17 09:40:27
INFO: status = running
INFO: update VM 139: -lock backup
INFO: VM Name: [REDACTED]
INFO: include disk 'scsi0' 'local-lvm:vm-139-disk-0' 20G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/backup/dump/vzdump-qemu-139-2019_05_17-09_40_26.vma'
INFO: started backup task 'b0dff1a3-d661-45d5-ba17-80c03d1a817d'

 

[t.lamprecht]

Hmm, kann ich hier leider nicht nachvollziehen.. Also, wenn ich sowas wie:

vzdump 90009 --storage tom_nasi --tmpdir /tmp/foo

und während das Backup läuft ein:

ls /tmp/foo

mache, sehe ich genau wie es benützt wird.

Man muss dazu sagen dass der Logoutput: "INFO: creating archive 'PFAD'" immer schon den finalen pfad ausgibt, und das das archive immer schon direkt dorthin geschrieben wurde, das tmpdir ist mehr für temporäre files, auch snapshot files, bei manchen backup modes (z.B. suspend bei CT).

Aber das gesamte Archiv lokal zu erstellen und dann automatisch auf einen andere storage zu schieben war von Haus aus nie möglich, soweit mir bekannt ist, man kann sowas aber mit den Backup hooks durchaus selber lösen.

Oder hab ich da was nicht ganz richtig verstanden?

 

[Paulo Gobbato]

Hmm, kann ich hier leider nicht nachvollziehen.. Also, wenn ich sowas wie:

vzdump 90009 --storage tom_nasi --tmpdir /tmp/foo

und während das Backup läuft ein:

ls /tmp/foo

mache, sehe ich genau wie es benützt wird.

Man muss dazu sagen dass der Logoutput: "INFO: creating archive 'PFAD'" immer schon den finalen pfad ausgibt, und das das archive immer schon direkt dorthin geschrieben wurde, das tmpdir ist mehr für temporäre files, auch snapshot files, bei manchen backup modes (z.B. suspend bei CT).

Aber das gesamte Archiv lokal zu erstellen und dann automatisch auf einen andere storage zu schieben war von Haus aus nie möglich, soweit mir bekannt ist, man kann sowas aber mit den Backup hooks durchaus selber lösen.

Oder hab ich da was nicht ganz richtig verstanden?

Bei LXC klappt das ganze auch... Nur bei KVM halt nicht mehr.

 

[t.lamprecht]

Kanns auch bei einer VM nicht nachvollziehen...

# vzdump 102 --storage tom-nasi --tmpdir /tmp/foo
...
INFO: /usr/bin/vma create -v -c /tmp/foo/vzdumptmp4124876/qemu-server.conf -c /tmp/foo/vzdumptmp4124876/qemu-server.fw exec:cat > /mnt/pve/tom-nasi/dump/vzdump-qemu-102-2019_05_29-07_50_17.dat drive-scsi0=/mnt/pve/tom-nasi/images/102/base-102-disk-0.raw

Die (temporären) config files werden zuerst nach tempdir extrahiert, die VM disken gehen direkt zum storage. Die "vma" zeile wurde in deinem geposteten Log ausgelassen, kannst du die auch mal zeigen?
Wie gesagt, bei VMs hat das mit (DIsk) Daten zuerst auf tmpdir dann autopmatisch auf Ziel storage nie funktioniert, da hat sich auch im source code nichts relevantes getan.