Es gibt eine ganze Reihe von Situationen, in denen man auf ein (komplettes) Backup einer unter VMware installierten Gastmaschine zurückgreifen möchte:

• Updates/Upgrades: Oft genug verursachen ureigenste Updates des Betriebssystem-Herstellers oder aber bestimmter Programm-Suites erhebliche Probleme. Das gilt für Windows-Systeme in besonderem Maße. OK – es gibt die Wiederherstellungspunkte unter Windows selbst. Um die nutzen zu können, muss das System aber noch lauffähig sein.
• Fehler von Benutzern mit Admin-Rechten: Wiederherstellungspunkte schützen nicht vor bestimmten gravierenden Fehlern von Anwendern mit hohen Berechtigungen auf dem VMware-Host wie auf der VMware-Gast-Maschine – echte Backups sind grundsätzlich unerlässlich.
• Änderungen an der HW-Ausstattung der virtuellen Maschine: Für Performance-Tests möchte man ggf. mit der HW-Ausstattung der virtuellen Maschine experimentieren. HW-Änderungen sind oft auch im Zusammenhang mit VMware-Upgrades angebracht.
• Pentests: Eine ganz eigene Klasse von Systemmanipulationen entsteht zudem im Zuge von Tests in einem Pentest-Labor: je nachdem, mit welchen Angriffsvektoren man sich da auseinandersetzt, kann das Ziel-System, also das VMware-Gastsystem, so in Mitleidenschaft gezogen werden, dass es danach schlicht nicht mehr funktionstüchtig ist.

Für all diese Situationen muss man vorausschauend planen. VMware bietet natürlich einen Snapshot-Mechanismus zur Fixierung des Zustands einer virtuellen Maschine an. Das schützt einen aber nicht vor Fehlern oder Ausfällen auf dem Virtualisierungshost selbst. Zudem muss man die Snapshot-Strategie konsequent anwenden; das erfordert in manchen Situationen einen erheblichen zusätzlichen Speicherplatz auf den Festplatten des Virtualisierungshosts und führt ggf. zudem systematisch zu Performance-Einbußen.

Meine Strategie ist grundsätzlich die, von wichtigen produktiven VMware-Installationen unter Linux zusätzlich zu Snapshots regelmäßig Kopien der gesamten Maschine anzufertigen und auf Partitionen externer Backup-Systemen zu verschieben. Mit Kopien meine ich echte Linux-Kopien der einer virtuellen Maschine im Linux-System zugeordneten Definitions- und virtuellen Hard-Disk-Dateien (cp -dpRv bzgl. der zu einer Maschine gehörigen .vcmx-, .vmxf-, .vmsd, .nvram-, .vmdk-Dateien). Von der vmx-Datei lege ich vorsorglich eine zweite Kopie (unter anderem Namen) an. Warum wird aus dem folgenden Text erkenntlich werden.

Nun ist ja bekannt, dass MS mit Windows vor allem Geld verdienen will. Intern überwacht das System daher Zustände und Veränderungen der (z.T. virtuellen) HW sowie anderer Parameter, die auf eine Veränderung der Systemumgebung hindeuten. Glaubt Windows bzw. Microsoft, dass solche Veränderungen einer Lizenzverletzung entsprechen, muss eine neue Aktivierung des Betriebssystems vorgenommen werden. Je nach Lizenzeinschränkungen kann das natürlich schiefgehen – im Besonderen, wenn Reaktivierungen in relativ kurzen Zeitabständen vorgenommen werden oder z.B. eine OEM-Lizenz plötzlich einer aus MS-Sicht neuen PC-Plattform zugeordnet wird.

Das Dumme ist, dass gerade Änderungen der HW-Ausstattung einer virtuellen Maschine (s. den obigen Punkt 3), die völlig legal erfolgen, aus Microsoft-Sicht böse sein können. Bestimmte Änderungen der (virtuellen) HW-Ausstattung werden von MS einfach mal so interpretiert, als habe man die zugrunde liegende PC-Plattform gewechselt. So ist ziemlich leicht, durch die Kombination zweier Änderungen einer virtuellen Maschine (Memory-Erweiterung + neue Netzwerkkarte oder CPU-Erweiterung + zusätzl. Netzwerkkarte) eine Neuaktivierung auszulösen. Das ist an sich schon ärgerlich. Ganz ekelhaft wird das Auslösen einer Windows-Reaktivierung aber beim Rückgriff auf ein Backup und dessen Inbetriebnahme. Im Besonderen dann, wenn das Problem der laufenden Windows-
Maschine, das den Rückgriff auf ein Backup verursacht, durch ein Windows-Update selbst hervorgerufen wurde.

Falsche Reaktion auf Rückfragen von VMware

Ein Fehler, den man unter VMware schnell macht und der anschließend nicht mehr so einfach zu korrigieren ist, ist folgender:

Man hat eine Kopie aller Dateien einer virtuellen Windows-Maschine unter VMware erstellt und natürlich nicht weiter benutzt. Das laufende Windows-System ist aufgrund irgendwelcher Aktionen zerschossen. Man löscht die zugehörigen Dateien (ggf. auch aus Platzmangel). Man kopiert die Dateien des letzten Backups vom Backup-System zurück in eine Zielpartition des Linux-Systems. Man öffnet die virtuelle Maschine und startet sie. Dann kommt eine typische Frage von VMware mit etwa folgendem verkürzten Inhalt:

