VM Disks lokalisieren aus einem RBD Pool
- Thread starter ferhat.oekten
- Start date
Danke, aber so bekomme ich die config nur zur sicht. Ich brauche die *.raw Dateien aus dem Pool, um die zu kopieren.
Code:
rbd -p {pool} ls
rbd -p {pool} export {image} /path/to/file.raw
Ich versuche es gerade mit:
qm disk import <vmid> <pfad/von/datei> <storage-id> --format raw
Scheint etwas langsam zu sein. Ist aber dennoch ok.
Eine andere Idee bzw. Möglichkeit?
qm disk import <vmid> <pfad/von/datei> <storage-id> --format raw
Scheint etwas langsam zu sein. Ist aber dennoch ok.
Eine andere Idee bzw. Möglichkeit?
Wenn die CPUs kompatibel sind geht das auch im laufenden Betrieb mit qm remotemigrate.
Notfalls im ausgeschalteten Zustand.
Notfalls im ausgeschalteten Zustand.
Ach ja, wenn die Cluster weit entfernt sind und keine LAN Verbindung da ist, dann lieber per Backup (VZ Dump) auf USB und am Zielcluster Restore. Geht schneller da die Daten komprimiert werden.
CPU's sind leider nicht kompatibel. Da Plattengröße über 3 TB, hat beim Test über 12h gedauert. Die Ausfallzeit ist leider nicht akzeptabel. Backup's über VZ Dump werden immer als Vollbackup durchgeführt. Das ist eins von vielen Problemen...
Wenn du eine Disk exportierst und wieder importierst, hast du ja viel mehr Downtime.
In wie weit sind dei CPUs nicht Kompatibel? Wechselst du von Intel auf AMD oder gehst du auf ältere CPUs? Wenn du von alten Intel auf neuere Intel migrierst, geht das auch im laufenden Betrieb, außer du hast auf den neueren Features deaktiviert, die auf den alten aktiv sind.
In wie weit sind dei CPUs nicht Kompatibel? Wechselst du von Intel auf AMD oder gehst du auf ältere CPUs? Wenn du von alten Intel auf neuere Intel migrierst, geht das auch im laufenden Betrieb, außer du hast auf den neueren Features deaktiviert, die auf den alten aktiv sind.
Wenn es kürzer sein soll und eine live-migration keine option ist, evtl. mit 2 PBS Instanzen?
Lokaler PBS -> remote sync. Im Hntergrund laufen lassen, bis ein manueller Remote Sync zur neuen Location direkt nach einem Backup in akzeptabler Zeit fertig ist.
Auf der Quell VM alle Dienste Stoppen, sodass keine wichtigen Daten mehr dazu kommen. Ein letztes Backup im laufenden Betrieb machen (fast incremental backup). Danach die Quell VM stoppen/killen.
Dann sofort den remote sync starten und wenn der fertig ist, am Zielsystem einen Live-Restore machen.
Dadurch sollte die Downtime recht kurz werden. Live-restore ist aber nur eine Option, wenn die 3TB primär Archivdaten sind und nicht dauernd hinten und vorne geschrieben wird. Ansonsten wird die VM während des Restores mitunter zu langsam reagieren.
Lokaler PBS -> remote sync. Im Hntergrund laufen lassen, bis ein manueller Remote Sync zur neuen Location direkt nach einem Backup in akzeptabler Zeit fertig ist.
Auf der Quell VM alle Dienste Stoppen, sodass keine wichtigen Daten mehr dazu kommen. Ein letztes Backup im laufenden Betrieb machen (fast incremental backup). Danach die Quell VM stoppen/killen.
Dann sofort den remote sync starten und wenn der fertig ist, am Zielsystem einen Live-Restore machen.
Dadurch sollte die Downtime recht kurz werden. Live-restore ist aber nur eine Option, wenn die 3TB primär Archivdaten sind und nicht dauernd hinten und vorne geschrieben wird. Ansonsten wird die VM während des Restores mitunter zu langsam reagieren.
Last edited:
Die Idee ist sehr gut, jedoch ist es eine VM, auf der mindestens 30 User an einem Samstag Abend zugreifen werden und Daten ablegen und darauf zugreifen. An anderen Tagen ist die VM noch mehr beschäftigt. Es ist eine Windows Maschine worauf Applikationen laufen, die von einer Fremdfirma gewartet wird und auf der wir sehr begrenzten Zugriff haben. Das macht es leider nicht einfach.
Gerade dann würde ich mal prüfen ob Live Migration geht. Wenn du uns die CPU Modelle nennst, kann ich dir schon sagen ob es Showstopper gibt.
Das mit den 2 PBS geht auch, aber da kann die Performance schon etwas leiden. Kommt natürlich auf die PBS Hardware an.
Das mit den 2 PBS geht auch, aber da kann die Performance schon etwas leiden. Kommt natürlich auf die PBS Hardware an.
Lieber Falk, wie schon erwähnt soll die VM von einem Cluster auf einem anderen Cluster. Wie soll eine Migration so funktionieren?
Performance ist wichtig. Die User müssen flüssig arbeiten können. Daher ist eine Downtime besser, die wir versuchen werdenso kurz wie möglich zu halten.
Performance ist wichtig. Die User müssen flüssig arbeiten können. Daher ist eine Downtime besser, die wir versuchen werdenso kurz wie möglich zu halten.
Deshalb ja unsere Vorschläge. Wenn du vernünftiges Netzwerk hast, kannst du mit
https://pve.proxmox.com/pve-docs/qm.1.html
qm remote-migrate auch Live zwischen verschiedenen Clustern migrieren.https://pve.proxmox.com/pve-docs/qm.1.html
Ja, das Feature ist seit PVE7 als experimental gekennzeichnet. Funktioniert aber wunderbar. Bei allem was experimental gekennzeichnet ist, sollte man vorher mit einer unwichtigen VM testen.