Migration von ESXI 6.0 nach PVE mit Fehlern

S

schloegel-edv

Member
Mar 23, 2020
70
4
13
42
Hallo,

ich habe eine Migration von ESxI 6.0 nach PVE machen wollen. Ich habe mich an die hier im Forum gepostete ToDo gehalten. Als NFN Speicher habe ich ebenfalls ein NAS verwendet. Alles Konfigurationen wurden auf einer Test-PVE Maschine gemacht. Danach starteten alle Maschinen auch korrekt. Die IP Adressen mussten lediglich angepasst werden. Anschließend installierte ich die virt-IO Treiber. Auch hier funktionierte alles. Nun habe ich die Platten auf einen internen ZFS Speicher verschoben, um Platz auf dem NAS für Backups zu machen. Und nun wurde von allen Maschinen ein Backup über PVE mit Ziel NFN- NAS gemacht. Als letztes wurden die Backups auf der echten PVE Maschine wieder zurück gespielt. Nur leider starteten einige Maschinen nun nicht mehr. Vermutlich bei allen Maschinen mit mehr als 1 Laufwerken trat das Problem auf. Als ich weiter geprüft habe, habe ich festgestellt, dass die selben Maschinen auf dem Test-PVE ebenfalls nicht mehr funktionierten. Das hatte ich nach dem Verschieben und vor dem Backup nämlich nicht noch einmal getetstet. Es muss also etwas mit dem "Verschieben" auf den anderen Speicher zu tun haben. Kann mir da jeman helfen?

Viele Grüße.

PS: hätte ich das in den genannten Thread posten müssen? Dann bitte verschieben.
 
Nur um das zu verstehen, es wurde eine VM auf PVE migriert.
Diese hat im Anschluss einwandfrei funktioniert, und es wurde das NFN-NAS als Diskstorage verwendet?
Anschließend wurden Backups ebenfalls auf NFN-NAS gemacht und diese auf einem anderen PVE restored? Ab da liefen die VMs nicht mehr?
Und im Anschluss lief auch die ursprüngliche VM nicht mehr? Oder nur die VMs die vom Backup wiederhergestellt wurden?

Bitte auch den Output von pveversion -v, cat /etc/pve/storage.cfg und qm config <VMID> posten.
<VMID> mit der entsprechenden VM ID ersetzen, wo es ursprünglich funktionierte und im Anschluss nicht mehr.
 
mira said:
Nur um das zu verstehen, es wurde eine VM auf PVE migriert.
Click to expand...
ja, mehrere VMs wurden zu PVE migriert.
mira said:
Diese hat im Anschluss einwandfrei funktioniert, und es wurde das NFN-NAS als Diskstorage verwendet?
Click to expand...
ja.

Da das NAS nicht genügend freien Speicher für das anschließende Backup hatte, wurden die Laufwerke aller VMs von diesem PVE anschließend auf einen internen ZFS verschoben.
mira said:
Anschließend wurden Backups ebenfalls auf NFN-NAS gemacht und diese auf einem anderen PVE restored? Ab da liefen die VMs nicht mehr?
Click to expand...
Das stimmt so. Vermutlich liefen die Maschinen nicht mehr, nachdem die Laufwerke auf das ZFS verschoben wurden. Ich hatte das aber nach dem Verschieben nicht mehr getestet, weil es noch nie durch das Verschieben von Laufwerken Probleme gab. Dem muss aber so sein. Denn nachdem Restore der VMs auf das endgültige PVE habe ich das erst geprüft und musste feststellen, dass nun auch die urspünglichen VMs des Interims PVE nicht mehr liefen. Ich hab sozusagen den Fehler mit gebackupt und wieder mit recovered.

