Author Archives: Ralph Mönchmeyer

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema

Posted on by

Ein neues Test-System bietet eine gute Gelegenheit, neue Technologie unter Linux auszuprobieren. In diesem Fall einen SSD-Raid-Verbund. So etwas mache ich natürlich nicht nur zum Vergnügen. Mein eigentliches Ziel ist es, Berechnungen eines Kunden, die auf Daten einer oder mehrerer MySQL-Datenbanken mit Tabellen mit bis 20 Millionen Datensätzen zurückgreifen, für die HW eines kleineren Standalone-Servers zu optimieren. Dabei sollen die Raid-Arrays auf ein bestimmtes Lastverhalten und andere Faktoren hin optimiert werden. Ich habe dabei doch ein paar Überraschungen erlebt.

Bzgl. SSDs hat sich in den letzten Jahren ja viel getan; die aktuellen SSDs sind schneller, die preislich erschwingliche Kapazität ist deutlich größer geworden. Am wichtigsten ist aber, dass sich die Haltbarkeit verbessert hat. Das ist für kleinere Unternehmen durchaus ein Punkt. Der Austausch von mehreren SSDs kostet ja nicht nur Geld, sondern auch Betriebsausfallzeiten und ggf. Aufwände externer Administratoren.

Diese Artikelserie ist für Leute gedacht, die sich dem Einsatz von SSD-Arrays im privaten Bereich oder aber in kleinen Unternehmen annähern wollen – und dabei sicher über einige grundlegende Fragen stolpern. Wir betrachten also SSD-Raid-Arrays in Linux-Workstations oder kleineren Linux-Servern. Dabei fassen wir auch den Einsatz von SATA3-Onboard-Controllern ins Auge – für Intel Chipsätze wie den Z170, dessen Sunrise-Point-Controller und Intels zugehörige, sog. “iRST”-Technologie.

In einem Linux-Blog ist vor allem auch der Einsatz von Linux-SW-Raid-Arrays von Interesse. Viele der in den kommenden Artikeln getroffenen Feststellungen zu Linux-SW-Raids gelten dabei ganz unabhängig von der Anlagengröße oder dem verwendeten SATA/SAS-Controller.

Raid mit SSDs – ein facettenreiches Thema

Warum will man überhaupt SSD-Raid-Arrays einsetzen? Typische Motive sind: Eine Verbesserung der Ausfallsicherheit und Performanceverbesserungen über das Leistungsvermögen einer einzelnen SSD hinaus.

Nach meiner Meinung sollte man diese Punkte jedoch gut hinterfragen, bevor man unbedarft Geld in die Beschaffung mehrerer SSDs steckt. Im Besonderen sollte man nicht auf Werbeversprechen, die mit sequentiellen Lese- und Schreibraten argumentieren, hereinfallen. Ferner gibt es (nicht nur unter Linux) einige weitere Punkte zu beachten:

  • Kann man für kleinere Server Mainboard-Sata-Controller nutzen? Oder ist ein Griff zu HW-Controllern schon aus Performancegründen unumgänglich?
  • Bietet der Einsatz spezieller Technologie (wie etwa Intels iRST; s.u.) für einfache Mainboard SATA3-Controller Vorteile gegenüber nativen SW-Raid-Verfahren unter Linux?
  • Will man das System aus einem Raid-Array heraus booten? Geht das überhaupt?
  • Wie sieht es mit dem Verschleiß der SSDs aus? Hat die Art des Raid-Systems darauf einen Einfluss? Lässt sich der fstrim-Befehl für Partitionen auf Raid-Arrays absetzen?
  • Von welchen Faktoren und Konfigurationsparametern hängt die Performance eines Linux-SW-Raid-Arrays ab?
  • Kann man den Standardeinstellungen vertrauen, die manche Linux-Installer für die Konfiguration von Raid-Arrays anbieten?

Arbeitet man sich in die Thematik ein, so merkt man schnell, dass das Thema “SSD-Arrays” eine Wissenschaft für sich ist. Und dann stößt man z.T. auch auf wirklich widersprüchliche Hinweise im Internet:

Das schlimmste Beispiel sind Artikel zur sog. Chunk-Size eines Arrays. Da werden von Administratoren mal möglichst große Chunk-Sizes im Bereich von 2 MB empfohlen, während andere möglichst kleine “Chunk Size”-Größen zwischen 8 und 32 KB empfehlen. Jeweils natürlich mit unterschiedlichen Begründungen, die vom Leser
selten zur Deckung gebracht werden können. Es kommt dann die Frage auf, ob die jeweiligen Autoren nicht implizite Annahmen bzgl. bestimmter Lastprofilen gemacht haben …

