VM Disks nach dem Verschieben auf anderes Storage defekt/korrupt

aL1aL7

aL1aL7

Member
Proxmox Subscriber
Apr 4, 2024
34
8
13
Hallo Zusammen,

ich hatte heute ein komisches Phänomen, welches ich so nicht kenne.

Ausgangssituation:
  • Win2022 VM mit Disks auf einem local-zfs (Single NVMe - das Risiko Datenverlust ist mir bekannt und hinnehmbar)
  • Disks in der VM als virtio-Devices
  • VM wird regelmäßig zu einem anderen Host repliziert
Ziel:
Ich habe mir das Wearout meiner NMVe angesehen und bin dann doch zu dem Entschluss gekommen die Platten der VM müssen auf mein Storage (iSCSI mit Multipath als LVM, nur RAW-Disks). Bis auf wenige Ausnahmen laufen auf diesem Storage ca. 20 VM's problemlos.

Vorgehen:
  • VM herunterfahren
  • über die UI das Verschieben der Disks auf das iSCSI Ziel angestoßen - hier als Zielformat RAW gewählt und dummerweise Quelldisk löschen
  • Verschiebevorgang abgewartet (100% - Task Ok)
  • VM auf anderen Host geschoben mit älterer CPU (hier hatte ich beim Start den Fehler:
    Code: 
    CPU flag 'nested-virt' resolved to 'vmx'
swtpm_setup: Not overwriting existing state file.
kvm: warning: host doesn't support requested feature: CPUID[eax=80000008h].EBX.virt-ssbd [bit 25]
kvm: warning: host doesn't support requested feature: CPUID[eax=80000008h].EBX.virt-ssbd [bit 25]
kvm: warning: host doesn't support requested feature: CPUID[eax=80000008h].EBX.virt-ssbd [bit 25]
kvm: warning: host doesn't support requested feature: CPUID[eax=80000008h].EBX.virt-ssbd [bit 25]
TASK OK
  • VM eingeschaltet -> landet im Reparaturmodus von Windows
  • Im Reparaturmodus von Win über diskpart nachgesehen -> oh, keine Platte da - wo sind die virtio-Treiber ????
  • Boot-Disk von virtio auf SATA gestellt -> Wieder Windows Reparaturmodus, diesmal jedoch mit der Option "Fortsetzen"
  • Nach dem "Fortsetzen" landet man dann leider wieder im Reparaturmodus mit "Fortsetzen" - also Boot-Loop
  • Hab dann noch am BCD rumgespielt mit dem Ergebnis - Kernel Prüfsummen Mismatch
  • Aufgegeben und Backup zurückgespielt

Ich finde weder im Journal noch in den Task-Logs irgendwelche Hinweise, dass etwas schief gelaufen ist. Kann es an der anderen CPU liegen??
 
Steht doch da:

Code: 
CPU flag 'nested-virt'...
kvm: warning: host doesn't support requested feature...

Also Nested-Virt in den CPU-Einstellungen deaktivieren.
 
Yoa, aber warum fliegen dann virtio-Treiber aus der Win-Installation? Damit hat ja die nested Virtualisierung nix zu tun.
Das Backup das ich zurückgespielt habe, habe ich extra so belassen wie die Original-VM, da ist das Flag auch gesetzt und die VM kommt trotzdem hoch (Fehler ist im Start genauso drin)
 
Dass diskpart in der WinRE keine Platte sieht, ist normal. Die Recovery-Umgebung hat die virtio-Treiber nicht an Bord, das zeigt nicht, dass beim Move was kaputtgegangen ist. Der Rest klingt weniger nach korrupten Daten als nach zerschossener Boot-Kette.

An der CPU allein liegt es nicht, ein anderes CPU-Modell zerschießt keine Blöcke auf der Disk. Du hast aber einen swtpm dran und nested-virt gesetzt. Läuft in der VM BitLocker bzw. VBS/Credential Guard? Der Wechsel von virtio auf SATA zusammen mit dem anderen CPU-Modell ändert die Measured-Boot-Kette, und dann kommst du je nach Konfig nicht mehr sauber hoch. Der Prüfsummen-Mismatch nach der BCD-Bastelei passt da auch ins Bild.

Fürs nächste Mal würde ich die Disks verschieben und die VM erst auf dem gleichen Host wieder hochfahren, bevor sie auf den anderen Node geht. Dann weißt du, welcher der beiden Schritte es war. Und "Quelle löschen" beim Move lasse ich weg, das Quell-Volume räumt man weg wenn die VM nachweislich läuft, nicht vorher.
 
  • Like
Reactions: ThoSo and news
Wo kommt das Backup wieder hoch? Auf der originalen Maschine oder auf dem Host mit der älteren CPU?

Kannst du mal genau sagen was die Start-CPU und was die Ziel-CPU ist?
 
Last edited:
Nein Bitlocker o. Ä. ist nicht aktiviert.

Das Backup das ich zurückgespielt habe, habe ich direkt auf dem anderen Host restored. Nach dem Restore (Host mit alter CPU) ist die VM gleich hochgekommen.

Oh man, ich Vollhonk - jetzt wo Du es schreibst mit der Reparaturkonsole, logisch kann die die Platten nicht kennen - autsch das schmerzt körperlich, dass ich da gestolpert bin.
 
Ohne BitLocker/VBS und mit einem Restore, der auf genau dem alten Host mit denselben CPU-Flags sofort hochkommt, ist die CPU raus. Bleibt der Move selbst oder die Bootkette.

Liegt die LV auf dem iSCSI noch rum? Falls ja, häng sie mal als zweite Platte an irgendeine Linux-VM und schau mit fdisk -l und ntfsfix -n /dev/... drauf. Sind Partitionstabelle und NTFS heil, war nie was korrupt und du hast dir nur mit dem Umstellen auf SATA plus BCD-Bastelei die Bootkonfig zerlegt. Sieht es dagegen wirklich zerschossen aus, würd ich mir Multipath auf dem Zielhost anschauen (Pfade/WWIDs, ob da wirklich nur die eine LV drauf liegt).

Zwei Sachen, die mich noch interessieren würden: läuft die VM mit OVMF, und sind efidisk und tpmstate beim Verschieben auf den iSCSI-Storage gewandert oder auf dem local-zfs liegengeblieben? Und war der Replikationsjob noch aktiv, als die Disks schon auf dem gemeinsamen Storage lagen? Der gehört danach weg, sonst kann dir das beim Migrieren noch dazwischenfunken.
 
Jetzt wird's kurios.

Eben eine Linux VM mit dem gleichen Ziel: Disk von local-zfs auf iSCSI verschieben.
Maschine war auch aus.VM am gleichen Host gelassen. Diesmal die Original Disk behalten.

Linux mit neuer Disk startet mit Grub und bleibt danach hängen weil angeblich nicht mehr in das Journal geschrieben werden kann und Dateisystemfehler.
Bootvorgang bleibt da dann hängen.
Originaldisk wieder rein -> VM bootet
Neue Disk auf iSCSI wieder rein, kurzer automatischer fsck beim boot, Maschine läuft. Die Journaleinträge mit dem kaputten Boot gibt es nicht (naja war anscheinend die Journaldatei im Eimer)

Das war dann im darauffolgendem Journal
Code: 
File /var/log/journal/6cc9fdf6e4454155b0d3ac2b7d53d588/system.journal corrupted or uncleanly shut down, renaming and replacing.

@Bu66as​

Ne, die kaputte Platte liegt leider nicht mehr rum.
Den Replika-Job habe ich im Nachgang gestoppt. Zum Zeitpunkt des Disk-Moves war der aber nicht aktiv


Ich hatte im letzten halben Jahr schon viele Platten verschoben - ohne Probleme. In der Regel waren die Maschinen da jedoch immer im Betrieb (auch heute schon 2 ohne Probleme).
 
Damit hast du es ja jetzt sauber reproduziert, ohne CPU-Wechsel, ohne BCD-Gebastel, gleicher Host. Dann liegt es wirklich am Move auf das iSCSI-LVM und nicht an dem ganzen Kram drumherum.

Interessant finde ich den Unterschied online/offline. Bei laufender VM zieht PVE die Disk per drive-mirror durch den QEMU-Blocklayer, bei ausgeschalteter läuft ein qemu-img convert. Wenn da am Ende nichts richtig runtergeschrieben/geflusht wird, passt das Schadensbild ziemlich genau: die zuletzt geschriebenen Blöcke (Journal, NTFS-Metadaten) sind im Eimer, der Rest ist heil. Passt auch dazu, dass deine bisherigen Moves im laufenden Betrieb problemlos waren.

Das kannst du hart nachweisen: nochmal offline verschieben, Quelle behalten, VM danach nicht starten, und dann die beiden Blockdevices direkt vergleichen. Größe vom zvol holen und damit begrenzen, weil das LV meist auf Extent-Größe aufgerundet ist.

Wenn da ein Unterschied rausfällt, hast du einen handfesten Bug-Report für die Proxmox-Leute statt Rätselraten.

Was ich noch wissen wollte: was sagt pveversion -v, und hängt die VG wirklich auf dem Multipath-Device (/dev/mapper/...) oder sieht LVM die einzelnen Pfade auch noch? multipath -ll und lvmconfig --type diff (Filter/global_filter) brauch ich da. Wenn LVM das mpath-Device und die nackten sdX beide als PV sieht, kann sowas sporadisch genau so aussehen.
 
Code: 
lvmconfig --typeconfig diff                                                                                                                                                                            14:13:38
devices {
        global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]
}

