Prozessoren und deren Funktionen sind ein wichtiger Bestanteil für die Server Virtualisierung. In einem älteren Artikel (Hyper-V CPU Anforderungen) wurde bereits detailliert beschrieben, welche Funktionen Hyper-V voraussetzt und wie diese aktiviert werden können.

Anders als bei Memory findet bei Prozessoren generell ein over-commit statt. Das heisst es werden den Virtual Machines mehr Ressourcen zugewiesen, als physikalisch vorhanden sind. Damit dies am Schluss sich nicht negativ auf die Performance der Virtual Machines und den Host auswirkt, sollte die Empfehlung von Microsoft befolgt werden. Aktuell wird die Limite auf ein Maximum von 8 v-procs pro logical Processor festgelegt. Für die beste Performance sollte aber wenn möglich eine Ratio von 1:4 nicht überschritten werden. Um die aktuelle Auslatung auslesen zu können, kann eine Zeile PowerShell Code ausgeführt werden: write-host (@(gwmi -ns root\virtualization MSVM_Processor).count / (@(gwmi Win32_Processor) | measure -p NumberOfLogicalProcessors -sum).Sum) "virtual processor(s) per logical processor" -f yellow

Damit stell Ben Armstrong ein sehr nützliches Hilfsmittel bereits um die aktuelle Auslastung genauer zu prüfen, indem die Anzahl “MSVM_Processor” Instanzen ausgelesen werden um die aktuell laufenden Virtual Machines respektive der zugewiesenen v-procs auszulesen:

(weiterlesen…)

In diesem Artikel wird beschrieben, wie eine Failed VM in Virtual Machine Manager repariert werden kann. Dieses Troubleshooting, auch als “Notes from the field” bekannt, sollte auch aufzeigen wie ein Problem in VMM analysiert werden kann… Zur Situation: Bei einer von VMM verwaltete Virtual Machine wurde jeder Job / jede Änderung abgebrochen. Im Job-Log wurde folgende Fehlermeldung ausgegeben:

Error (12711)
VMM cannot complete the WMI operation on server MyDamagedVM.intra.server-talk.eu because of error: [MSCluster_ResourceGroup.Name="dced5bf8-493b-49b7-8295-ee079d008b1f"] The cluster group could not be found.
(The cluster group could not be found (0×1395))

Recommended Action
Resolve the issue and then try the operation again.

Die Virtual Machine wird in Virtual Machine Manager mit dem Status Failed dargestellt. Ist die VM gestartet, läuft diese zwar uneingeschränkt weiter, allerdings könne in VMM keine  Aktionen mehr ausgeführt werden, selbst die Funktion “Repair” schlägt fehl…

(weiterlesen…)

Die Fragmentierung der Festplattendateien ist vor allem bei I/O-intensiven Anwendungen, wo auch Microsofts Hyper-V dazuzählt, ein Problem. Wie im letzten Artikel “How-To: Verwaltung eines Cluster Shared Volume (CSV)” beschrieben kann mit durchaus mit Boardmittel eine Defragmentierung der Cluster Shared Volumes durchgeführt werden – Der in Windows integrierte Disk Defragmenter ist die erste Anlaufstelle, aber bietet nur einen limitierten Funktionsumfang. Weiter verfügen weder Host und Guests über die Information ob ein System virtualisiert ist (Virtualization Awareness) und können somit den Defragmentierungsvorgang nicht entsprechend abstimmen.

Abhilfe schafft hier V-locity von Diskeeper welche speziell für Hyper-V ausgelegt wurde. Mit der auf virtuelle Plattformen ausgelegten Lösung wird nicht einfach nur eine Defragmentierung ausgelöst – sondern die komplexen Aktivitäten zwischen Host und Guest werden laufend synchronisiert. Eine vollständige Liste der Funktionen von Diskeeper und den Limitationen von Windows Disk Defragmenter gibt es auf der Webseite von Diskeeper.

About Diskeeper V-locity

V-locity überwindet die Barrieren zur vollständigen Effizienz virtueller Systeme, mit einer neuen Technologie, die unsichtbar operiert und keinerlei Konflikte der Systemressourcen verursacht. Auf Windows Plattformen optimiert jede V-locity Komponente das jeweilige Betriebssystem (OS), indem sie Dateien defragmentiert und freien Speicherplatz zusammenlegt. Dies minimiert unnötige I/Os, die vom OS zum Untersystem des Laufwerks gesendet werden und ordnet Daten auf den Laufwerken so an, dass bisher unerreichte Geschwindigkeiten und Ausfallsicherheit erzielt werden.

(weiterlesen…)

