Drücke "Enter", um den Text zu überspringen.

Schlagwort: Hyper-V

Hyper-V VMs werden angehalten, wenn der Speicherplatz knapp wird

Auch wenn die Tatsache selbst nicht neu ist möchte ich den folgenden Fakt etwas genauer beleuchten, da immer mehr Unternehmen Hyper-V für produktive Virtualisierungszwecke verwenden.

Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.

Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).

Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):

Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.

Glücklicherweise kündigt sich das bereits vorab an:

Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.

Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.

Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:

Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!

(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)

Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!

Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:

(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)

Schreibe einen Kommentar...

Einige Neuerungen im Windows Server 2015 (Technical Preview) bezüglich Hyper-V

In der aktuell verfügbaren Technical Preview vom künftigen Windows Server (aktuell unter verschiedenen Namen bekannt, Windows Server 10, Windows Server 2015, Threshold, …) sind bereits einige Neuerungen in Hyper-V erkennbar. Einige davon möchte ich hier kurz ansprechen:

Production Checkpoints vs. Standard Checkpoints

Neben den bisherigen “regulären” Snapshots / Checkpoints (Im Windows Server 2015 als “Standard Checkpoints” bezeichnet) gibt es nun “Production Checkpoints” die explizit für Maschinen im Produktiv-Betrieb gedacht sind.

Hierbei wird mit Hilfe der Datensicherungstechniken des Gastbetriebssystems (bei Windows via VSS, bei Linux über den Systempuffer) ein Snapshot erzeugt, der auf Konsistenz ausgelegt ist. Sollte ein solcher Snapshot nicht möglich sein, wird auf einen regulären Snapshot ausgewichen (bei dem eben keine Konsistenz aller Daten gegeben ist). Wurde der Production Snapshot erfolgreich erzeugt, wird eine entsprechende Meldung ausgegeben:

Für den Production Snapshot muss die Windows Server Sicherung im Gast-System NICHT installiert sein:

Laufende Anwendungen werden bei dieser Snapshot-Technik nicht berücksichtigt. Nach einem Revert (Zurücksetzen au einen Snapshot) muss die VM neu gestartet werden, Anwendungen die zum Zeitpunkt des Snapshots liefen gehen dadurch verloren. Allerdings verhält sich das Gast-Betriebssystem so, wie nach einem regulären, sauberen Shutdown:

Hyper-V Manager Remote Management

Bereits frühere Versionen vom Hyper-V Manager haben es ermöglicht, von einem System aus mehrere Hosts unter einer GUI zu verwalten. Dabei fand das Login auf den Remote-Servern immer mit den Credentials des interaktiv angemeldeten Benutzers statt. Der neue Hyper-V-Manager macht es jetzt möglich, alternative Login-Daten anzugeben:

Damit wird es möglich, Maschinen in fremden Domänen, in Workgroups oder in der DMZ anzusprechen.

Schreibe einen Kommentar...

Windows Server 2012 R2: Einrichten eines Failover-Clusters am Beispiel Hyper-V

Ein Failover-Cluster ist eine gute Sache: Er sorgt für Hochverfügbarkeit! Damit lassen sich diverse Dienste geclustert betreiben. Mehrere Server teilen sich eine Aufgabe und die dazugehörige Last. Fällt nun einer der beteiligten sogenannten “Knoten” aus, so übernehmen die verbliebenen die Aufgabe sofort automatisch. Damit lässt sich beispielsweise auch Hyper-V bzw. die darauf laufenden virtuellen Maschinen gegen einen Ausfall absichern.

Für eine Minimal-Konfiguration werden benötigt:

  • Ein Domänencontroller
  • Zwei weitere Server als Mitglied der Domäne
  • Zentraler Speicher