Hier mal die multipath -ll
Code: 
vm_pve_sas_01 (3600c0ff00051b20b98e2166901000000) dm-1 DellEMC,ME4
size=7.3T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 19:0:0:0 sdc 8:32  active ready running
| |- 17:0:0:0 sdb 8:16  active ready running
| |- 21:0:0:0 sdj 8:144 active ready running
| `- 24:0:0:0 sdm 8:192 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 18:0:0:0 sdd 8:48  active ready running
  |- 20:0:0:0 sde 8:64  active ready running
  |- 23:0:0:0 sdl 8:176 active ready running
  `- 22:0:0:0 sdk 8:160 active ready running
vm_pve_ssd_01 (3600c0ff00051c8c098b1316901000000) dm-0 DellEMC,ME4
size=3.2T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 20:0:0:1 sdg 8:96  active ready running
| |- 18:0:0:1 sdf 8:80  active ready running
| |- 22:0:0:1 sdo 8:224 active ready running
| `- 23:0:0:1 sdp 8:240 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  |- 17:0:0:1 sdh 8:112 active ready running
  |- 19:0:0:1 sdi 8:128 active ready running
  |- 21:0:0:1 sdn 8:208 active ready running
  `- 24:0:0:1 sdq 65:0  active ready running

Hier pverversion
Code: 
❯ pveversion -v                                                                                                                                                                                          14:04:59
proxmox-ve: 9.2.0 (running kernel: 7.0.14-11-pve)
pve-manager: 9.2.10 (running version: 9.2.10/43df2e01f27a1a19)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.14-11
proxmox-kernel-7.0.14-11-pve-signed: 7.0.14-11
proxmox-kernel-7.0.14-8-pve-signed: 7.0.14-8
proxmox-kernel-6.17: 6.17.13-21
proxmox-kernel-6.17.13-21-pve-signed: 6.17.13-21
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.3-pve4
corosync: 3.1.10-pve3
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve3
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-7
libproxmox-acme-perl: 1.7.2
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.2.1
libpve-guest-common-perl: 6.0.5
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.7
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.8
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.3-1
proxmox-backup-file-restore: 4.2.3-1
proxmox-backup-restore-image: 1.0.0
proxmox-enterprise-support-keyring: 1.1
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.7
pve-cluster: 9.1.6
pve-container: 6.1.13
pve-docs: 9.2.4
pve-edk2-firmware: 4.2025.05-3
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.5
pve-firmware: 3.18-5
pve-ha-manager: 5.2.5
pve-i18n: 3.10.0
pve-qemu-kvm: 11.0.3-2
pve-xtermjs: 6.0.0-2
qemu-server: 9.2.4
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.3-pve1

