Wie VMs migrieren auf neuen Proxmox Knoten

[pleibling]

Hallo zusammen,

ich migriere derzeit meinen ESXI zu Proxmox - mittlerweile habe ich einen temporären Proxmox 8.1 installiert und auch schon alle VMs von ESXI zu Proxmox migriert - mittels scp und vm importdisk.

Alle VMs laufen nun auf dem temporären Proxmox Server und meinen alten ESXI habe ich mittlerweile auch schon auf Proxmox 8.1 installiert.

Nun müssen alle laufenden VMs vom temporären Server auf den Ziel Server - der bisherige Weg ist mir zu aufwendig, ich hoffe das es einen einfacheren Weg gibt.

Alternativ hätte ich die Idee einen temporären Cluster zu erstellen aus den beiden Servern und später wieder aufzulösen - deshalb ein paar Fragen:

a) Mache ich es mir zu kompliziert und es geht viel einfacher? Wenn ja, wie?
b) Wenn ich einen Cluster erstelle und beide Knoten hinzufüge - können die schon jeweils beide Vms haben oder müssen die beide leer sein oder zumindest der master/slave?

Danke vielmals für eure Unterstützung - habt noch einen schönen ersten Advent.

 

[Dunuin]

b) Wenn ich einen Cluster erstelle und beide Knoten hinzufüge - können die schon jeweils beide Vms haben oder müssen die beide leer sein oder zumindest der master/slave?

Knoten die du zum Cluster hinzufügst müssen leer sein: https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_join_node_to_cluster

Außerdem nicht vergessen, dass das mit 2 Nodes nicht stabil läuft und du tricksen musst.

a) Mache ich es mir zu kompliziert und es geht viel einfacher? Wenn ja, wie?

Es gibt seit PVE 8.0 auch Cross-Cluster Migration als Feature Preview, dass man da nicht einmal beide Server im Cluster haben müsste:

qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS]
Migrate virtual machine to a remote cluster. Creates a new migration task. EXPERIMENTAL feature!
<vmid>: <integer> (100 - 999999999)
The (unique) ID of the VM.
<target-vmid>: <integer> (100 - 999999999)
The (unique) ID of the VM.
<target-endpoint>: apitoken=<A full Proxmox API token including the secret value.> ,host=<Remote Proxmox hostname or IP> [,fingerprint=<Remote host's certificate fingerprint, if not trusted by system store.>] [,port=<integer>]
Remote target endpoint
--bwlimit <integer> (0 - N) (default =migrate limit from datacenter or storage config)
Override I/O bandwidth limit (in KiB/s).
--delete <boolean> (default =0)
Delete the original VM and related data after successful migration. By default the original VM is kept on the source cluster in a stopped state.
--online <boolean>
Use online/live migration if VM is running. Ignored if VM is stopped.
--target-bridge <string>
Mapping from source to target bridges. Providing only a single bridge ID maps all source bridges to that bridge. Providing the special value 1 will map each source bridge to itself.
--target-storage <string>
Mapping from source to target storages. Providing only a single storage ID maps all source storages to that storage. Providing the special value 1 will map each source storage to itself.

Backup+Restore ist natürlich auch eine Option, gerade mit PBS mit den inkrementellen Backups und Live-Restore, wo sich die Downtime dann n Grenzen hält.

 

[pleibling]

Danke für deine schnelle Antwort, das Cluster hätte ich nur temporär betrieben und danach auch wieder entfernt - deshalb hätte ich auch die kurze Phase auch ohne Qurum- Node / -Device gearbeitet. Aber leerer Knoten ist schon wieder ein KO Kriterium.

Ein experimentelles Feature möchte ich erst mal nicht nutzen.

Backup und Restore hatte ich eigentlich ausgeschlossen, wegen der Downtime (4 VMs sind zwischen 0.5 - 1 TB groß). Aber Live Restore klingt interessant - ich schau mir das mal an. Wenn ich es richtig verstehe, dann ist es einfach wie folgt:

• Backup der VM online
• Herunterfahren VM
• Letztes inkrementielles Backup
• Restore auf dem anderen Host

Habe ich das so richtig verstanden?

Eigentlich hatte ich mir die ganze Umstellung einfacher vorgestellt - aber ich habe schon einen Abend verloren, wegen der 10 GBit Fiber Netzwerkkarte, die ich nicht zum laufen bringe (entweder hängt es bei initialise ramdisk oder aber startet und ist danach instabil). Aber das schaue ich mir später an - ich migriere jetzt erst mal über Gigabit und schaue später noch mal nach einer anderen Karte (10 GBit Fiber oder Kupfer - zur Not brauche ich nur ein 10 GBit Kupfer Gbic).

Danke noch mal für deine Unterstützung.

 

[Dunuin]

• Backup der VM online
• Herunterfahren VM
• Letztes inkrementielles Backup
• Restore auf dem anderen Host

Habe ich das so richtig verstanden?

Genau, und beim Restore vom PBS dann nicht vergessen die "Live Restore" Checkbox zu setzen.

 

[pleibling]

Klingt gut, schaue ich mir gleich an - installiere schon. mal einen temporären PBS nur für die Migration, später kommt der eigentliche PBS bei uns ins Rechenzentrum, da habe ich auch schon eine interessante Idee, von der ich gespannt bin, ob diese so funktioniert wie ich mir die vorstelle - aber dazu mache ich einen eigenen Thread auf.

Danke noch mal für deine schnelle Unterstützung.

 

[Falk R.]

Ein experimentelles Feature möchte ich erst mal nicht nutzen.

Das kann man aber locker nutzen, Im Enterprise Umfeld wo es 0 Downtime geben darf, da würde ich es eventuell noch nicht einsetzen.

 

[sb-jw]

Folgendes sollte man bei live-restore aber nicht vergessen:

Note that this comes with two caveats:

    During live-restore, the VM will operate with limited disk read speeds, as data has to be loaded from the backup server (once loaded, it is immediately available on the destination storage however, so accessing data twice only incurs the penalty the first time). Write speeds are largely unaffected.

    If the live-restore fails for any reason, the VM will be left in an undefined state - that is, not all data might have been copied from the backup, and it is most likely not possible to keep any data that was written during the failed restore operation.

Quelle: https://pve.proxmox.com/wiki/Backup_and_Restore#vzdump_restore

Letztlich ist es also quasi egal ob man ein experimentelles Feature nutzt oder Live-Restore, geht etwas schief, kann es den Datenverlust zur Folge haben. Wenn du es also wirklich sicher haben willst, dann musst du die VM vorher abschalten und erst dann migrieren. Damit hast du immer eine saubere Quelle und es ist egal ob zwischendurch was abbricht.

Wenn du den PBS nicht mit 4x HDDs mit 5400 RPM betreibst, sondern mit SSDs (wie es auch empfohlen wird) wird dein Restore sicherlich auch kein Thema sein. Vielleicht kannst du auch einfach alle nacheinander machen, dann ist nicht alles weg und der einzelne Server geht schneller weil eben die gesamte Performance für den einen Restore da ist.

 

[pleibling]

Danke für eure zahlreichen Hinweise. Denn Hinweis hatte ich auch gesehen und dann Offline migriert - dennoch habe ich mir ein paar VMs geschossen, denke aber das ich über einen Anfängerfehler gestolpert bin. Ich hatte bei den VMs nicht auf eindeutige IDs geachtet, und zwei Hosts gehabt, somit wurden wahrscheinlich die VMs gemischt. Aber da ich den Fehler gesehen habe, setze ich noch mal einen neuen Backupserver auf und mache nur Backups vom alten Host und achte auf die IDs. Somit alles gut.Gehört halt zum lernen dazu.

 

[Falk R.]

Dafür gibts ja extra Namespaces im PBS. Steht ja auch im Wiki beschrieben

 

[pleibling]

Und wieder was gelernt. Danke für den Hinweis.