mira said:
Bitte auch den Output von pveversion -v, cat /etc/pve/storage.cfg und qm config <VMID> posten.
<VMID> mit der entsprechenden VM ID ersetzen, wo es ursprünglich funktionierte und im Anschluss nicht mehr.
Click to expand...
Code: 
root@pve:~# pveversion -v
proxmox-ve: 7.0-2 (running kernel: 5.11.22-4-pve)
pve-manager: 7.0-11 (running version: 7.0-11/63d82f4e)
pve-kernel-5.11: 7.0-7
pve-kernel-helper: 7.0-7
pve-kernel-5.11.22-4-pve: 5.11.22-8
ceph-fuse: 15.2.14-pve1
corosync: 3.1.2-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.21-pve1
libproxmox-acme-perl: 1.3.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.0-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-6
libpve-guest-common-perl: 4.0-2
libpve-http-server-perl: 4.0-2
libpve-storage-perl: 7.0-10
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.0.9-2
proxmox-backup-file-restore: 2.0.9-2
proxmox-mini-journalreader: 1.2-1
proxmox-widget-toolkit: 3.3-6
pve-cluster: 7.0-3
pve-container: 4.0-9
pve-docs: 7.0-5
pve-edk2-firmware: 3.20200531-1
pve-firewall: 4.2-2
pve-firmware: 3.3-1
pve-ha-manager: 3.3-1
pve-i18n: 2.5-1
pve-qemu-kvm: 6.0.0-3
pve-xtermjs: 4.12.0-1
qemu-server: 7.0-13
smartmontools: 7.2-1
spiceterm: 3.2-2
vncterm: 1.7-1
zfsutils-linux: 2.0.5-pve1
root@pve:~#

Code: 
root@pve:~# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content iso,backup,vztmpl

lvmthin: local-lvm
        thinpool data
        vgname pve
        content rootdir,images

zfspool: ZFS-DATA
        pool ZFS-DATA
        content rootdir,images
        mountpoint /ZFS-DATA
        nodes pve

nfs: NAS-NFS
        export /TEMP_PVE
        path /mnt/pve/NAS-NFS
        server 192.168.2.47
        content images,backup
        prune-backups keep-all=1

Ich weiß nicht, ob das sinnvoll ist, die Config einer der 6 Maschinen zu posten, da diese durch mich auf Grund des Herumprobierens und Suchen nach Lösungen x-Mal verändert wurden.
 
Endlosschleifen beim Booten mit Windowsmaschinen (Server 2019), auf Linux Maschinen wurden die Laufwerke vermutlich so verändert, dass diese in den Notstart liefen (hier muss ich dazu sagen, dass ich vermutlich zu wenig Linux-Erfahrung habe, um das zu korrigieren). Hatte dann mittels Diskpart usw. bei den Windowsmaschinen getestet, da ich erst dachte, dass die Startpartitionen nicht aktiv sind. Unter Server 2012 R2 kam auch die Meldung, dass Windows nicht gestartet werden könnte und ging in den Reparaturmodus.

Aber wie gesagt, alle Maschinen liefen ja bereits vor dem Verschieben auf den anderen Store. Eventuell hat es damit zu tun, dass die Raw Files beim Verschieben in qcow2 umgewandelt wurden? Aber man konnte da ja nichts einstellen.
 
Meiner Meinung nach sollte es keinen Probleme geben, wenn du die virtuellen Disks hin und her schiebst.
Du hast erwähnt, dass du nach der Inbetriebnahme der neuen Produktionsumgebung ein Backup & Restore durchgeführt hast und es scheitern nur jene VMs > 1 Platte - richtig?

Hast du in der jeweiligen VM Configuration auch die andere Festplatten entsprechend als "backup-bar" markiert?
 
Du könntest noch versuchen, dass du die VM platten zurückschiebst und das ursprüngliche Format (raw) auswählst, ob die dann eventuell booten?
 
Ich muss mich nochmal melden, weil das Problem für mich noch nicht geklärt ist. Es war tatsächlich nur bei allen VMs mit mehr als einer Platte. Warum könnte denn das so sein? Wenn ich die Migration wiederhole, möchte ich diese Probleme nicht unbedingt wieder haben.
 