Für den zentralen Speicher kämen die beiden SAN-Technologien iSCSI und FiberChannel in Frage. Optional geht seit Server 2012 auch SMB3.0 (“Scale Out File Server”). Für eine Testumgebung ist iSCSI sehr gut geeignet. Wie man ein iSCSI-Target einrichtet und den dazugehörigen Initiator nutzt habe ich in einem meiner letzten Blogartikel beschrieben (Windows Server 2012 R2: iSCSI Target und Initiator einrichten).

Der Domänencontroller sowie die beiden Member-Server laufen unter Windows Server 2012 R2.

Es werden 2 iSCSI-Targets benötigt, eines mit min. 512MB Speicher, das zweite mit ausreichend Speicher für die vorgesehenen VMs und deren VHD(X)-Dateien, in meinem Fall 40GB. Die beiden Targets müssen bereits auf beiden Knoten eingebunden sein, die beiden Datenträger online geschaltet worden sein, initialisiert und formatiert (ohne Laufwerksbuchstaben).

Weiterhin muss das Netzwerk sauber konfiguriert sein. Für eine Testumgebung reicht es, wenn die beiden Hosts über genau eine Netzwerkverbindung verfügen. Dort muss das selbe Subnetz eingerichtet sein, ebenso ein passender DNS-Server und ein Gateway. Für Produktivzwecke empfehlen sich deutlich mehr Netzwerkverbindungen, z.B. eine dedizierte für den Heartbeat (Link zwischen den Knoten), eine für die Anbindung an das Storage, eine für die Verwaltung, eine für die Anbindung an das reguläre Netzwerk und so weiter und so fort.

Als nächstes muss auf allen künftigen Knoten das Feature “Failoverclustering” installiert werden. Dazu werden auch die Verwaltungstools angeboten, die zumindest auf einem System installiert sein müssen, um den Cluster einrichten zu können:

Wenn die Installation auf beiden/allen künftigen Knoten abgeschlossen ist kann der “Failovercluster-Manager” gestartet werden, z.B. über “Tools” im Servermanager:

Dort wird durch einen Rechtsklick auf das Wort “Failovercluster-Manager” im Baum links mittels “Cluster erstellen…” der Prozess begonnen:

In den ersten Schritten sind die künftigen Knoten auszuwählen:

 

Danach folgt eine Abfrage bezüglich des “Konfigurationsvalidierungstests”. Dabei werden die beteiligten Server “auf Herz und Nieren geprüft”. Dieser Test dauert ca. 10 Minuten. Man könnte ihn abschalten – verzichtet dann auber auf den Support durch Microsoft und wertvoll Hinweise zur Konfiguration. Nicht zuletzt kann der Test einem auch Fehler aufzeigen, die man bei der Vorbereitung übersehen hat. Ich würde ihn also immer laufen lassen…

Am Ende des Tests wird einem das Ergebnis angeboten (“Bericht anzeigen”):

In diesem Fall liegt nur eine Warnung vor: Es gibt nur eine Netzwerkverbindung!

Nun muss noch ein Name für den Cluster sowie eine entsprechende IP-Adresse bestimmt werden. Außerdem kann man auswählen, dass der gesamte verfügbare Speicher dem Cluster hinzugefügt werden soll:

Danach beginnt die eigentliche Bildung des Clusters. Ist diese abgeschlossen, kann die Clusterkonfiguration verändert werden bzw. der Cluster mit Rollen ausgestattet werden. Dabei ist zum einen die Netzwerkkonfiguration zu prüfen: Wenn es einen dedizierten Link zwischen den Hosts geben soll, so ist bei dieser Netzwerkkonfiguration der Haken “Clients das Herstellen einer Verbindung…” zu entfernen. Weiterhin muss das zweite iSCSI-Target noch als “Cluster Shared Volume” (CSV) bzw. al “freigegebenes Clutservolume” hinzugefügt werden. Das sorgt dafür, dass dieses “Laufwerk” auf allen Clutserknoten unter C:\ClusterStorage eingebunden wird und dort genutzt werden kann (z.B. für die VMs und VHDs)

Abschließend können nun VMs im Cluster erzeugt werden. Dabei ist darauf zu achten, das alle relevanten Daten unter C:\ClusterStorage liegen!

