[SOLVED] Linux-Container-Migration bricht ab

S

sse

New Member
Jun 1, 2021
5
0
1
Guten Morgen,

ich habe ein Problem mit der Container-Migration (Testaufbau für spätere Prod-Umgebung):

In meinem Cluster befinden sich aktuell 2 Nodes, pve00 und pve0. Dort habe ich jeweils eine VG names vmdata01 angelegt. In den VGs habe ich wiederum jeweils ein LV namens bigdata01 angelegt¹.

Der LVM-Thin-Storage auf pve00 heißt data00, der auf pve01 heißt bigdata01.

Die Migration via Web-GUI oder Cli bricht allerdings ab:

Bash: 
root@pve00:~# pct migrate 102 pve01
2021-06-01 09:44:08 use dedicated network address for sending migration traffic (192.168.1.101)
2021-06-01 09:44:09 starting migration of CT 102 to node 'pve01' (192.168.1.101)
2021-06-01 09:44:09 found local volume 'bigdata01:vm-102-disk-0' (in current VM config)
2021-06-01 09:44:09 found local volume 'daten00:vm-102-disk-0' (via storage)
2021-06-01 09:44:11   Logical volume "vm-102-disk-0" created.
2021-06-01 09:44:20 16384+0 records in
2021-06-01 09:44:20 16384+0 records out
2021-06-01 09:44:20 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.99303 s, 107 MB/s
2021-06-01 09:44:24 49+40145 records in
2021-06-01 09:44:24 49+40145 records out
2021-06-01 09:44:24 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 13.1822 s, 81.5 MB/s
2021-06-01 09:44:24 successfully imported 'bigdata01:vm-102-disk-0'
2021-06-01 09:44:26 volume vmdata01/vm-102-disk-0 already exists
2021-06-01 09:44:26 command 'dd 'if=/dev/vmdata01/vm-102-disk-0' 'bs=64k'' failed: got signal 13
send/receive failed, cleaning up snapshot(s)..
2021-06-01 09:44:26 ERROR: storage migration for 'daten00:vm-102-disk-0' to storage 'daten00' failed - command 'set -o pipefail && pvesm export daten00:vm-102-disk-0 raw+size - -with-snapshots 0 | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve01' root@192.168.1.101 -- pvesm import daten00:vm-102-disk-0 raw+size - -with-snapshots 0 -allow-rename 0' failed: exit code 255
2021-06-01 09:44:26 aborting phase 1 - cleanup resources
2021-06-01 09:44:26 ERROR: found stale volume copy 'bigdata01:vm-102-disk-0' on node 'pve01'
2021-06-01 09:44:26 ERROR: found stale volume copy 'daten00:vm-102-disk-0' on node 'pve01'
2021-06-01 09:44:26 start final cleanup
2021-06-01 09:44:26 ERROR: migration aborted (duration 00:00:18): storage migration for 'daten00:vm-102-disk-0' to storage 'daten00' failed - command 'set -o pipefail && pvesm export daten00:vm-102-disk-0 raw+size - -with-snapshots 0 | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve01' root@192.168.1.101 -- pvesm import daten00:vm-102-disk-0 raw+size - -with-snapshots 0 -allow-rename 0' failed: exit code 255
migration aborted

Die VM-Disk wird auch übertragen, dann bricht der Vorgang allerdings ab. Die Dusk lösche ja per Web-GUI vor jedem Test bzw. bricht der Vorgang auch bei explizit neu erstellten Containern ab.

Was übersehe ich?

¹ Initial hatte ich auf den Nodes auch unterschiedliche Namen für VG und LV. Da brach die Migration aber direkt mit dem Hinweis auf die jeweilig nicht existierende VG bzw. das nicht existierende LV ab.
 
bitte den inhalt von /etc/pve/storage.cfg, output von vgs und lvs sowie pct config 102 posten.
 
Bash: 
root@pve00:~# vgs
  VG       #PV #LV #SN Attr   VSize VFree 
  pve        1   3   0 wz--n- 1.09t <16.00g
  vmdata01   1   5   0 wz--n- 3.27t      0

Bash: 
root@pve01:~# vgs
  VG       #PV #LV #SN Attr   VSize    VFree
  pve        1   3   0 wz--n- <837.34g    0
  vmdata01   1  16   0 wz--n-    3.27t    0

