RSS

RSSAlle Einträge in der "Hypervisor" Category

Update: NAT-Switch für Hyper-V im Windows Server 2016 TP5

Vor einiger Zeit hatte ich hier einen Beitrag veröffentlicht über einen neuen NAT Switchtyp im Hyper-V, der es ermöglichte, dass VMs in einem internal Hyper-V Netzwerk mit der Außenwelt bzw. mit dem Internet kommunizieren können. Diese Informationen bezogen sich auf die Technical Preview 4 von Windows Server 2016 bzw. Windows 10 Build 10586 (November 2015 Update 1511).

Nun hat Microsoft vor ein paar Tagen die Technical Preview 5 von Windows Server 2016 und auch eine neue Windows 10 Insider Preview (Build 14332) veröffentlicht, in denen die Implementierung für NAT geändert wurde. Den Switchtyp NAT gibt es nicht mehr und damit ist auch meine seinerzeitige Beschreibung hinfällig. Vielmehr gibt es jetzt eine Anleitung, wie man auf Basis eines internen Hyper-V Switch ein NAT-Subnetz einrichten kann. Diese neue Vorgehensweise soll hier kurz beschrieben werden einschließlich von 2 Powershell Funktionen, die dies etwas vereinfachen.

Windows Server 2016: Gerätebenennung der Netzwerkkarten

Eine der kleinen, aber coolen Änderungen in der nächsten Version von Microsofts Server-Betriebssystem ist die Möglichkeit, virtuelle Netzwerkkarten unter Hyper-V mit einem sprechenden Namen zu versehen. Die Funktion des Umbenennen einer Netzwerkkarte in der Hyper-V Konfiguration gibt es mit dem Windows Server 2012 R2 aktuell auch schon, hier gibt es allerdings innerhalb der VM keine Möglichkeit, den “von außen” vergebenen Namen auszulesen oder zu benutzen. Besonders für eine Automatisierung ist dies natürlich eine sehr gute Funktion. In der aktuellen Preview-Version von Windows Server 2016 lässt sich die Funktion schon nutzen, hier eine kurze Beschreibung mit ein paar Screenshots.

Windows Server 2016 und Windows 10: NAT-Switch für Hyper-V

Achtung: Der Inhalt dieses Artikels bezieht sich auf ältere Versionen von Windows Server 2016 bzw. Windows 10 und ist überholt. Eine aktualisierte Fassung dieses Artikels finden Sie hier.

Der Windows Server 2016 und auch die aktuellen 64-Bit Versionen von Windows 10 Pro bringen im Hyper-V neben den bisherigen virtuellen Netzwerk-Switches external, internal und private einen neuen Switchtyp NAT mit. Damit ist es möglich, ohne zusätzliche Komponenten VMs, die mit einem internal Netz verbunden sind, auch mit der Außenwelt bzw. dem Internet kommunizieren zu lassen.

Okay, bei VMware Workstation oder auch VirtualBox gab es diese Funktionalität schon immer. Bei Hyper-V musste man sich jedoch bisher damit behelfen, eine VM als Router zwischen dem internal Netz und einem external Netzwerkadapter des Hyper-V Hosts zu konfigurieren (z.B. über Routing und RAS eines Windows Servers oder über das Internet Connection Sharing). Diesen Aufwand kann man sich jetzt mit dem NAT-Switch sparen.

Leider versteckt sich die Beschreibung dieser Neuigkeit ganz tief in der Technet Library und auch in den Microsoft-Veröffentlichungen zu den jeweiligen Betriebssystemen sucht man vergebens danach. Ich will hier deshalb mal näher beschreiben, wie man damit umgeht.

Rebalancing von Verbindungen in einem Scale-Out File Server