Ich habe nun mehrere Tage mit eigenen Tests und Informationsbeschaffung verbracht – erst jetzt hat sich ein Vorgehensmodell herauskristallisiert. Ich werde mir dabei aus guten Gründen Reserven für weitere datenbankspezifische Experimente offen lassen. Inzwischen habe ich immerhin einige Erkenntnisse gewonnen, die auch anderen helfen können, wenigstens ein paar essentielle Fehler und eine unkritische Übernahmen von Empfehlungen zu vermeiden.

Verfügbare Ressourcen auf dem neuen Test-System

Mein neues Testsystem hat folgende Ressourcen:
i6700K-CPU, 64 GB RAM, 4 Raid10 HDDs mit HW-Controller, 1 rel. teure SSD 850 Pro, 4 relativ kostengünstige SSDs 850 EVO.

Das Z170-Mainboard weist einen onboard Intel Z170-SATA3-Controller (Sunrise Point) auf, der mit Intel Rapid Storage Technologie [iRST] betrieben werden kann. Es handelt sich dabei um eine Lösung von Intel, die eine (Vor-) Konfiguration von Raid-Platten-Verbänden bereits im BIOS zulässt. Ich spreche in den kommenden Artikeln kurz vom “iRST-Controller”, wenn denn iRST im BIOS aktiviert ist.

Was ist das vorläufige Zwischenergebnis nach etlichen Tests?

Um den Leser einen Vorgeschmack zu geben, hier ein paar vorläufige Entscheidungen:

  1. Ich habe eine klare Entscheidung für Linux-SW-Raid getroffen und gegen den Einsatz von iRST getroffen. Weniger aus Performance-Gründen, als vor allem aus Gründen der Flexibilität. Auf iRST werde ich ganz verzichten; die Platten werden BIOS-seitig im reinen AHCI-Modus angesprochen.
  2. Es werden hauptsächlich Raid-10-Arrays und keine Raid-5-Arrays zum Einsatz kommen. Dies ist eine fundamental wichtige Entscheidung! Sie ist primär dadurch motiviert, die SSDs zu schonen. Raid 10 ist hinsichtlich Plattenplatz teuer – aber das erscheint mir im Vergleich zur Plattenabnutzung nach meinen bisherigen Erfahrungen ein relativ kleiner Preis zu sein.
  3. Ich werde das Betriebssystem (OS Suse 42.2 und alternativ Debian) nicht auf einer Partition des Raid-Systems selbst aufsetzen – und wenn doch, dann nur zu Testzwecken, aber nicht zum produktiven Arbeiten.
  4. Ich werde die Raid-Erstellung nicht halbautomatisch über YaST, sondern manuell vornehmen. Hierfür gibt es einen guten Grund, den ich in einem kommenden Artikel erläutern werde.
  5. Bzgl. des Partition-Alignments werde ich dagegen nach vielen manuellen Checks Opensuses’ YaST bzgl. dessen Alignment-Algorithmen vertrauen.
  6. Insgesamt werde ich auf den SSDs ca. 12% Plattenplatz ungenutzt lassen. Das ist teuer, aber bzgl. des Verschleißes eine Vorsichtsmaßnahme.

  7. LVM wird zum Einsatz kommen; die logischen Volumes werden mit guten Reserven bzgl. des eigentlichen Platzbedarfes angelegt.
  8. Ich werde mir die Option für mehr als 2 Raid Arrays auf ein und demselben Plattenverbund offen lassen. Für echte Hochperformance-Aufgaben werde ich kleine Raid-5-Arrays weiter austesten.
  9. Für weitere intensivere Applikations- und Datenbanktests werde ich mindestens 2 Raid-Arrays mit ganz unterschiedlichen Raid Chunk Sizes, nämlich 512KB bzw. 32KB verwenden. Die Chunk Size hat sich als ein essentieller Parameter für eine gute Performance erwiesen.
  10. Bzgl. der endgültigen Wahl der Chunk Size gibt es gleich mehrere Aspekte zu beachten – u.a. die Art der Last: Random I/O? Kleine Blocksizes? Viele parallele und konkurrierende Prozesse mit Plattenzugriff oder eher
    zeitlich getrennte Einzelprozesse mit hohen Last-Peaks? Viele separate Zugriffe? Applikationen mit Threading zur Lastverteilung? Auf einem halbwegs ausgelasteten Fileserver wüsste ich jetzt bereits die richtige Wahl; für unsere spezielle PHP/MySQL-Anwendung sind weitere Tests und ggf. sogar eine stärkere Parallelisierung des SW-Algorithmen für mehrere CPU-Cores erforderlich.