Bash: 
root@pve00:~# lvs
  LV                                VG       Attr       LSize    Pool      Origin         Data%  Meta%  Move Log Cpy%Sync Convert
  data                              pve      twi-aotz-- <976.88g                          0.00   0.20                           
  root                              pve      -wi-ao----   96.00g                                                                 
  swap                              pve      -wi-ao----    8.00g                                                                 
  bigdata01                         vmdata01 twi-aotz--    3.27t                          0.21   1.98                           
  snap_vm-1004-disk-0_MySQL_Install vmdata01 Vri---tz-k   50.00g bigdata01 vm-1004-disk-0                                       
  vm-1004-disk-0                    vmdata01 Vwi-aotz--   50.00g bigdata01                7.40                                   
  vm-1004-state-MySQL_Install       vmdata01 Vwi-a-tz--  <32.24g bigdata01                8.18                                   
  vm-102-disk-0                     vmdata01 Vwi-a-tz--    1.00g bigdata01                70.46

Bash: 
root@pve01:~# lvs
  LV             VG       Attr       LSize    Pool      Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data           pve      -wi-ao---- <733.34g                                                         
  root           pve      -wi-ao----   96.00g                                                         
  swap           pve      -wi-ao----    8.00g                                                         
  bigdata01      vmdata01 twi-aotz--   <3.27t                  67.77  30.19                           
  vm-100-disk-0  vmdata01 Vwi-a-tz--    8.00g bigdata01        10.52                                 
  vm-1001-disk-0 vmdata01 Vwi-aotz--   50.00g bigdata01        100.00                                 
  vm-1001-disk-1 vmdata01 Vwi-aotz--  100.00g bigdata01        100.00                                 
  vm-1003-disk-0 vmdata01 Vwi-aotz--   50.00g bigdata01        100.00                                 
  vm-1003-disk-1 vmdata01 Vwi-aotz--    1.95t bigdata01        100.00                                 
  vm-101-disk-0  vmdata01 Vwi-aotz--   30.00g bigdata01        17.33                                 
  vm-102-disk-0  vmdata01 Vwi-a-tz--    1.00g bigdata01        68.41                                 
  vm-106-disk-0  vmdata01 Vwi-aotz--   10.00g bigdata01        47.58                                 
  vm-111-disk-0  vmdata01 Vwi-a-tz--  100.00g bigdata01        42.60                                 
  vm-112-disk-0  vmdata01 Vwi-aotz--   15.00g bigdata01        14.05                                 
  vm-113-disk-0  vmdata01 Vwi-aotz--   10.00g bigdata01        18.76                                 
  vm-115-disk-0  vmdata01 Vwi-aotz--   10.00g bigdata01        20.10                                 
  vm-116-disk-0  vmdata01 Vwi-aotz--   10.00g bigdata01        21.84                                 
  vm-117-disk-0  vmdata01 Vwi-aotz--   50.00g bigdata01        10.77                                 
  vm-118-disk-0  vmdata01 Vwi-aotz--   10.00g bigdata01        16.82
Bash: 
root@pve00:~# pct config 102
arch: amd64
cores: 1
hostname: test0
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=3A:12:EC:FF:56:C1,type=veth
ostype: ubuntu
rootfs: bigdata01:vm-102-disk-0,size=0T
swap: 512
unprivileged: 1
unused0: daten00:vm-102-disk-0

Danke.
 
inhalt von /etc/pve/storage.cfg fehlt nocht ;)
 
Bash: 
root@pve00:~# cat /etc/pve/storage.cfg
dir: local
    path /var/lib/vz
    content vztmpl,iso,backup

dir: data
    path /mnt/data
    content images,rootdir,iso,snippets,vztmpl,backup
    nodes pve01
    prune-backups keep-daily=1,keep-monthly=1,keep-yearly=1
    shared 1

lvmthin: lvmthin00
    thinpool data
    vgname pve
    content rootdir,images

lvmthin: bigdata01
    thinpool bigdata01
    vgname vmdata01
    content images,rootdir

lvmthin: daten00
    thinpool bigdata01
    vgname vmdata01
    content rootdir,images
:cool:
 