In einem aktuellen Projekt bin ich dabei, einen Scale-Out File Server aufzubauen. Dieses Mal werden als Speicher keine JBODs mit Festplatten und SSDs genutzt; im Hintergrund steht stattdessen ein per Fibre Channel angeschlossenes SAN. Bisher wurden die LUNs im Hyper-V Failover Cluster direkt an alle zwölf Hyper-V Hosts angebunden, dies bedingt jeweils FC-Adapter in den Hosts. In dem aktuellen Projekt werden zwischen die Hypervisor und dem SAN zwei Server gebaut, die eine hochverfügbare Dateiserver-Rolle im Failover Cluster betreiben (ein Scale-Out File Server, kurz SOFS).

Live Migration schlägt mit Event ID: 21502 fehl

Vorlage-Button-WinServ2012R2_thumb.jpgWir hatten heute bei unserem Hyper-V 2012 R2 Failovercluster das Problem, dass wir die Live Migration nur noch von einem Host aus durchführen konnten, beim zweiten Hyper-v Host bekamen wir folgende Fehlermeldung:

Probleme bei der Nutzung von Teaming unter Windows Server 2012 R2

Vorlage-Button-WinServ2012R2_thumbIn einem unserer Projekte hatten wir neulich den Fall, dass die Nutzung von Netzwerkkarten-Teaming dazu führte, dass die Server manchmal nicht reagierten, sich teilweise mit einem Bluescreen verabschiedeten und manchmal einfach in dem aktuellen Fenster einfrierten. Dieses Verhalten ließ sich besonders gut rekonstruieren, wenn ein NIC Team erstellt und danach wieder entfernt wurde. Das Verhalten trat auf mehreren Servern auf, eine wirkliche Gemeinsamkeit ließ sich jedoch nicht wirklich feststellen.

Cisco UCS Blade Profile Settings für Hyper-V

imageMomentan arbeite ich in einer Kundenumgebung in der eine Menge Cisco UCS System verwendet werden. Es hat sich herausgestellt, das wir bei bestimmten VMs (Windows Server 2008 R2 mit 4 vCPUs) auf Hyper-V und VMware sehr unterschiedliche Performance feststellen.  Wir messen bei einem Test unter Hyper-V 30 Sekunden und mit der gleichen VM und dem gleichen Test auf VMware 13,5 Sekunden. Wenn VMware langsamer wäre könnte ich damit leben aber andersherum – das geht gar nicht.

Nach langem Testen sind wir dann auf die BIOS Einstellungen gekommen die offensichtlich drastische Effekte bei den beiden Hypervisoren haben. Wer jetzt nach UCS BIOS Settings für Hyper-V sucht wird nicht fündig und für VMware und Virtualisierung bekommt man im wesentlichen die zwei Dokumente die ich weiter unten im Post verlinkt habe. Leider sind diese nicht hundertprozentig genau und zum Teil sogar widersprüchlich.

Deswegen haben wir experimentiert und die  für unser Szenario besten Werte herausgespielt (mit den neuen Werten läuft der Test unter Hyper-V  mit 12 Sekunden). Die wichtigen Werte, die dabei die Verlangsamung gegenüber VMware verursachten, sind die Prefetcher (Hardware Prefetcher, Adjacent Cache Line Pre-fetcher, DCU Stream Pre-fetcher und DCU IP Pre-fetcher). Diese waren auf Platform Default eingestellt was in unserem Fall eingeschaltet bedeutete.

Hier alle Settings nochmal als Text und im Screenshot:

Backup-Jobs schlagen nach November Update Rollup fehl

Gestern wurde von Taylor Brown, seines Zeichens nach Microsoft Hyper-V Program Manager, auf seinem MSDN Blog ein Artikel veröffentlicht, auf dem er darauf hinweist, das es nach der Installation des November Rollups zu Problemen mit Backup Jobs kommen kann.

Bis das Problem behoben wurde, empfiehlt Microsoft das Hotfix-Update (KB2996928) einzuspielen.

Ihr könnt das Hotfix-Update KB2996928 hier downloaden!