Migrate scheitert / Cannot process volume group pve

[Thorsten119]

Hi,

ich habe frisch meine 2 nodes mir Proxmox (5.1-36) installiert. node1 hat ein Hardware-Raid mit ext4. node2 soll mein Notfall-Host werden. Hier sind 2 Festplatten drin und hier habe ich bei der Installation ZFS (Raid1) gewählt. Ich habe beide nodes in einem Cluster zusammengefasst. Soweit alles gut. Nun scheiter aber meiner erster Versuch, einen Container von node1 zu node2 zu migrieren.

Die Fehlermeldung seht ihr unten. Wenn ich allerdings das lvs-Kommando in der Shell ausführe, dann ist das Ergebnis ok (siehe weiter unten). Auch das dd-Kommando passt ansich.

Wo mache ich denn bitte hier den Fehler?

root@node1:~# pct migrate 105 node2
2018-01-04 18:45:24 starting migration of CT 105 to node 'node2' (ipNumber here)
2018-01-04 18:45:24 found local volume 'local-lvm:vm-105-disk-1' (in current VM config)
Volume group "pve" not found
Cannot process volume group pve
command '/sbin/lvs --separator : --noheadings --units b --unbuffered --nosuffix --options vg_name,lv_name,lv_size,lv_attr,pool_lv,data_percent,metadata_percent,snap_percent,uuid,tags pve' failed: exit code 5
command 'dd 'if=/dev/pve/vm-105-disk-1' 'bs=64k'' failed: got signal 13
send/receive failed, cleaning up snapshot(s)..
2018-01-04 18:45:25 ERROR: command 'set -o pipefail && pvesm export local-lvm:vm-105-disk-1 raw+size - -with-snapshots 0 | /usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=matroschka4' root@213.202.251.190 -- pvesm import local-lvm:vm-105-disk-1 raw+size - -with-snapshots 0' failed: exit code 5
2018-01-04 18:45:25 aborting phase 1 - cleanup resources
2018-01-04 18:45:25 ERROR: found stale volume copy 'local-lvm:vm-105-disk-1' on node 'matroschka4'
2018-01-04 18:45:25 start final cleanup
2018-01-04 18:45:25 ERROR: migration aborted (duration 00:00:01): command 'set -o pipefail && pvesm export local-lvm:vm-105-disk-1 raw+size - -with-snapshots 0 | /usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=matroschka4' root@213.202.251.190 -- pvesm import local-lvm:vm-105-disk-1 raw+size - -with-snapshots 0' failed: exit code 5
migration aborted

root@matroschka3:~# /sbin/lvs --separator : --noheadings --units b --unbuffered --nosuffix --options vg_name,lv_name,lv_size,lv_attr,pool_lv,data_percent,metadata_percent,snap_percent,uuid,tags pve
pve:swap:8589934592:-wi-ao----:::::ThPFYt-FhnT-8p6d-ZvCQ-kv6A-okxT-jd4KEs:
pve:root:103079215104:-wi-ao----:::::qIqZYL-ceR0-oK9p-ghPI-hL5w-k8VW-2gcOzy:
pve:data:870536183808:twi-aotz--::2.78:1.68:2.78:ISSoBX-FsnO-mSwg-t583-U023-7ANF-pRfpQh:
pve:vm-100-disk-1:42949672960:Vwi-aotz--:data:7.99::7.99:61gxOI-jTNJ-sPNx-a2HO-sWTG-WG1n-KPpfgF:
pve:vm-101-disk-1:13958643712:Vwi-aotz--:data:17.39::17.39:NrgpJi-WeP1-Z0XP-0k6T-fW23-Du3E-vuY61a:
pve:vm-102-disk-1:42949672960:Vwi-aotz--:data:26.90::26.90:zXCYV0-m0Po-8qTX-6kdH-n0ar-dJPD-Cbp7v7:
pve:vm-103-disk-1:8589934592:Vwi-aotz--:data:43.43::43.43:5ggGSP-gdJP-8y5o-l075-xIQK-79gM-jiNL4r:
pve:vm-104-disk-1:12884901888:Vwi-aotz--:data:16.13::16.13:XXh1ya-ksjU-ql77-7vmV-WXMJ-LC3a-KcuW1A:
pve:vm-105-disk-1:8589934592:Vwi-a-tz--:data:11.10::11.10:xWbavs-eyVR-q6Vb-T3nt-ipeH-nBL4-ytVO75:

Mit besten Grüßen,
Thorsten

 

[wolfgang]

Hallo,

das Problem ist das du auf der anderen Seite kein local-lvm hast.
Du verwendest ja ZFS.
Du kannst nur über die command line mit dem parameter -targetstorage migrieren.

Siehe
https://pve.proxmox.com/pve-docs/pv...ng_qm_strong_qemu_kvm_virtual_machine_manager

 

[Thorsten119]

Hi Wolfang,

danke. Aber ich nutze nur container. Dafür käme (sofern ich es richtig verstehe) pct migrate zum Einsatz. Allerdings kennt das Kommando die Option "--targetstorage" nicht.

Hast Du noch einen Tipp für mich?

Schöne Grüße, Thorsten

 

[wolfgang]

Ja mit container geht es nicht es gibt eh schon einen Bugeintrag.
https://bugzilla.proxmox.com/show_bug.cgi?id=1532
Ich würde dir empfehlen entweder zu warten bis das Feature umgesetzt ist oder
ändere eines deiner Storages auf einen anderen Type.
Backup und Restore mit manuellen kopieren.
Was du auch machen kannst ist eine manuelle Migration mit dd über ssh.

 

[Merundius]

Hi,

Ich versuche gerade von einem Proxmox 5 mit LVM-thin auf einen Proxmox 5 mit zfs Maschinen und Container zu verschieben.

Die Gui-Migration klappt aus obenbeschriebenen Gründen nicht.

Wenn ich nun ein Backup eines Containers anfertige und dieses auf dem ZFS-based Host einspielen will bekomme ich in der GUI nur "local-lvm" als Restore-Ziel angezeigt - was dann fehlschlägt.

Gibt es eine Möglichkeit einstorage-unabhängiges Backup-File zu erzeugen? Oder einen anderen Workaround?
Welche Dateien müsste ich manuell kopieren um eine VM/CT umzuziehen?

(Die Openvz Backups aus einem PVE3.x /LVM+EXT4 einzuspielen war übrigens kein Problem )

Danke!

Viele Grüße,

Martin

 

[fireon]

Wenn ich nun ein Backup eines Containers anfertige und dieses auf dem ZFS-based Host einspielen will bekomme ich in der GUI nur "local-lvm" als Restore-Ziel angezeigt - was dann fehlschlägt.

Das ist kein Problem. Du musst die Storages den Hosts einmal richtig zuweisen. Da genügt es nicht den Host anzuklicken, sondern du musst dich mit dem Zielhost (bei dir ZFS) am Webinterface einloggen, dann auf Rechenzentrum gehen, und dort kannst dann ZFS dem richtigen Host zuweisen.

Das passiert alles so wenn du verschieden Storagetypen auf verschiedenen Hosts hast. Das hab ich auch bei ein paar Server, aber nur gezwungener Maßen. Ist absolut nicht zu empfehlen, ist nur verwirrend.

 

[Merundius]

Hi Fireon,

Genial , das hat geklappt - danke!