Den Rest probiere ich jetzt aus

BTW: Die Linux Platte ist kpl. hinüber, der e2fsck läuft ohne Fehler durch aber es passieren ganz komische Sachen - gerade ist ein apt update mit einem segfault gestorben
 
Ich habe jetzt wieder eine verschobene Disk hier und die Originale noch - wie könnte ich die beiden vergleichen, ob sie wirklich die gleichen Daten enthalten.
 
Last edited:
Hmm, so wirklich deuten kann ich das nicht. Müsste die LVM Disk nicht etwas größer sein?


Code: 
❯ SRC=/dev/zvol/rpool/vm-108-disk-2                                                                                                                                                                      14:47:42
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ DST=/dev/mapper/ME4_PVE_SSD_01_LVM-vm--108--disk--0                                                                                                                                                    14:47:54
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ blockdev --getsize64 $SRC                                                                                                                                                                              14:48:06
85899345920
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ blockdev --getsize64 $DST                                                                                                                                                                              14:48:11
85899345920
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ cmp $SRC $DST                                                                                                                                                                                          14:49:02
/dev/zvol/rpool/vm-108-disk-2 /dev/mapper/ME4_PVE_SSD_01_LVM-vm--108--disk--0 differ: byte 61443, line 225
 
Oh Oh :rolleyes:, könnten leere Bereiche in der Quelldisk evtl. alte Daten aus vorherigen gelöschten LVM Disks haben? Quasi werden beim Übertragen nur volle Bereiche geschrieben und leere Übersprungen - wenn jetzt in dem leeren Bereich noch alte Daten von gelöschten Disks liegen bleiben diese da und es sind Random-Daten in der neuen Disk?

