VM MoRef IDs neu zuordnen zu bestehenden  Veeam Backup Restorepoints

In diesem Beitrag werde ich zeigen, wie man das Veeam Migration Utility einsetzen kann, falls man einen ganzen Cluster auf ein neues vCenter umziehen muss und die bestehenden Backup-Ketten dabei erhalten bleiben müssen.

The Good

Das Upgrade einer vCenter Appliance (VCSA) wurde in jüngster Zeit immer weiter vereinfacht. Man muss nur den Wizard starten und ihm das alte vCenter zeigen. Dank der VMware Entwickler wurde das zu einem “Next-Next-Finish” Upgrade. Am Ende stand einen neues vCenter mit den gleichen Einstellungen, der selben IP und (falls gewünscht) mit historischen Logdaten. Das ist großartig! Ich kann mich da noch an vCenter Upgrades auf Windows erinnern die ein PITA waren.

The Bad

Es gibt seltene (und hässliche) Situationen, in denen man den Wizard nicht nutzen kann und man die Hosts auf ein komplett neues vCenter übertragen muss – ohne Migration der Einstellungen. In solchen Fällen muss man alles von Hand nachbauen. Jedes Datacenter, jeden Cluster, jeden Ordner, jeden Pool, alle Gruppen, Regeln usw.

Wer sich jetzt fragt, warum zum Teufel hat er nicht diesen wundervollen Wizard verwendet? Nun, in diesem speziellen Fall musste die IP Adresse des vCenter verändert werden. Im Prinzip ist das kein Hindernis.  Man kann diese in neueren Versionen aus der GUI, oder über schmutzige Tricks verändern. Aber es gibt eine Ausnahme: Wenn jemand in der tiefen Vergangenheit entschied, dem vCenter anstatt eines Hostnamens, nur eine IP zu geben, kann diese nicht mehr verändert werden. Sie fungiert dann als einzigartige ID und bleibt für immer. Die einzige Chance dem Dillemma zu entkommen, ist in den sauren Apfel zu beißen und ein komplett neues vCenter aufzubauen. Man vergibt diesem einen echten Hostnamen und migriert alle Hosts auf dieses neue vCenter. Das ist eine Menge Arbeit und so kann man bei der Gelegenheit auch gleich auf die neueste vCenter Version upgraden.

Wir migrierten in diesem Szenario von VCSA 6.0 auf VCSSA 6.7. Zusätzlich mussten wir vShield loswerden, das ein Teil von vCloud Networking and Security (vCNS) ist und unter vCenter  6.5 und später nicht mehr unterstützt wird. Vergleiche hierzu meinen Post “vShield zu NSX Migration“.

ESX Hosts unter Last migrieren

Eine kalte Migration kam in dem beschriebenen Fall nicht in Frage, also mussten wir den Host unter vollen Segeln zum neuen vCenter migrieren. Dazu mussten alle Einstellungen am neuen VC analog zum alten angepasst werden. HA und DRS musste im alten vCenter deaktiviert werden. Der Host wird getrennt und tritt dem neuen vCenter bei. Dabei überträgt der ESX Host seine Lizenz ins neue vCenter. Man stimmt dem Lizenzimport zu und verwendet sie weiterhin für den Host. Diese Prozedur muss Host-für-Host wiederholt werden.

Nach einer Menge Arbeit sind hoffentlich alle Hosts im neuen vCenter angekommen. Zeit für ein Feierabend-Bier? Leider nein!

The Ugly

Sobald ein Host mit VMs in einem neuen vCenter registriert wird, erhalten alle VMs eine neue MoRefID (Managed Object Reference ID), die in diesem vCenter einzigartig ist. Es gibt zum Thema einen älteren Blogpost von William Lam über Managed Object Reference IDs.

Worin besteht das Problem?

Wer eine Backuplösung wie z.B. Veeam Backup & Replication einsetzt, hat sicher großes Interesse daran, daß die Backup-Ketten bisheriger Sicherungen mit den neuen MoRef IDs übereinstimmen. MoRef IDs für die Identifikation einer VM zu verwenden ist sicher eine gute Idee, denn VM Namen können sich mit der Zeit ändern. Eine VM mit dem Namen “Exchange2016_Migration” könnte zu einem späteren Zeitpunkt in “ExchangeEMEA” umbenannt werden. Tritt man jedoch einem neuen vCenter bei, werden alle Sicherungspunkte abgeschnitten und der Backupauftrag findet das VM Objekt nicht mehr. Aber  selbst wenn man im Auftrag das alte VM Objekt entfernt und gegen das analoge neue ersetzt, kann Veeam die Verbindung zur bestehenden Backup-Kette nicht mehr herstellen, denn die VM hat jetzt eine abweichende MoRef ID.

Natürlich kann man die alten Backup Ketten abschneiden und mit den neuen IDs ein neues Backup aufbauen, aber dafür benötigt man ausreichend Platz auf dem Backupspeicher und ein entsprechend großes Zeitfenster, um beim nächsten Lauf ein Vollbackup zu fahren. alte Backup-Ketten löschen um Platz zu gewinnen ist keine Option. Schachmatt? Nicht unbedingt, denn es gibt Hilfe. Auf der nächsten Seite wird erklärt, wie es funktioniert.