du hast den thinpool "bigdata01" 2x als storage konfiguriert... redundanten eintrag wegmachen (erst aus storage.cfg, dann manuell referenzen in den gast configs sofern vorhanden). dann mit pct rescan und qm rescan storages neuscannen und ggf. configs "reparieren". dann sollte die migration wieder gehen.

vorsicht beim entfernen von unused volumes mittels GUI/API/qm set/pct set - standardmaessig werden hier die volumes geloescht! bei dem container 102 z.b. ist ein volume 2x referenziert - einmal ueber den storage 'daten00' als unused0, einmal ueber den storage 'bigdata01' als rootfs. wenn du hier jetzt unused0 entfernst, loescht du das rootfs volume (weil PVE nicht weiss, dass das volume dasselbe ist).
 
Vielen Dank für deine Erläuterungen, Fabian.

Den Thinpool bigdata01 hatte ich auf beiden Nodes eingerichtet, da es sonst direkt zu einem Abbruch der Migration kam, s. u.

Ich habe nun den gesamten Block lvmthin: daten00 aus der storage.cgf entfernt. Anschließend löschte ich den unsused-Eintrag aus der 102.conf - so weit, so gut und habe die Scans durchgeführt.

Der Thinpool bigdata01 des Nodes pve00 war dann nicht mehr im Web-GUI zu sehen (klar, ist ja gelöscht). Ich habe dann das ganze PV auf pve00 gelöscht und einen neuen Thinpool über das Web-GUI erstellt:
  1. pve00 - Disks - LVM-Thin
  2. DIsk: /dev/sdb
  3. Name: vmdata00
  4. Storage hinzufügen: selektiert
Wenn ich mir den Storage über das Rechenzentrum ansehe, wird vmdata00 nur dem Node pve00 zur Verfügung gestellt. Das habe ich geändert und ihn für alle beiden Nodes freigegeben.

Starte ich nun die Migration, erhalte ich folgende Fehler:

Bash: 
root@pve00:~# pct migrate 102 pve01
2021-06-02 11:10:24 use dedicated network address for sending migration traffic (192.168.1.101)
2021-06-02 11:10:24 starting migration of CT 102 to node 'pve01' (192.168.1.101)
  Command failed with status code 5.
command '/sbin/vgscan --ignorelockingfailure --mknodes' failed: exit code 5
2021-06-02 11:10:24 found local volume 'vmdata00:vm-102-disk-0' (in current VM config)
2021-06-02 11:10:26   Volume group "vmdata00" not found
2021-06-02 11:10:26   Cannot process volume group vmdata00
2021-06-02 11:10:26 command '/sbin/lvs --separator : --noheadings --units b --unbuffered --nosuffix --config 'report/time_format="%s"' --options vg_name,lv_name,lv_size,lv_attr,pool_lv,data_percent,metadata_percent,snap_percent,uuid,tags,metadata_size,time vmdata00' failed: exit code 5
2021-06-02 11:10:26 command 'dd 'if=/dev/vmdata00/vm-102-disk-0' 'bs=64k'' failed: got signal 13
send/receive failed, cleaning up snapshot(s)..
2021-06-02 11:10:26 ERROR: storage migration for 'vmdata00:vm-102-disk-0' to storage 'vmdata00' failed - command 'set -o pipefail && pvesm export vmdata00:vm-102-disk-0 raw+size - -with-snapshots 0 | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve01' root@192.168.1.101 -- pvesm import vmdata00:vm-102-disk-0 raw+size - -with-snapshots 0 -allow-rename 0' failed: exit code 5
2021-06-02 11:10:26 aborting phase 1 - cleanup resources
2021-06-02 11:10:26 ERROR: found stale volume copy 'vmdata00:vm-102-disk-0' on node 'pve01'
2021-06-02 11:10:26 start final cleanup
2021-06-02 11:10:26 ERROR: migration aborted (duration 00:00:02): storage migration for 'vmdata00:vm-102-disk-0' to storage 'vmdata00' failed - command 'set -o pipefail && pvesm export vmdata00:vm-102-disk-0 raw+size - -with-snapshots 0 | /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve01' root@192.168.1.101 -- pvesm import vmdata00:vm-102-disk-0 raw+size - -with-snapshots 0 -allow-rename 0' failed: exit code 5
migration aborted