Code: 
❯ OFF=61442                                                                                                                                                                                              15:00:26
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ echo "--- QUELLE ---"; dd if=$SRC bs=1M iflag=skip_bytes,count_bytes skip=$OFF count=4194304 2>/dev/null | xxd | head -30                                                                              15:00:39
--- QUELLE ---
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ echo "--- ZIEL ---";   dd if=$DST bs=1M iflag=skip_bytes,count_bytes skip=$OFF count=4194304 2>/dev/null | xxd | head -30                                                                              15:00:55
--- ZIEL ---
00000000: c303 3f67 6574 6c6f 6340 696f 735f 6261  ..?getloc@ios_ba
00000010: 7365 4073 7464 4040 5145 4241 3f41 566c  se@std@@QEBA?AVl
00000020: 6f63 616c 6540 3240 585a 0000 b701 3f5f  ocale@2@XZ....?_
00000030: 4765 7463 6174 403f 2463 7479 7065 4047  Getcat@?$ctype@G
00000040: 4073 7464 4040 5341 5f4b 5045 4150 4542  @std@@SA_KPEAPEB
00000050: 5666 6163 6574 406c 6f63 616c 6540 3240  Vfacet@locale@2@
00000060: 5045 4256 3432 4040 5a00 3905 3f77 6964  PEBV42@@Z.9.?wid
00000070: 656e 403f 2463 7479 7065 4047 4073 7464  en@?$ctype@G@std
00000080: 4040 5145 4241 4744 405a 0000 c805 5f57  @@QEBAGD@Z...._W
00000090: 6373 636f 6c6c 0000 0f02 3f5f 496e 6974  cscoll....?_Init
000000a0: 406c 6f63 616c 6540 7374 6440 4043 4150  @locale@std@@CAP
000000b0: 4541 565f 4c6f 6369 6d70 4031 3240 5f4e  EAV_Locimp@12@_N
000000c0: 405a 0000 cd03 3f69 6440 3f24 636f 6c6c  @Z....?id@?$coll
000000d0: 6174 6540 4740 7374 6440 4032 5630 6c6f  ate@G@std@@2V0lo
000000e0: 6361 6c65 4032 4041 0000 9102 3f5f 5872  cale@2@A....?_Xr
000000f0: 6567 6578 5f65 7272 6f72 4073 7464 4040  egex_error@std@@
00000100: 5941 5857 3465 7272 6f72 5f74 7970 6540  YAXW4error_type@
00000110: 7265 6765 785f 636f 6e73 7461 6e74 7340  regex_constants@
00000120: 3140 405a 0000 c905 5f57 6373 7866 726d  1@@Z...._Wcsxfrm
00000130: 0000 1205 3f74 6f6c 6f77 6572 403f 2463  ....?tolower@?$c
00000140: 7479 7065 4047 4073 7464 4040 5145 4241  type@G@std@@QEBA
00000150: 5045 4247 5045 4147 5045 4247 405a 0000  PEBGPEAGPEBG@Z..
00000160: 1105 3f74 6f6c 6f77 6572 403f 2463 7479  ..?tolower@?$cty
00000170: 7065 4047 4073 7464 4040 5145 4241 4747  pe@G@std@@QEBAGG
00000180: 405a 0000 1104 3f69 7340 3f24 6374 7970  @Z....?is@?$ctyp
00000190: 6540 4740 7374 6440 4051 4542 415f 4e46  e@G@std@@QEBA_NF
000001a0: 4740 5a00 ab00 3f3f 3166 6163 6574 406c  G@Z...??1facet@l
000001b0: 6f63 616c 6540 7374 6440 404d 4541 4140  ocale@std@@MEAA@
000001c0: 585a 0000 7500 3f3f 3066 6163 6574 406c  XZ..u.??0facet@l
000001d0: 6f63 616c 6540 7374 6440 4049 4541 4140  ocale@std@@IEAA@
 