Hier wären die genauen Schritte, die VM Configs (qm config <VMID>, die Storage Config (/etc/pve/storage.cfg) und auch die Task Logs (GUI -> Doppelklick unten auf die Tasks) interessant.
 
Die genauen Schritte wurden von mir ja bereits beschrieben. Wie ich schon schrieb, sind die Konfigurationen inzwischen mehrfach verändert worden, bzw. teilweise komplett gelöscht worden, weil ich nach Lösungen gesucht hatte. Letztlich musste ich den Originalzustand (wie vor der Migration) wieder herstellen, da ja wieder gearbeitet werden musste. Also habe ich nur die Chance, alles nochmals durchzuführen und wieder auf diese Probleme zu treffen? Dann scheint das in meinem Fall ja tatsächlich das erste Mal so passiert zu sein.
 
Wichtig beim Backup ist, das für jede VM auch alles "Festplatten" im Backup mit drin sind.
Das prüfst du vor dem Backup in der Hardware-Config der jeweiligen "Festplatte".
Dann achte darauf, dass alle Platten einer VM auch auf dem selben Storage liegen.
Prizipiell ist das nicht wichtig, kann aber Timingprobleme bringen.
Und ändere möglichst wenig händisch an den Config's der VM's.
 
Mal ein anderer Ansatz, du spielst ja immer ein Backup zurück. Ich habe meine Migrationen zu PVE von den original VMs gemacht. Ich habe die VMs auf einen NFS Share geschoben. Danach habe ich den NFS Share an PVE gegeben. VM runter gefahren und die VMDK dann auf cli zu qcow konvertiert.. Somit bleibt die orignal VM im notfall startbar und du hast garantiert den originalzustand migriert.

Gruß Falk
 
nicht ganz. Ich hatte die Original vmdk´s auf den NFS-Share kopiert und wie beschrieben in die Maschinen aufgenommen (ein interims PVE bestehend aus neuer Hardware, es ist der zukünftiger Proxmox-Backupserver) und dann dort nach qcow kopiert (ZFS-Store intern).

Der originale ESXi Server wurde dann gelöscht. Alle Platten neu eingerichtet und ein PVE aufgespielt. Auf dieses PVE wurden die Backups zurück gespielt. Wie hätte ich sonst das PVE auf den vorhandenen Server mirgrieren sollen?

Oder ich hätte auch den ESXi nach dem Kopieren der vmdk´s auf den NFS-Share gleich platt machen können. Aber ich wollte eben erst ein funktionierendes System haben.
 
Last edited:
OK, da ich zwei Server habe, konnte ich erst einen neu machen und den alten original lassen. Ich kann mir aber auch nicht richtig erklären wieso die Windows Gäste solche Probleme machen. Migrationen zwischen Physik, ESXi & HyperV mache ich in der Regel mit Veeam, da kann man immer schön hin und her. ;) Die Migration mit Veeam Backup zu PVE geht zwar auch, über ein Bare Metal Recovery in eine neue VM. Das ist zwar etwas aufwändiger, aber in der Regel funktioniert Windows dann immer korrekt.
 
schloegel-edv said:
nicht ganz. Ich hatte die Original vmdk´s auf den NFS-Share kopiert und wie beschrieben in die Maschinen aufgenommen (ein interims PVE bestehend aus neuer Hardware, es ist der zukünftiger Proxmox-Backupserver) und dann dort nach qcow kopiert (ZFS-Store intern).

Der originale ESXi Server wurde dann gelöscht. Alle Platten neu eingerichtet und ein PVE aufgespielt. Auf dieses PVE wurden die Backups zurück gespielt. Wie hätte ich sonst das PVE auf den vorhandenen Server mirgrieren sollen?

Oder ich hätte auch den ESXi nach dem Kopieren der vmdk´s auf den NFS-Share gleich platt machen können. Aber ich wollte eben erst ein funktionierendes System haben.
Click to expand...
Also war dein Weg:

ESXI -> vmdk-Platten -> NFS -> eingebunden in die PVE-VM's?

Wenn ja, liefen die VM's in dem Stadium? Wenn ich dich richtig verstanden habe, ja?

Danach NFS -> vmdk-Platten -> ZFS inkl. Konversion qcow2 lokal auf den PVE?

Nun Backups der PVE-VM's erstellt, ohne vorher die VM's zu testen?

Nach dem Restore traten die Probleme auf?

Hast du mal z.B. mit einer gparted.iso eine der VM's gebootet um zu schauen, ob alles da ist?

Evtl. stimmt auch die Reihenfolge der vmdk's/ jetzt qcow Platten nicht mehr?
 
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