Eine wichtige Sache, die ich auch gelernt habe:

Man kann die potentiellen Probleme nicht allein mit einfachen Testtools wie “hdparm -tT”, “dd” für das Lesen und Schreiben größerer Test-Datenmengen mit unterschiedlichen Blockgrößen oder grafischen Tools wie “gnome-disks” erfassen.

Ein Ergebnis wie

irst_raid_ssdroot_20mb_400_from_old_rux

für den iRST ist nicht wirklich aussagekräftig. Tools wie “fio”, die eine differenzierter parametrierte Last erzeugen können, sind wesentlich hilfreicher.

Aber der Reihe nach – in den zunächst kommenden Teilen dieser Miniserie
SSD Raid Arrays unter Linux – II – HW-Controller?
gehe ich zunächst ein wenig auf das Thema HW-Controller ein. Lohnt sich deren Einsatz?

Es folgen dann ein paar Beiträge zum Einsatz von iRST im Vergleich zu nativen SW-Raids.

Danach werde ich mich mit Frage Raid-5 vs. Raid-10 auseinandersetzen. Ein weiterer Artikel zeigt dann, wie man Raid-10-Arrays unter Linux praktisch konfiguriert.

Schließlich werde ich Performance-Daten präsentieren und daraus Schlussfolgerungen bzgl. der Raid-Konfiguration ziehen.

Der eine oder andere praktisch veranlagte Leser wird sich im Gegensatz zu der von mir gewählten Themenfolge vielleicht als erstes auf das Thema einer Anlage und Konfiguration von SW-Raid-Arrays stürzen wollen. Bitte, kein Problem! Ich empfehle vorab eine intensive Auseinandersetzung mit dem “mdadm”-Kommando und seinen Optionen. Siehe zur Einführung etwa

https://raid.wiki.kernel.org/index.php/RAID_setup
https://www.thomas-krenn.com/de/wiki/Software_RAID_mit_MDADM_verwalten
https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
https://linux.die.net/man/8/mdadm
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.advdisk.html#sec.yast2.system.raid

Einen kleinen “Kurs” zu mdadm bietet die Seite
https://www.tecmint.com/understanding-raid-setup-in-linux/.

Eclipse Neon 1 – Standard-JSDT mit Schwächen – zusätzliche Plugins

Posted on by

Im September 1016 wurde die neue Eclipse-Version NEON I veröffentlicht. Ich hatte mir zuvor im Sommer bereits die R-Version angesehen. Während das PDT-Plugin für PHP unter NEON gut aussieht und seine Dienste auch für PHP 7 in gewohnter Weise leistet, kam bei einem Blick in die JSDT-Ecke eher ein wenig Enttäuschung auf.