Diese Woche hat Nils Kaczenski von faq-o-matic.net ein Artikel zu “LUN auswerfen?!” gepostet. Bei näherer Betrachtung hat sich herausgestellt, dass dieser Server virtuell betrieben wird und die LUNs als Wechselhardware angezeigt werden. Da dies bei manchen Servern sehr unangenehm sein kann, wenn ein Laufwerk einfach so entfernt würde, schauen wir uns die Ursache mal etwas genauer an…

Bei Hyper-V werden Datenträger entweder an einen IDE- oder SCSI-Controller angeschlossen. Da man mit SCSI weitaus eine grössere Zahl von Devices verwalten kann, sowie auch im laufenden Betrieb ohne downtime weitere Hard Disks hinzugefügt werden können, wird empfohlen für Daten Disks ausschliesslich den SCSI-Controller zu verwenden. Auch Pass-through Disks werden mit einem SCSI-Controller konfiguriert.

Nun ist es so, dass alle Hard Disks welche an einem solchen SCSI-Controller angeschlossen sind, als auswerfbar angezeigt werden. Mit einem Klick auf das Task Icon “Safely Remove Hardware and Eject Media” lässt sich die Disk auswerfen (“Eject Msft Virtual Disk SCSI Disk Device”):

Was passiert nun, wenn eine Hard Disk ausgeworfen wurde? Windows Server führt diese Aktion entsprechend durch und die Disk wird auch aus dem Storage Manager entfernt. Diese bleibt solange “verschwunden” bis a) der Server neu gestartet wird, oder b) die VHD in den Virtual Machine Settings re-attached wird. Übrigens, da IDE Hard Disks, wie zum Beispiel auch die System Disk, nicht online hinzugefügt werden können, werden diese Laufwerke auch nicht als auswerfbar angezeigt.

Ironischerweise ist die Anzeige im Device Manager korrekt und die Hard Disk wird nicht als “Devices with removable storage” aufgeführt:

Dieses Verhalten ist auch bei Windows Server 2008 R2 (Beta) mit installiertem Service Pack 1 noch so. Workaround? Eigentlich kein richtiger – “Safely Remove Hardware and Eject Media” kann zum Beispiel von der Taskbar ausgeblendet werden…

By the way – auch bei VMware werden Devices zum Auswerfen angezeigt:

Mit Windows Server 2008 R2 wurde für Hyper-V das Cluster Shared Volume (CSV) eingeführt. Im Artikel “Einblicke in Cluster Shared Volume (CSV)” wurde bereits detailliert darüber berichtet. Mit Cluster Shared Volume (CSV) nimmt allerdings nicht nur die Flexibilität, sondern auch die Komplexität um ein grosses Stück zu. Da durch den Einsatz von “Direct IO” gleichzeitig mehrere Hyper-V Hosts auf das gleiche LUN Zugriff haben, muss für den optimalen Betrieb eine perfekte Ausgangslage bezüglich Network und Storage geschaffen werden. Aber auch Aufgaben aus dem “Daily Business” müssen mit grösster Sorgfalt und bei CSV Volumes oftmals ein wenig anders durchgeführt werden. In den nachfolgenden Abschnitten werden daher die wichtigsten Punkte näher erläutert.

(weiterlesen…)

Vor wenigen Tagen hat Microsoft den TechNet Artikel “Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2″ angepasst. Neu können in einem Failover Cluster pro Host mehr Virtual Machines gehostet werden:

 
Neu können somit generell bis zu 384 Virtual Machines auf einem Hyper-V Host betrieben werden. Anhand von paar konkreten Beispielen kann dies noch besser veranschaulicht werden, wie die Konfigurationen empfohlen werden:

• 5 Node Hyper-V Cluster: 4 aktive Nodes mit jeweils 250 VMs + 1 Failover Node
• 11 Node Hyper-V Cluster: 10 aktive Nodes mit jeweils 100 VMs + 1 Failover Node
• 16 Node Hyper-V Cluster: 15 aktive Nodes mit jeweils 66 VMs + 1 Failover Node

Natürlich müssen auch die Rahmenbedingungen für Hyper-V und die Virtual Machines gegebensein. Wichtig sind vor allem Punkte wie IOPS, Arbeitsspeicher und genügend Bandbreite für Network und Storage.

 
Und was sind die Limits bei VMware?

Diese Anpassung ist besonders auch interessant, wenn man über den Zaun zum Konkurenten VMware schaut. Gemäss der aktuellen Version der Configuration Maximums für VMware vSphere 4.0 ohne/mit Update 1 gelten folgende Limiten:

 
Sonst noch was?