...er findet also die Quell-VG vmdata01 vom Ausgangsnode nicht auf dem Zielnode.
Somit befinde ich mich wieder am Anfang: Erstelle ich gleichnamige VGs und dann LVs (die meckert er sonst auch an), bekomme ich wieder gleichnamige Thinpools in als Storage und laufe dann wieder in den eingangs beschriebenen Fehler.

Irgendwie habe ich das Gefühl an einer Ecke falsch abzubiegen…

Bash: 
root@pve00:~# vgs
  VG       #PV #LV #SN Attr   VSize VFree 
  pve        1   5   0 wz--n- 1.09t <16.00g
  vmdata00   1   2   0 wz--n- 3.27t 512.00m

Bash: 
root@pve00:~# lvs
  LV             VG       Attr       LSize    Pool     Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data           pve      twi-aotz-- <976.88g                 1.05   0.25                           
  root           pve      -wi-ao----   96.00g                                                       
  swap           pve      -wi-ao----    8.00g                                                       
  vm-1004-disk-0 pve      Vwi-aotz--   50.00g data            9.19                                   
  vm-1004-disk-1 pve      Vwi-aotz--  100.00g data            5.66                                   
  vm-102-disk-0  vmdata00 Vwi-a-tz--    1.00g vmdata00        70.18                                 
  vmdata00       vmdata00 twi-aotz--    3.24t                 0.02   0.19

Bash: 
root@pve00:~# pct config 102
arch: amd64
cores: 1
hostname: test0
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=3A:12:EC:FF:56:C1,type=veth
ostype: ubuntu
rootfs: vmdata00:vm-102-disk-0,size=1G
swap: 512
unprivileged: 1
Bash: 
root@pve00:~# cat /etc/pve/storage.cfg
dir: local
    path /var/lib/vz
    content iso,vztmpl,backup

dir: data
    path /mnt/data
    content vztmpl,snippets,images,backup,rootdir,iso
    nodes pve01
    prune-backups keep-daily=1,keep-monthly=1,keep-yearly=1
    shared 1

lvmthin: lvmthin00
    thinpool data
    vgname pve
    content images,rootdir
    nodes pve00

lvmthin: bigdata01
    thinpool bigdata01
    vgname vmdata01
    content images,rootdir

lvmthin: vmdata00
    thinpool vmdata00
    vgname vmdata00
    content rootdir,images
    nodes pve00,pve01
 
Last edited:
der knoten laesst sich wie folgt aufloesen:

pve00: thinpool mit namen foobar
pve01: ebenfalls thinpool mit namen foobar

storage.cfg: EIN storage eintrag fuer den thinpool foobar

die config ist clusterweit, und PVE weiss welche storages auf jedem node gleichen inhalt haben (==shared) und welche nicht (==local). wenn du in der GUI dann unter pve00 den storage anschaust siehst du die volumes welche lokal auf diesem node existieren. genauso fuer pve01. bei der migration wird dann kopiert.

was nicht geht ist:
- lokale storages die auf einem node nicht existieren nicht, aber in der storage.cfg als ueberall verfuegbar markiert sind (das jetzige problem)
- einen storage mehrmals in die storage.cfg schreiben, so dass PVE denselben inhalt mehrfach sieht (die urspruengliche verwirrung)
 
der knoten laesst sich wie folgt aufloesen:
Click to expand...
Das wurde er! Vielen Dank.

Ich habe noch einmal das PV gelöscht und das LV auf pve00 neu erstellt.

Bash: 
pvcreate --metadatasize 1024M -y -ff /dev/sdb1
vgcreate --metadatasize 1024M vmdata01 /dev/sdb1
lvcreate -l 100%FREE --poolmetadatasize 1024M --chunksize 256 -T -n bigdata01 vmdata01

Dabei habe ich dann zufällig gesehen, dass das neue Storage auch sofort in den Nodes auftaucht. Ich hatte nämlich bei den Vorversuchen noch eine besondere Idiotie eingebaut: Nach der Erzeugung in der CLI habe ich im Rechenzentrum noch einmal das LVM-Thin-Storage hinzugefügt. Das war blöd, fiel mir aber erst nach deinen Erläuterungen auf.

Danke noch einmal!
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back