Wenn die VM fertig konfiguriert ist und läuft, dann kann man ganz einfach die Funktionsfähigkeit des Clusters testen und einen einfachen Ausfall simulieren: Man zieht einfach das Netzwerkkabel aus dem Host heraus, auf dem die VM aktuell ausgeführt wird. Dann sollte sie in kurzer Zeit auf dem verbliebenen Host neu gestartet werden und dann kurz darauf wieder regulär zur Verfügung stehen!

Schreibe einen Kommentar...

Hyper-V 4.0: Live Größenänderung von virtuellen Festplatten

Eine der wirklich praktischen Neuerungen im Hyper-V 4.0 unter Windows Server 2012 R2 ist die Möglichkeit, eine virtuelle Festplatte im laufenden Betrieb zu vergrößern oder zu verkleinern. Dies funktioniert, wenn:

  • Die virtuelle Festplatte das VHDX-Format verwendet und
  • Am SCSI-Controller angebunden ist

Wenn man eine virtuelle Maschine der 2.Generation (Gen2-VM) verwendet, stellt sich die Frage nach der zweiten Bedingung nicht, da hier ja ohnehin nur noch SCSI zum Einsatz kommt.

In der Abbildung ist eine Muster-VM zu sehen, die neben ihrer OS-Platte noch über eine zweite Platte (VHDX, SCSI-Controller) mit 30GB verfügt:

Nun kann diese VHDX-Festplatte im laufenden Betrieb vergrößert werden. Dazu ist nur ein Klick auf “Bearbeiten” nötig:

Der Assistent führt einen dann durch die notwendigen Schritte, bei dem schließlich auch die gewünschte neue Größe angegeben wird: (Klick auf Bild für Vergrößerung)

 

 

Am Ende steht dann eine Festplatte mit mehr Speicher zur Verfügung, bei der anschließend noch die Partition erweitert werden muss:

PS: Die VHDX lässt sich auch verkleinern, allerdings nur, wenn die Partition im Inneren kleiner ist, als der Datenträger…

Weitere Informationen: http://technet.microsoft.com/en-us/library/dn282286.aspx

Schreibe einen Kommentar...

Hyper-V und USB-Datenträger

Oft liest und hört man, dass Hyper-V nicht mit USB-Datenträgern umgehen kann/könne. Dies wird mit der Generation-2-VM unter Windows Server 2012 R2 (Hyper-V 4.0) anders. Dort ist es dank des “Erweiterten Sitzungsmodus” möglich, eine Hyper-V VM auch ohne Netzwerk per RDP anzusprechen und dabei auch Laufwerke mitzunehmen.

Aber: Auch unter den älteren Hyper-V-Versionen bzw. auch bei Generation-1-VMs lassen sich USB-Datenträger mit in die VM “hineinreichen”. Dies klappt allerdings leider nur dann, wenn sich der Datenträger als Festplattenlaufwerk präsentiert (i.A. also bei USB- und Firewire-Festplatten). Dazu muss folgendermaßen vorgegangen werden:

1. Datenträger am Host-System über die Datenträgerverwaltung offline schalten:

(Die Datenträger-Verwaltung erreicht man bei Windows 8 bzw. dem Server 2012 am einfachsten mit [WIN]+[X])

Dann kann man per Rechtsklick auf den gewünschten Datenträger diesen offline schalten:

2. Den Datenträger als Pass-Through-Disk an die Hyper-V VM als neues Laufwerk anbinden:

(Da Hyper-V mit dem SCSI-Controller auch hotplug-fähig ist, klappt dies sogar, während die VM läuft)

Statt einer vorhandenen virtuellen Festplatte wählt man eben unten eine physische Festplatte aus; hier werden nur Datenträger zur Auswahl angeboten, die beim Host offline sind.

3. Datenträger an der VM online schalten und benutzen:

In der Datenträgerverwaltung des Gast-Systems taucht nun eine Festplatte auf, die aber noch offline ist. Analog zum Offline-Schalten im ersten Schritt erfolgt hier nun die Online-Schaltung:

 

Anschließend steht die USB-Festplatte in der Gastbetriebssystem-Umgebung zur Verfügung:

Vor dem Trennen der USB-Platte sollte diese sauber (den bisherigen Weg rückwärts) ausgehangen werden, um Datenverlust o.ä. zu vermeiden.

2 Comments

Windows Server 2012 R2 – Das kommt im neuen Hyper-V

Nachdem kürzlich für Windows Server 2012 ein R2 angekündigt wurde, gibt es nun auch einige Details zu den Änderungen in Hyper-V. Diese möchte ich hier kurz zusammentragen:

Generation-2-VMs

Es wird eine neue Generation für VMs geben, die verschiedene neue Szenarien unterstützen soll, so z.B. das Booten von iSCSI. Dies wird erreicht, indem hier nahezu vollständig auf Emulation von Hardware verzichtet werden soll. Dies funktioniert allerdings nur mit 64-Bit Client-Systemen und nur mit Windows 8 und dem Server 2012 als Gast.

VM Direct-Connect

Bisher ist für einen direkteren Zugriff auf die VM (inkl. Durchreichen von Laufwerken und Zwischenablage) eine RDP-Verbindung nötig, für die wiederum eine Netzwerkverbindung zwischen Gast und Host nötig ist, mit allen damit verbundenen Sicherheitsrisiken und Konfigurationsaufwänden. Mit Direct-Connect werden diese Möglichkeiten künftig auch mit der klassischen VM-Verbindung möglich sein.

Erweiterte Replikation einer VM

Es soll möglich sein, dass ein Host für eine VM nicht mehr nur Quelle ODER Ziel für die Replikation ist, sondern beides. Damit wird es möglich sein, ein Replikat innerhalb des Unternehmens, ein zweites außerhalb aufzubewahren. Vermutlich wird es auch möglich sein, eine VM direkt an 2 Ziele zu replizieren.

Die Replikation unter Server 2012 lässt lediglich ein Intervall von 5 Minuten zu. Im R2 wird es möglich sein, alternativ auch 30 Sekunden oder 15 Minuten zu wählen – je nach Notwendigkeit und Kapazität. Da nach 12 fehlerhaften Versuchen die Replikation unterbrochen wird, hätte man damit die Möglichkeit, 3 Stunden Downtime zu tolerieren.

Kompression & SMB Direct

Bei der Migration von VMs wird es 2 neue Optionen geben: Kompression der zu übertragenden Daten oder Übertragung via SMB Direct (setzt Netzwerkadapter auf beiden Seiten voraus, die RDMA unterstützen). Microsoft empfiehlt bei 10GBps-Links die Nutzung von RDMA, andernfalls die Kompression. Hierbei muss man natürlich den Einfluss der höheren CPU-Last auf die restlichen VMs beachten.

Online Export & Klonen

In Windows Server 2012 muss eine VM erst heruntergefahren/ausgeschaltet werden, bevor sie exportiert oder mittels SCVMM geklont werden kann. In R2 wird dies nun auch bei laufenden VMs möglich sein, wodurch es auch für Produktivumgebungen interessant wird.

Online-Größenänderung von VHDX

Es soll in Windows Server 2012 R2 möglich sein, eine VHDX während deren Nutzung durch eine laufende VM sowohl zu vergrößern, als auch sie zu verkleinern!

Storage-QoS

Der Windows Server 2012 R2 wird eine Möglichkeit bieten, die IOPS einer VM zu beschränken. Damit kann man eine IO-lastige VM begrenzen, um anderen VMs weiterhin eine akzeptable Datenrate auf dem Storage zu ermöglichen.

Dynamic Memory für Linux-VM