The virtual machine may have been moved or copied. … In order to configure certain management and networking features VMware needs to know which. Did you move this virtual machine, or did you copy it? If you don’t know, answer “I copied it”.
Haben sie die Maschine kopiert oder verschoben? Im Zweifel soll man dann den Auswahlpunkt “Kopiert” anklicken.

Die Wahl “Kopiert” erscheint dann logisch, da das Backup ursprünglich ja mal als Kopie entstanden ist. Leider wird man dann nach dem Starten der Backup-Installation feststellen, dass eine Neuaktivierung von Windows erforderlich ist. Die ggf. fehlschlägt; man kann dann trotz Backups nicht mehr produktiv mit dem Gastsystem arbeiten.

In diese Falle bin ich selbst schon getappt. Zu beachten ist: Man hat in dem von mir beschriebenen Prozess nichts Illegales getan. Die Windows-Lizenz sieht das Anlegen von Backups vor. Man benutzt in dem beschriebenen Prozess die angelegte Backup-Kopie auch nicht parallel zum Original. (Das würde aus einem bestimmten Grund – s.u. – auch Zusatzmaßnahmen erfordern).

Ursache und Problemlösung

Im lokalen LAN müssen MAC-Adressen eindeutig sein, damit die Zuordnung von IP-Adresse zu MACs eindeutig wird und das ARP-Protokoll korrekt funktionieren kann. Wird eine Kopie einer virtuellen Maschine angelegt, so kann es natürlich sinnvoll sein, die MAC der virtuellen Maschine zu ändern, um bei einem Start des Originals und der Kopie zwei identische MAC-Adressen im Netz zu vermeiden. Antwortet man auf die obige Frage mit “Copied oder Kopiert”, so passiert genau das: VMware ändert die Mac-Adressen der NICs der “kopierten” virtuellen Maschine. Aus Sicht von Windows hat das System dann eine oder gar mehrere neue Netzwerkkarten bekommen – im Spiel um eine Windows-Neuaktivierung entspricht dies einem sehr hoch bewerteten Kriterium.

VMWare vergibt zudem pro virtueller Maschine eine eindeutige UUID, die an die BIOS-Kennung (SMBIOS Descriptor) gebunden wird und somit auch von Windows erkennbar ist. Hierauf reagiert ein Konzern, dessen Erfolg auf Geldverdienen mit Lizenzen aufgebaut ist, natürlich allergisch. Beantwortet man also die obige (berechtigte) Frage von VMware mit “Kopiert”, so wird die UUID von VMware geändert. Windows erkennt das und löst nach meiner Erfahrung in jedem Fall eine Reaktivierung aus, um eine Lizenzverletzung zu prüfen.

Leider begibt man sich durch beide Effekte als User schnell in Teufels (MS Lizenz-) Küche, wenn man auf die obige Frage von VMware falsch antwortet – selbst wenn man nicht Illegales tut und nur Backups reaktivieren will. Dies gilt im Besonderen dann, wenn man lediglich eine günstige OEM-Lizenz für sein Windows erworben hat, die ja relativ strikt eine bestimmte HW gebunden wird.

Will man solche Probleme vermeiden, gilt also:

Die richtige Antwort bei Reaktivierung eines Backups und Ersetzung der originalen virtuellen Maschine ist: “Moved” oder “Bewegt” – unabhängig davon, dass der Backup-Erstellung ein echter Kopierprozess zugrunde lag.

Selbst
wenn diese Antwort mal falsch sein sollte: Alle UUID-Probleme, ja selbst das Netzwerkkarten-Problem, lassen sich bei Bedarf auch anders lösen. Eine bei MS vergeigte Lizenz durch Backup-Reaktivierung erfordert dagegen einen wesentlich höheren Aufwand an Zeit und Nerven.

Eine weitere Regel ist: Werft auch bei einer zerschossenen Windows-Maschine die zugehörige vmx-Definitionsdatei nicht sofort ins digitale Nirwana. Mit ihrer Hilfe kann man ggf. noch etwas retten, wenn die Aktivierung der Backup-Kopie bei Microsoft fehlschlagen sollte.

Manuelle UUID-Einstellungen und manuelle Vorgaben für Kopien

Der Vollständigkeit halber möchte ich darauf hinweisen, dass das Verhalten von VMware bzgl. der UUID-Änderung durch Anweisungen in der Definitionsdatei einer virtuellen Maschine beeinflusst werden kann. Siehe hierzu einige der unten angegebenen Links.

Auch die MAC-Einstellungen sind in der vmx-Datei natürlich zugänglich für evtl. notwendige Änderungen oder Rückschreibungen auf die ursprünglichen Werte.

Links

https://kb.vmware.com/ selfservice/ microsites/ search.do?language=en_US&cmd= displayKC&externalId= 1541
https://www.vmware.com/ support/ ws5/ doc /ws_move_ uuid_ moving_ virtual_ machines.html
https://pubs.vmware.com/ workstation-12/ index.jsp#com.vmware.ws.using.doc/ GUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html
https://pubs.vmware.com/workstation-12/ index.jsp? topic=%2Fcom.vmware.ws.using.doc%2 FGUID-533B2C4F-7BD5-41EB-8392-2B9FE687AE50.html
https://jojitsoriano.wordpress.com/ 2010/09/03/ avoiding-activation-when-movingcopying-a-windows-7-vmware-image/