Zwar gilt:
Der neue JS-(Esprima)-Interpreter kann sehr gut mit “ECMAScript 6”-Syntax [ES6]. Auch der Outline-Bereich funktioniert z.B. für die Anzeige definierter Objekt-Methoden/Funktionen, die über die neue ES6-Syntax mit “calss”-Statements angelegt werden, perfekt. Die gesamte Hierarchie von Objekt-Methoden/Funktionen und -Variablen wird dabei angezeigt. Gut gefallen haben mir auch der Debugger, der Support von “node.js” und auch ein paar andere neue Features (siehe etwa https://www.youtube.com/watch?v=UxGwu2adzIc). Generell ist es begrüßenswert, dass engagierte Leute versuchen, JSDT auf ein neues, zeitgemäßes Niveau zu hieven !

Aber: Wer hat schon alle seine JS-Codes auf die ES6-Syntax umgestellt? Zumal nicht alle von Kunden genutzten Browser-Versionen ES6 unterstützen.

Und dann kommt beim originalen unmodifizierten JSDT von NEON ein wenig Frust auf:

Hat man seine Objekt-Methoden über die klassische Syntax und Definitionen in der Prototype-Chain festgelegt, wird die nächste Hierarchieebene “Objekt” => Funktionen und Variablen” für ein Objekt im Outline-Fenster leider nicht mehr angezeigt. Der Outline-View für Objekte endet dann auf der Ebene der Objektnennung – nur der oberste Level wird angezeigt, also das Objekt selbst, nicht aber seine Variablen oder Methoden/Prototype-Funktionen. Ich habe das gerade nochmal für ein frisch heruntergeladenes NEON I überprüft.

Das Outline-Tool liefert für ES(≤5)-Code also leider nicht mehr die Funktionalität, die man von Mars 2 und Vorgängerversionen gewohnt war. Ich weiß nicht, ob sich die Eclipse-JSDT-Entwickler darüber im Klaren sind, dass das fast einem KO-Kriterium für die Benutzung entspricht? Eine voll funktionierende Outline-Umgebung mit mindestens zwei funktionierenden Hierarchie-Ebenen ist für ein schnelles organisiertes Arbeiten bei komplexen Codes ein Muss.

Ein Test-Beispiel

Folgender simpler Testcode zeigt das Problem auf: 

var z = 7; 
var GOCR = new GOCC();  

var xas = function() {
  var beta = GOCR.beta(); 	
	
  var yas = function () {
	  var loc_num = GOCR.alpha(); 	
	  var zzz = function() {
		  var fff = 'fff'; 
	  }; 
  };  
}; 

class UUC {
	constructor (x) {
		this.x = x; 
	}
	ucc_alpha() {
		this.y = 'yyyy'; 	
	}
}

function GOCC() {
	this.ax_str = 'ufo'; 
	this.vv_ay  = new Array('Enlarge'); 
}

	GOCC.prototype.alpha = function() {
		this.a_num = 7;  
	};
	
	GOCC.prototype.beta = function() {
		this.b_num = 8; 
		return this.bnum; 
	};

 
Mit dem unmodifiziertem JSDT von NEON I führt dies zu folgender Darstellung im Outliner:

not_expanding_object_prototype_functions

Man erkennt, dass zwar verschachtelte Funktionsstatements über mehrere Hierarchieebenen hinweg korrekt aufgelöst werden. Auch die Methoden der “UUC”-Klasse werden noch dargestellt. Die Funktionen aber, die einem Funktionsobjekt über dessen Prototype zugeordnet wurden, werden jedoch im Gegensatz zum JSDT von Eclipse Mars nicht im Outline-View angezeigt.

Workaround mittels “Webclipse JSjet” und “Tern”

nDiejenigen, die nicht auf eine originäre Lösung im Rahmen der weiteren JSDT-Entwicklung warten wollen, können ggf. auf das Webclipse JSjet-Plugin zurückgreifen (Eclipse Repository: https://www.genuitec.com/updates/webclipse/ci/). JSjet greift intern auf Tern-Funktionalität zurück. Nach der Installation bietet der Outliner für Objekte bzw. Objekt-Konstruktor-Funktionen wenigstens zwei Ebenen an. Allerdings muss man sich dafür nach jedem Neustart von Eclipse mit etwas nerviger Werbung für Webclipse und die Fa. Genuitec auseinandersetzen – und mir persönlich sind die Lizenzbedingungen nicht vollständig klar. Ein Blick in diese Ecke lohnt sich aber durchaus.

Ich habe testweise auch die wichtigsten “tern”-Plugins aus dem aktuellen Repository “http://oss.opensagres.fr/tern.repository/1.2.0/” installiert. Insgesamt habe ich dadurch neben einer bzgl. Class und Prototype verbesserten Outline-Darstellung auch eine vernünftige Autocompletion-Unterstützung für jQuery erhalten. Dies ist umso wichtiger, als der Entwickler für das bisher bewährte JSDT-jQuery-Plugin nach eignen Ausführungen auf seiner Github-Seite Probleme mit Neon hat und um Unterstützung bittet.

In einer Testinstallation versammeln sich dann neben dem JSDT-Plugin u.a. folgende Plugins für die JS-Entwicklung:
tern_plugins

Mit dem Resultat kann man leben:
expanding_object_prototype_functions_with_tern
Ich verstehe nicht, dass das, was da geboten wird, nicht schon in den Standard übergegangen ist, da ja beim neuen JSDT-Team auch jemand von der Fa. Genuitec, die hinter Webclipse steckt, dabei zu sein scheint.

Fairerweise muss man sagen, dass die Auflösung über mehrere Ebenen hinweg unter dem Standard JSDT für verschachtelte Funktionen sogar besser funktioniert als mit JSjet und Tern. Leider aber nicht für Objekt-Konstruktoren und Prototype-Funktionen nach alter ECMA-Syntax.

Ich hoffe auf ein noch besseres JSDT in der Neon 2 Version.

Nachtrag 01.04.2017:

Meine Hoffnungen – und vielleicht die anderer Leser – wurden leider nicht erfüllt. Umso interessanter erschien es mir, mich ein wenig genauer mit JSjet auseinanderzusetzen. Leider gibt es auch da nicht nur Positives zu berichten. Mehr findet ihr dazu in folgenden Blogposts:

Webclipse JSjet, Eclipse Neon 2 and the Outline View – what I like and what not – part I
Webclipse JSjet, Eclipse Neon 2 and the Outline View – what I like and what not – part II

Reaktivierung des Backups eines Windows-Gastes unter VMware Workstation

Posted on by

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/