Für supportete Linux-Systeme wird es möglich sein, deren RAM-Zuweisung (wie bisher auch bereits bei Windows-Gast-Systemen möglich) dynamisch zu gestalten. Damit werden z.B. größere Ansammlungen von Linux-(Web-)Servern dynamischer.

Shared VHDX

Für Cluster-Szenarien wird es möglich sein, dass 2 VMs eine gemeinsame VHDX nutzen. Damit entfällt die Notwendigkeit, ein CSV auf iSCSI- oder FibreChannel-Basis einzusetzen.

 

Schreibe einen Kommentar...

SCVMM2012: Keine IP-Einstellungen beim Erstellen eines Clusters

Beim Erstellen eines Clusters mit Hilfe vom System Center Virtual Machine Manager 2012 unter Server 2008 R2 auf Hyper-V-Hosts unter Server 2008 R2 hatte ich das „Phänomen“, dass der „Create Cluster Wizard“ die Option für die Cluster-IP nicht anzeigte:

 

Es fehlte einfach der Bereich „IP Adress“, dadurch lässt sich der Wizard auch nicht abschließen. Beim Überprüfen aller in Frage kommenden Faktoren, viel mir auf, dass die Netzwerkkarten der beiden Hyper-V-Hosts kein Gateway eingetragen hatten (IP + Subnetzmaske + DNS passten). Nachdem ich ein Gateway (welches die Hosts gar nicht erreichen können) auf beiden NICs eingetragen habe, zeigte der Wizard auch die entsprechende Einstellung an und erstellt den Cluster erfolgreich.

Im Nachgang habe ich das Ganze dann nochmal nachgestellt und den „klassischen“ Cluster-Assistenten verwendet, der vom Windows Server mitgeliefert wird. Dieser zeigt eine Warnung bezüglich des Gateways, stört sich aber sonst nicht weitere daran und erstellt den Cluster problemlos.

Schreibe einen Kommentar...

Windows 7 als VHD installieren und sowohl nativ als auch in Hyper-V booten

Wenn man eine Windows 7 Installation sowohl nativ als auch in Hyper-V innerhalb eines Server 2008 R2 nutzen will, dann muss man folgendermaßen vorgehen, um am Ende ein und dieselbe Installation auf beide Arten booten zu können:

  • Windows Server 2008 R2 installieren
  • Mit Windows-7 DVD neustarten, Installation starten
  • Mittels [Shift]+[F10] die Commandshell öffnen
  • „diskpart“ starten
    • „create vdisk file=“C:\win7.vhd“ type=expandable maximum=120000″  (für eine 120GB VHD)
    • „select vdisk file=“c:\wim7.vhd““
    • „attach vdisk“
    • „exit“
  • Nun ist die vDisk bei der Auswahl des Zieldatenträgers für die Windows-7-Installation auswählbar
  • Nachdem die Installation durchgelaufen ist, wird ein zweiter Eintrag im Bootmenü erzeugt
  • Nun wieder Server 2008 booten, Hyper-V-Rolle installieren, neustarten
  • Server 2008 booten, Commandshell öffnen
    • diskpart
      • „select vdisk file=“C:\win7.vhd“
      • attach vdisk
      • select part 1
      • active
      • assign letter=V
      • exit
    • Im Commandshell nach V:\Windows\System32 wechseln
      • „bcdboot.exe V:\Windows /s V:\“
      • „bcdedit /store V:\boot\BCD /set {bootmgr} device boot“
      • „bcdedit /store V:\boot\BCD /set {default} device boot“
      • „bcdedit /store V:\boot\BCD /set {default} osdevice boot“
    • Wieder zurück nach C:\
    • diskpart
      • select vdisk file=“C:\Win7.vhd“
      • detach vdisk
      • exit
  • Server 2008 booten, dort im Hyper-V eine neue virtuelle Maschine erzeugen, als Festplatte die win7.vhd auswählen
  • Diese Maschine kann nun aus Hyper-V oder nativ beim starten des physischen Rechners gebootet werden
Schreibe einen Kommentar...