aL1aL7 said:
Oh Oh :rolleyes:, könnten leere Bereiche in der Quelldisk evtl. alte Daten aus vorherigen gelöschten LVM Disks haben? Quasi werden beim Übertragen nur volle Bereiche geschrieben und leere Übersprungen - wenn jetzt in dem leeren Bereich noch alte Daten von gelöschten Disks liegen bleiben diese da und es sind Random-Daten in der neuen Disk?

Code: 
❯ OFF=61442                                                                                                                                                                                              15:00:26
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ echo "--- QUELLE ---"; dd if=$SRC bs=1M iflag=skip_bytes,count_bytes skip=$OFF count=4194304 2>/dev/null | xxd | head -30                                                                              15:00:39
--- QUELLE ---
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
❯ echo "--- ZIEL ---";   dd if=$DST bs=1M iflag=skip_bytes,count_bytes skip=$OFF count=4194304 2>/dev/null | xxd | head -30                                                                              15:00:55
--- ZIEL ---
00000000: c303 3f67 6574 6c6f 6340 696f 735f 6261  ..?getloc@ios_ba
00000010: 7365 4073 7464 4040 5145 4241 3f41 566c  se@std@@QEBA?AVl
00000020: 6f63 616c 6540 3240 585a 0000 b701 3f5f  ocale@2@XZ....?_
00000030: 4765 7463 6174 403f 2463 7479 7065 4047  Getcat@?$ctype@G
00000040: 4073 7464 4040 5341 5f4b 5045 4150 4542  @std@@SA_KPEAPEB
00000050: 5666 6163 6574 406c 6f63 616c 6540 3240  Vfacet@locale@2@
00000060: 5045 4256 3432 4040 5a00 3905 3f77 6964  PEBV42@@Z.9.?wid
00000070: 656e 403f 2463 7479 7065 4047 4073 7464  en@?$ctype@G@std
00000080: 4040 5145 4241 4744 405a 0000 c805 5f57  @@QEBAGD@Z...._W
00000090: 6373 636f 6c6c 0000 0f02 3f5f 496e 6974  cscoll....?_Init
000000a0: 406c 6f63 616c 6540 7374 6440 4043 4150  @locale@std@@CAP
000000b0: 4541 565f 4c6f 6369 6d70 4031 3240 5f4e  EAV_Locimp@12@_N
000000c0: 405a 0000 cd03 3f69 6440 3f24 636f 6c6c  @Z....?id@?$coll
000000d0: 6174 6540 4740 7374 6440 4032 5630 6c6f  ate@G@std@@2V0lo
000000e0: 6361 6c65 4032 4041 0000 9102 3f5f 5872  cale@2@A....?_Xr
000000f0: 6567 6578 5f65 7272 6f72 4073 7464 4040  egex_error@std@@
00000100: 5941 5857 3465 7272 6f72 5f74 7970 6540  YAXW4error_type@
00000110: 7265 6765 785f 636f 6e73 7461 6e74 7340  regex_constants@
00000120: 3140 405a 0000 c905 5f57 6373 7866 726d  1@@Z...._Wcsxfrm
00000130: 0000 1205 3f74 6f6c 6f77 6572 403f 2463  ....?tolower@?$c
00000140: 7479 7065 4047 4073 7464 4040 5145 4241  type@G@std@@QEBA
00000150: 5045 4247 5045 4147 5045 4247 405a 0000  PEBGPEAGPEBG@Z..
00000160: 1105 3f74 6f6c 6f77 6572 403f 2463 7479  ..?tolower@?$cty
00000170: 7065 4047 4073 7464 4040 5145 4241 4747  pe@G@std@@QEBAGG
00000180: 405a 0000 1104 3f69 7340 3f24 6374 7970  @Z....?is@?$ctyp
00000190: 6540 4740 7374 6440 4051 4542 415f 4e46  e@G@std@@QEBA_NF
000001a0: 4740 5a00 ab00 3f3f 3166 6163 6574 406c  G@Z...??1facet@l
000001b0: 6f63 616c 6540 7374 6440 404d 4541 4140  ocale@std@@MEAA@
000001c0: 585a 0000 7500 3f3f 3066 6163 6574 406c  XZ..u.??0facet@l
000001d0: 6f63 616c 6540 7374 6440 4049 4541 4140  ocale@std@@IEAA@
Click to expand...
Das kommt drauf an wie deine DELL ME4 konfiguriert ist. Warum hast du eigentlich 8 Pfade? Default und Empfehlung DELL sind 4 Pfade.
Nutzt du einen Thin Pool in der ME?
 
