Fileserver Migration

Ein alltägliches Szenario. Ein betagter Fileserver soll auf ein neues Betriebsystem wandern. Das kann z.B. eine V2V Migration sein, etwa bei Wechsel von Server2000 auf Server2008. Aber auch eine P2V Migration mit gleichzeitigem Systemwechsel.

Der reine Transfer der Nutzdaten ist nicht wirklich problematisch. Tools wie z.B. Robocopy sind hier wertvolle Helfer. Schwieriger kann da schon die Wiederherstellung der Freigaben sein, vor allem wenn sich hier über die Jahre komplexe Strukturen entwickelt haben. Mit einem kleinen Trick lassen sich all diese Einstellungen leicht transferieren. Bei den Berechtigungen muß es sich jedoch um Benutzerkonten der Domäne handeln. Lokale Benutzer des Quellsystems werden vom Zielsystem nicht erkannt. „Fileserver Migration“ weiterlesen

Linux VM: eth0 disabled

Nach dem Klonen einer Linux VM trat das Phänomen auf, daß nach einem Neustart das Netzwerkinterface eth0 im Status „deaktiviert“ war. Man kann es zwar manuell aktivieren, aber nach einem Neustart war es wieder deaktiviert. Sehr lästig.

Auffällig ist auch, daß der Netzweradapter nicht wie sonst üblich eth0 heisst, sondern eth0.bak. Dies tritt in der Regel auf, wenn sich die Hardware des Netzadapters, oder dessen MAC Adresse ändert. „Linux VM: eth0 disabled“ weiterlesen

Storage DRS default affinity

Mit Einführung von vSphere5 kam Storage-DRS als eine neue Funktionalität hinzu. Ähnlich dem herkömmlichen DRS, welches die VM Lastverteilung bezüglich Arbeitsspeicher und CPU zwischen den ESXi Knoten regelt, ermöglicht Storage-DRS eine automatische Lastverteilung in Bezug auf Speicherplatz und I/O.

In der Praxis beobachtet man jedoch häufiger, daß VMs oder einzelne ihrer vDisks nicht migriert werden, obwohl erhöhte Last über einen längeren Zeitraum auftritt. Die Ursache, warum Storage-DRS beispielsweise nicht die vDisk einer VM verschiebt, welche die stark beanspruchte Datenbank enthält, fand ich durch einen Blogartikel von Duncan Epping auf Yellow-Bricks.

Die Standard Einstellung eines jeden Storage Clusters ist „VMDKs zusammenhalten“ bzw. „keep VMDK’s together“. Eine Default Einstellung, die sicherlich dem Admin entgegenkommen soll, damit er nicht alle Disks seiner VM auf mehrere LUNs verteilt suchen muß. Der Preis für diese „Ordnung“ ist allerdings, daß die Dateien einer VM nur komplett oder gar nicht verschoben werden. In der Praxis bedeutet dies, daß z.B. eine VM mit 5 vDisks von je über 100 GB nur unter extremsten Bedingungen auf eine andere LUN wandern würde. Wünschenswert wäre jedoch, daß beispielsweise nur eine einzelne VMDK Datei verschoben wird, da diese gerade unter erhöhten I/O Druck geraten ist.

Die nett gemeinte, aber etwas unflexible Standardeinstellung dieses Verhaltens läßt sich leicht ändern:

  •  Ansicht Datenspeicher und Datenspeicher Cluster
  • Kontextmenü von Datenspeicher-Cluster öffnen und „Einstellungen bearbeiten“ wählen
  • Einstellungen der VM
  • Haken bei „VMDKs zusammenhalten“ entfernen. Entweder für einzelne VMs oder global für den gesamten Storage-Cluster.

Weiterführende Literatur

Frank Denneman zum Thema impact of intra vm affinity rules on storage drs.

Bug: svMotion benennt vmdk Dateien nicht um

Normalerweise wird die Benennung von VM Dateien und Diskfiles bei einer Storage vMotion Aktion dem VM Namen angepasst, so daß alle Dateien den Namen der VM tragen. Genau das trat aber heute nicht ein. Der Ordner wurde zwar umbenannt, die VMX Datei und die VMDK Container behielten aber ihre ursprüngliche Bezeichnung. Warum? Eine kurze Suche brachte Licht ins Dunkel. Offensichtlich hat vSphere 5.0.0 in dieser Hinsicht noch einen Bug, der unter KB 2008877 beschrieben wird.

Derzeit bleibt also nur zwei mögliche Methoden:

  • Die (mühsame) Methode der manuellen Umbenennung mittels vSphereCLI (vgl. Renaming a virtual machine and its files)
  • Die VM „kalt“ migrieren. d.h. im ausgeschalteten Zustand migrieren. Dabei werden die Namen der Files an den VM-Namen angepasst.

Warten wir auf den nächsten Patch. 🙂