Ja, es wird empfohlen dass in einem Hyper-V Cluster auch ein “Reserved Node” (Passive Node) berücksichtigt wird. Dies bedeutet dass solch ein Host nicht in Gebrauch ist, bis ein anderer Host ausfällt, oder Wartungsarbeiten durchgeführt werden.

Die anderen Empfehlungen und Limiten für Hyper-V gelten nach wie vor. Das heisst es können zum Beispiel maximal 4 CPU’s einer Virtual Machine (je nach Operating System) zugewiesen werden. Zudem sollte eine Ratio von maximal 8 CPU’s pro logical Processor nicht überschritten werden. Für ein System mit zwei Quad Core CPU‘s wären dies dann eine Limite von 64 virtual CPU’s welche den VM’s zugewiesen werden könnten.

Weitere Informationen

• Microsoft TechNet: Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2
• Microsoft TechNet: Hyper-V: Using Hyper-V and Failover Clustering

Von einer Weile hat Microsoft angekündigt, dass Hyper-V Server 2008 R2 (HVS) auch boot von USB Flash Devices (UFD) unterstützt. Somit kann der Hypervisor zukünftig ohne lokale Hard Disks auskommen, ohne an Funktionen zu verlieren. Wenn man die Konfiguration etwas genauer unter die Lupe nimmt, so kann man feststellen dass nicht nur USB Flash Drives als Medium unterstützt werden, sondern dass Hyper-V dazu auch direkt Boot aus einem VHD Image startet.

Anforderungen

• USB Flash Device
  • Standard Storage Device (Class 08h)
  • USB 2.0 kompatibel
  • Non-removable, internal Device
  • Minimum 8 GB Kapazität, Empfohlen 16 GB
  • Plattform Firmware muss Boot von USB 2.x Port unterstützen
• Software
  • Hyper-V Server 2008 R2
  • Windows AIK

Der Vorgang um HVS von einem USB Flash Device starten zu können, umfasst mehrere Schritte. Diese werden nachfolgend im Detail beschrieben…

(weiterlesen…)

Microsoft hat neu ein Component Architecture Poster für Hyper-V bereitgestellt. Wie bereits schon beim Windows Server 2008 R2 Components Poster werden auf dieser A3 Seite die wichtigsten Funktionen einfach dargestellt. Es werden folgende Komponenten im Hyper-V Architecture Poster beschrieben:

• Architecture
• Virtual Networking
• Virtual Machine Snapshots
• Live Migration
• Storage Interfaces
• Storage Types
• Storage Location and Paths
• Import and Export

(weiterlesen…)

Schon seit mehreren Jahren stellt Microsoft ihren Kunden mit “Best Practice Analyzer” (BPA) ein kostenloses Tools um die eigene Infrastruktur zu überprüfen, wie zum Beispiel die Konfiguration des eigenen Exchange Servers. Nachdem BPA eine Installation überprüft hat, werden Abweichungen von bewährten Einstellungen aus der Praxis dem Administrator aufgezeigt.

Mit Windows Server 2008 R2 hat Microsoft nun auch diverse Best Practice Analyzer für folgende Rollen eingeführt:

• Active Directory Certificate Services
• Active Directory Domain Services
• Domain Name System
• Internet Information Services
• Remote Desktop Services

(weiterlesen…)

Microsoft empfiehlt für den produktiven Einsatz von Hyper-V den Core Installation Mode zu wählen. Denn die Vorteile des Server Core liegen für die Virtualisierung eigentlich ganz klar auf der Hand:

• Wartung - Da bei einer Server Core Installation nur das installiert wird, was zur Verwaltung einer Rolle erforderlich ist, fällt weniger Wartungsaufwand an.
• Angriffsfläche – Systemdateien sind nur in minimalem Umfang installiert. Dadurch dass nur wenige Dienste und Anwendungen laufen, verringert dies die Angriffsfläche.
• Management - Da auf einem Server im Core Installation Mode nur wenige Applikationen und Dienste vorhanden sind, sinkt der Verwaltungsaufwand.
• Speicherplatzbedarf – Server Core benötigt zur Installation nur etwa 1 Gigabyte (GB) Disk Space. Im Anschluss daran sind beim Betrieb lediglich rund 2 GB erforderlich.

Wie die Installation von Hyper-V auf Basis von Server Core durchgeführt werden kann, wird in einem älteren Artikel bereits beschrieben. Mit dem in Windows Server 2008 R2 hinzugefügten “sconfig” geht dies  inzwischen ganz flott. Nun hat sich herausgestellt, dass bei manchen ProLiant Server von HP zu Problemen kommen kann. Beim Anlegen des Failover Cluster wird folgende Fehlermeldung angezeigt:

An error occurred while creating the cluster. An error occurred creating cluster ‘clustername’.
The service has not been started.

(weiterlesen…)