Die Zwei uterschiedlichen Storagetypen versuche ich gerade zu eliminieren - das testen mit lvm-thin überzeugte mich nicht ganz (https://forum.proxmox.com/threads/huge-io-delay-when-recovering-vm.38703/) da ich bei mehreren Restores gleichzeitig elegant den ganzen host getötet hatte - jetzt also ein neuer Anlauf mit ZFS!

Viele Grüße

Martin

 

[fireon]

Ja ich bin auch ein Freund von ZFS. Bei Raidcontrollern mit Cache haben wir aber alles LVM-Thin. Wenn du im Forum suchst, wirst du zu vielen Beiträgen kommen wo ein Recovery von LVM-Thin super langsam geht. Das hat immer zwei Ursachen. Entweder ist der Server/PC dafür einfach zu alt. Oder es ist was defekt. Bei mir war vor ca. 3 Wochen nach nem Serverfirmwareupgrade bei HP das Cachratio komplett verstellt. Der Import ging mit ca. 10MB/s. Und Proxmox reagierte nicht mehr. Nach berichtigen des Cachratios am Controller gings wieder mit 120MB/s und alles reagierte normal. LVM-Thin verzeiht eben nichts.

 

[Merundius]

Ein interessanter Punkt, danke. Wie ist/war Dein Cacheratio konfiguriert? Wir hatten den Write-Cache komplett deaktiviert:

Cache Board Present: True
Cache Status: Not Configured
Cache Ratio: 100% Read / 0% Write
Read Cache Size: 0 MB
Write Cache Size: 0 MB
Drive Write Cache: Disabled
Total Cache Size: 2.0 GB
Total Cache Memory Available: 1.8 GB
No-Battery Write Cache: Disabled

Im Forum war mal die Proxmox-Support-Empfehlung:

This is very likely due to some cache running full and LVM syncs to the RAID. A alternative is to restore to a non-LVM storage and use the disk move option.

Und dann gibt es ja noch die Empfehlung das qmrestore zu limitieren - aber eine robuste Lösung, die verhindert dass jemand über die GUI mit einem einfachen Restore den ganzen Node lahmlegt wäre schon toll.

Mit ZFS haben wir das problem nun nicht - nebenbei, auf der identischen Hardware haben wir mit ZFS RaidZ2 + hbamode :

CPU BOGOMIPS: 199509.20
REGEX/SECOND: 1811194
FSYNCS/SECOND: 362.50

dd if=/dev/zero of=/root/testfile bs=512 count=10000 oflag=dsync
5120000 bytes (5.1 MB, 4.9 MiB) copied, 26.7523 s, 191 kB/s

dd if=/dev/zero of=/tmp/testfile bs=20G count=1 oflag=dsync
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 1.80488 s, 1.2 GB/s

dd if=/dev/zero of=/tmp/testfile bs=2G count=10 oflag=dsync
21474795520 bytes (21 GB, 20 GiB) copied, 14.5361 s, 1.5 GB/s

(ok - die letzten beiden sind gemein: Die Komprimierung vom ZFS haut /dev/zero natürlich komplet weg )

mit lvm-thin / HW-RAID6 mit 2GB Readcache:

CPU BOGOMIPS: 199518.40
REGEX/SECOND: 722359
FSYNCS/SECOND: 183.03

dd if=/dev/zero of=/root/testfile bs=512 count=10000 oflag=dsync
5120000 bytes (5.1 MB, 4.9 MiB) copied, 75.105 s, 68.2 kB/s

dd if=/dev/zero of=/tmp/testfile bs=20G count=1 oflag=dsync
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 11.2474 s, 191 MB/s

dd if=/dev/zero of=/tmp/testfile bs=2G count=10 oflag=dsync
21474795520 bytes (21 GB, 20 GiB) copied, 97.4041 s, 220 MB/s


Von daher bleiben wir glaube ich bei ZFS.

Hast Du Vergleichswerte aus der Praxis bezüglich Stabilität und Performance im Vergleich zwischen lvm/zfs?

 

[fireon]

Ein interessanter Punkt, danke. Wie ist/war Dein Cacheratio konfiguriert? Wir hatten den Write-Cache komplett deaktiviert

Naja, so kanns nicht nicht gehen. Von HP aus steht das auf Read25 und Write75.

Hast Du Vergleichswerte aus der Praxis bezüglich Stabilität und Performance im Vergleich zwischen lvm/zfs?

Stabil ist beides, beides läuft mit der richtige Hardware einwandfrei. ZFS kann halt viel viel mehr, benötigt aber auch mehr CPU und RAM je nach Anwendungsgebiet. LVM-Thin hat eben die ganzen netten ZFS-Features nicht, und braucht einen Raidcontroller funktionierenden und richtig konfigurierten CACHE. ZFS benötigt da ja nicht direkt auf die Platten geschrieben wird einen ZFS-Cache (mehr für viele kleine Dateien). Ich hab auch damit die Erfahrung gemacht ZFS für gleiche Geschwindigkeit mehr HDD/SSD's benötigt als ein HWRaid.
Fazit: Würde es trotzdem niemals gegen ein HWRaid tauschen. Könnte auf die Funktionalitäten von ZFS nicht verzichten. Vor allem die Selbstheilung, Komprimierung und die einfache Handhabung.