Wo steht dass Dell 4 Pfade empfiehlt? Das hätte ich nirgends gelesen. Hast Du hierzu einen Link?
Warum sollte der Fehler mit der Config vom Dell zu tun haben? Aber ja ist ein Thin-Pool. Wenn die VM läuft funktioniert der Move ja ohne Probleme, nur wenn die VM aus ist kommt es zu dem Fehler.
Man sieht auch im Task Log, dass Proxmox je nach VM Zustand den Move unterschiedlich macht.
Mein Problem ist anscheinend, dass ich den Default für saferemove auf 0 gelassen habe und deshalb Daten von gelöschten Disks an den eigentlich leeren Stellen der neuen Disk habe.
 
aL1aL7 said:
Wo steht dass Dell 4 Pfade empfiehlt? Das hätte ich nirgends gelesen.
Click to expand...
Das ist schon ewig so, aber kann auch sein, dass die Empfehlung wegen ESXi war, weil der Probleme bekommt bei zu vielen Pfaden.
aL1aL7 said:
Hast Du hierzu einen Link?
Warum sollte der Fehler mit der Config vom Dell zu tun haben? Aber ja ist ein Thin-Pool. Wenn die VM läuft funktioniert der Move ja ohne Probleme, nur wenn die VM aus ist kommt es zu dem Fehler.
Man sieht auch im Task Log, dass Proxmox je nach VM Zustand den Move unterschiedlich macht.
Mein Problem ist anscheinend, dass ich den Default für saferemove auf 0 gelassen habe und deshalb Daten von gelöschten Disks an den eigentlich leeren Stellen der neuen Disk habe.
Click to expand...
Beim Thin Pool sollte eigentlich die ME gelöschte Daten immer ausnullen. Da darf es eigentlich nicht dazu kommen, dass du alte Daten siehst. Bei klassischem RAID könnte das theoretisch auftreten.
 
Nach meinem Verständnis, weiß die ME gar nix davon, dass die Daten gelöscht werden können so lange saferemove auf 0 steht - da wird doch nur das LV aufgelöst aber die Daten nicht gelöscht + das würde mit saferemove 1 passieren.
Kann aber sein, dass ich gerade einen Gedankenknoten habe.

Imho müsste beim Move im ausgeschalteten VM Zustand dafür gesorgt werden, dass die neu angelegte Disk kpl. genullt angelegt wird.
 
Ich weiß nicht wo du saferemove konfigurierst.
Wenn Discard gesetzt ist, bekommt die ME das mit, wenn gelöscht wird. Sonst geht die immer davon aus, dass die Daten noch genutzt werden und hängt hinten an.
Ich habe noch nie eine VM offline migriert, daher kann ich auch nicht sagen ob da etwas schief laufen könnte. Online hatte ich noch nie Probleme.
Du kannst das gern testen und eventuell ist das nicht nur ein Thema für Proxmox, eventuell läuft auch was im Storage schief.
 
Das saferemove ist der Haken beim Storage "Daten sicher löschen" - weiß jetzt die genaue Bezeichnung der UI nicht, aber Du findest die Option dann in der Storage Konfiguration.

Das Discard bei der Disk ist ja eine Stufe darunter, das betrifft ja Daten innerhalb einer Disk die gelöscht werden. Das saferemove bezieht sich auf kpl. Disks die auf einem LVM gelöscht werden

BTW: Habe heute noch ein paar Disks von laufenden VM's verschoben - alles stressfrei
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back