Integrations-Dienste

Jede neue Hyper-V Version brachte eine neue Version der Integrationsdienste für die virtuellen Maschinen mit. Vereinzelt gab es Windows-Updates für die Hosts, die ebenfalls eine neue Version der Integrationsdienste mit an Board hatten. In beiden Fällen war in der Vergangenheit ein Update der Integrationsdienste der VM erforderlich, was einen Neustart erforderlich machte und schwer zu verwalten war. Aus diesen Gründen werden in der Technical Preview die Integrationsdienste vom Host-OS getrennt und für die Gast-Betriebssysteme komfortabel via Windows Update / WSUS verteilt.

Linux Secure Boot

Ausgewählte Linux-Distributionen, derzeit Ubuntu 14.04 oder spätere Versionen sowie Suse Linux Enterprise Server 12 unterstützen nun Secure Boot.

Energieverwaltung

Hyper-V hat insbesondere für Client Hyper-V bessere Energiesparmethoden dazu gelernt und unterstützt nun sogar connected standby.

Grafik-Virtualisierung

Support für OpenGL 4.4 und OpenCL

In früheren Versionen von Hyper-V war es möglich das Netz bereits zugeordneter virtueller Netzwerkkarten im Betrieb zu wechseln, für andere Veränderungen musste man die virtuelle Maschine jedoch stoppen.

Mit der Technical Preview ist es möglich Netzwerkkarten für Virtuelle Maschinen der Generation 2 im laufenden Betrieb hinzuzufügen und zu entfernen, die entsprechenden Einstellungen sind in der GUI nicht mehr ausgegraut:

Neu hinzugefügte Netzwerkkarten tauchen sofort in der neuen virtuellen Maschine auf:

Während uns bei physischen Systemen die Netzwerkkarten dank CDN (Consistent Device Naming) automatisch richtig benannt werden, fehlt uns mangels PCI-Express Bus in der VM diese Funktionalität. Wir können jedoch die Adapter vom Host aus umbenennen um auch in virtuelle Maschinen eine eindeutige Zuordnung der vNics zu haben über das "Device Naming" genannte Feature. (Gen2 VMs, Technical Preview als Guest-OS) Hierzu verwenden wir erneut PowerShell:

Rename-VMNetworkadapter -VMName <Vmname> -Name "Network Adapter" - NewName "Name"

In den Eigenschaften der VM ist der neue Name sofort sichtbar:

Für die korrekte Darstellung in der VM ist ein Reboot erforderlich, dann ist der neue Name Read-Only in den Eigenschaften der VM sichtbar. Er kann aus der VM heraus nicht geändert werden, sondern nur vom Host-Administrator.

Auch bei der Änderung von Arbeitsspeicher hat sich einiges getan, so kann selbst statischer Arbeitsspeicher für VMs mit Technical-Preview OS im Betrieb geändert werden:

Sowohl das Hinzufügen als auch das Entfernen von Arbeitsspeicher klappt auf diese Weise. Es wird beim Entfernen überprüft, dass dem Betriebssystem noch genügend Arbeitsspeicher zur Verfügung steht, ansonsten schlägt der Vorgang fehl.

Jedes Mal, wenn ein Snapshot einer virtuellen Maschine erstellt wird, wird eine neue differenzielle Festplatten-Datei (.avhdx) zur Original-Festplatte der VM erzeugt. Alle Änderungen an der VM werden ab sofort in diese neue differenzielle Festplatten-Datei geschrieben. Möchte man zum Ursprungszustand zurückkehren wurden erstellte Snapshots angewendet, was nichts anderes bedeutet, als dass die erstellte Änderungsdatei gelöscht wurde und die VM "nur" mit der Original-Festplatte gestartet wurde.

Wurde der Snapshot gelöscht, wurde die differenzielle Disk mit der Original-Disk zusammengeführt und eine Rückkehr zum Snapshot war nicht mehr möglich.

Snapshots haben im Laufe der Zeit und Hyper-V Versionen zwar einige Verbesserungen erfahren, so können Sie mittlerweile online zusammengeführt werden und sie wurden aus Konsistenzzwecken umbenannt zu Checkpoints, für produktive Workloads waren sie aber nie richtig empfohlen.

Der Grund dafür ist ein relativ simpler:

Die Workloads in der virtuellen Maschine haben von den an der virtuellen Maschine vorgenommenen Checkpoint-Operationen fast nichts mitbekommen. Dies lässt insbesondere für Anwendungen wie Exchange Server und co einige Risiken offen. Für Active Directory Domain-Controller wurde daher mit Windows Server 2012 zusätzliche Maßnahmen zur Konsistenzsicherung getroffen.

Die mit der Technical Preview eingeführten Production Checkpoints bietet nun workloadunabhängigen Schutz, in dem sie nicht auf Saved-States sondern auf VSS setzen. Production Checkpoints nutzen daher die gleichen Mechanismen wie Backup-Software (Bei Linux-Systemen wird der Dateisystem-Cache geleert). Jeder Workload, der VSS Backups unterstützt, sollte damit auch Production-Checkpoints unterstützen können.

Die Konfiguration für Checkpoints ist sehr granular geworden. Sie können vollständig deaktiviert werden und die Art des Checkpoints kann ausgewählt werden, die bisherigen Checkpoints heißen nun Standard-Checkpoints.

In der Standard-Konfiguration sind Checkpoints aktiv, primär werden Production Checkpoints erstellt und im Fehlerfall wird versucht einen Standard-Checkpoint zu erstellen (z.B. bei VSS Fehlern).

Nach einem Restore eines Production-Checkpoints sieht eine VM genauso aus, wie aus einem Backup wiederhergestellt, sie ist also im Gegensatz zum Standard-Checkpoint ausgeschaltet.

Achtung: Auch wenn Checkpoints nun "Backup-Technologie" nutzen, können Sie den Einsatz einer ganzheitlichen Backupstrategie und deren Produkte nicht ersetzen.

In der Technical Preview ist das Upgrade bestehender Hyper-V Cluster ohne Downtime möglich. Beim Rolling Cluster Upgrade genannten Feature können Server mit Technical Preview OS bestehenden Hyper-V Clustern mit Windows Server 2012 R2 hinzugefügt werden können. Virtuelle Systeme können in beide Richtungen (!) im Cluster Live migriert werden, ein Fail-Back ist möglich. Erst wenn man sich sicher ist, dass alle Services vollständig und korrekt laufen, werden die verbleibenden Knoten im Cluster auf die nächste Version des Windows Servers aktualisiert und das Cluster-Level wird aktualisiert.

Selbst der Betrieb eines Hyper-V Clusters mit Hosts ausschließlich auf der Technical Preview ist möglich und erst nach einem Upgrade des Cluster-Levels ist ein Failback innerhalb des Clusters nicht mehr möglich. Mit dem Cluster-Level wird das Funktionslevel des Clusters und damit die verfügbaren Feature innerhalb des Clusters bestimmt.

Ein Hochstufen der VM-Version ist z.B. erst bei aktualisiertem Cluster-Level möglich.

Windows Server 2012 R2 verwendet das Cluster-Level 8, die Technical Preview das Cluster-Level 9. Auslesen und Anpassen des Clusters erfolgt derzeit ausschließlich via PowerShell:

Auslesen des aktuellen Cluster-Level:

Get-cluster | fl ClusterFunctionalLevel

Update des Cluster-Levels:

Update-ClusterFunctionalLevel

Windows typisch gibt es eine Sicherheitsabfrage:

Und anschließend ist das Cluster-Level auf Version 9 angehoben.

Achtung: Befinden sich noch nicht alle Clusterknoten auf der Tech-Preview schlägt der Vorgang fehl:

Aus diesem Grund erfolgt in der Technical Preview für Windows Server kein automatisches Upgrade mehr von Hyper-V Versionen.

So ist es möglich auf Hyper-V Hosts mit der Technical Preview virtuelle Maschinen mit älteren Versionen (wie z.B. der Version 5.0 aus 2012 R2 zu betreiben) zu betreiben. Dies ermöglicht eine Abwärtskompatibilität mit älteren Hosts, die neuen Features stehen der virtuellen Maschine jedoch erst nach einem Upgrade auf die VM-Version aus der Technical Preview (6.0) zur Verfügung. Neben der Option eines Fallbacks werden auch die Upgrade-Wege vereinfacht und ermöglichen Rolling Cluster Upgrades.

Neue virtuelle Maschinen werden weiterhin in der höchsten VM-Version erstellt. Die jeweils verwendete VM-Version ist in der GUI dem Hyper-V Manager zu entnehmen:

Oder via PowerShell:

Get-VM -Name <vmname>  | fl version

Das Upgrade erfolgt ausschließlich via PowerShell mit CMDlet:

Update-VmConfigurationVersion <vmname>

Nach einem Upgrade befindet sich die VM dann auf Version 6.0.

Achtung: Bei einem Fehlschlagen des CMDlets erfolgt derzeit keine Fehlermeldung, daher sollte hinterher die Version unbedingt überprüft werden.

Wer alle seine virtuellen Maschinen nach einer Migration auf die neue Version upgraden möchte, kann dazu das folgende PowerShell Script von Brandon Linton benutzen:

$VMs = Get-VM *

Foreach( $VM in $VMs){

If ($VM.Version -ne '6.0'){

Write-Host "Stopping VM:"$VM.Name

Stop-VM $VM.Name

Write-Host "Updating VM Version" $VM.Version " on " $VM.Name

Update-VmConfigurationVersion $VM.Name -Force

Write-Host "Starting VM:"$VM.Name

Start-VM $VM.Name

       }

}

Nach einem Upgrade der VM Konfiguration ist die VM-Konfiguration keine XML-Datei mehr, sondern besteht aus zwei getrennten Dateien (.vmcx und .VMRS).

Diese Binär-Dateien sollten niemals direkt bearbeitet werden und erlauben schnellere Lese- und Schreibzugriffe auf die VM-Konfiguration, zusätzlich bieten Sie einen höheren Schutz vor Datenverlust.

Downlevel Host Management

Bisher war der Hyper-V Manager der jeweiligen Betriebssystemversion ausschließlich in der Lage Hyper-V Systeme der gleichen Versionsnummer zu verwalten, unabhängig ob Hyper-V auf einem Client- oder Serverbetriebssystem betrieben wird. Über die Remote-Server-Administration-Tools (RSAT) konnte man sich zudem auf anderen Systemen die passende Version installieren.

In der Technical Preview für Windows Server ist das erstmals anders, hier kann über den Hyper-V Manager neben der Technical Preview auch Hyper-V Hosts mit Windows Server 2012 R2 und Windows Server 2012 verwalten. Vermutlich klappt das auch mit Hyper-V auf den korrespondierenden Client-Betriebssystemen Windows 8.1 und 8. Um das neue Feature zu verwenden, ist nichts Besonderes zu berücksichtigen, die Verbindungen werden genauso zu Downlevel Hosts aufgebaut, wie zu Hosts der Technical Preview selbst.

Wie immer ist ausschließlich der aktuelle Hyper-V Manager in der Lage die Technical Preview selbst zu verwalten, es gibt jedoch auch bereits eine Preview für RSAT-Tools zum Download:

http://www.microsoft.com/en-us/download/details.aspx?id=44280

Achtung: Anders als in den System-Anforderungen angegeben kann der Download nur auf Windows 10 Preview Systemen und NICHT auf Windows 8.1 installiert werden.

Alternative Anmeldeinformationen und IP-Adressen

Die Verwendung von Remote-Verbindungen zu anderen Hyper-V Hosts über den Hyper-v Manager erfolgt in der Vergangenheit mit den Anmeldeinformationen des aktuell am Betriebssystem angemeldeten Benutzers. Dies ist auch in der Technical Preview weiter der Standard, jedoch gibt es im Verbindungsdialog des Hyper-V Managers die Möglichkeit alternative Anmeldeinformationen für die Verbindung zu verwenden. Auch die Verbindung mit IP-Adressen statt DNS Namen ist nun erfolgreich.

Die verwendeten Anmeldeinformationen können gespeichert werden und erleichtern so die wiederholte Verbindung zu denselben Hosts.

Achtung: In der Technical Preview gibt es Schwierigkeiten, wenn die Anmeldung am OS nicht mit einem lokalen oder Domänenbenutzer, sondern mit einer Microsoft ID (der ehemaligen Live ID) erfolgt.

Neues Verwaltungsprotokoll

Der Hyper-V Manager nutzt in der Technical Preview das WS-MAN Protokoll für die Verbindung zum Host. Die Authentifizierung erfolgt dabei wahlweise über CredSSL, Kerberos oder NTLM. Dadurch sind Live-Migrationen zwischen Hosts möglich, ohne zunächst Delegierungen im Active Directory einrichten zu müssen. Auch das remote Management wird vereinfacht, da ab sofort (der meistens geöffnete) Port80 für die Verbindung verwendet wird.

Wie üblich fehlen dem Client-OS einige Hyper-V Features wie Live-Migration oder Hyper-V Replica. Diese sind in der Server Technical Preview erhalten (Build 9841), der Download erfolgt hier:

http://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

In Hyper-V stecken zahlreiche neue Features, die ich auf diesem Blog vorstellen werde. Wer System-Center einsetzen möchte, um das neue Betriebssystem zu verwalten benötigt dazu die System Center Technical Preview. In den einzelnen Komponenten finden sich bisher nur wenige Neuerungen, im Wesentlichen ging es zunächst darum Kompatibilität zur Windows Server Technical Preview sowie SQL Server 2014 herzustellen. Der Download der System Center Technical Preview erfolgt hier:

http://www.microsoft.com/en-us/evalcenter/evaluate-system-center-technical-preview

Ein Releasedatum für die finale Version der nächsten Version vom Windows Server ist derzeit ebenso wenig bekannt wie der Name. Es ist jedoch mit weiteren aktualisierten Preview-Builds in den nächsten Wochen / Monaten zu rechnen.

Ein Einsatz der Technical Preview Versionen sollte ausschließlich in abgetrennten Test-, Labor- und Entwicklungsumgebungen erfolgen, der frühe Entwicklungsstatus ist nicht für einen produktiven Systembetrieb geeignet und schon gar nicht supported.

Die Aktivierung und Konfiguration der Hyper-V Rolle und die Benutzung via PowerShell und dem Hyper-V Manager erfolgen in der Preview erfolgen genauso wie in der aktuellen Hyper-V Version mit Windows Server 2012 R2. Eine wichtige Unterscheidung gibt es jedoch in den Systemvoraussetzungen. Wie bereits bei Windows 8 / Windows 8.1 ist ab sofort auch bei den Server-Systemen von Hyper-V das CPU-Feature Second Level Adress Translation (SLAT) erforderlich.

Hier eine Kurzübersicht der neuen und veränderten Funktionalitäten, auf die ich in weiteren Blogposts näher eingehen werde:

• Verbesserter Hyper-V Manager
• VM Versionen und deren Upgrades
• Rolling Cluster Upgrades
• Update der Integrationsdienste über Windows Update
• Neues Dateiformat für virtuelle Maschinen
• Change-Log Tracking für Backup
• Ressourcen zu virtuellen Maschinen hinzufügen und entfernen
• Netzwerkkarten-Benennung
• Production-Checkpoints
• Hyper-V Replica Verbesserungen
• Sonstige Änderungen

Die Produktgruppen des System Center Virtual Machine Manager (SCVMM) und des Windows Azure Packs sammeln derzeit das Feedback von Kunden über verschiedene Wege ein. Ein Weg ist die direkte Möglichkeit über eine Befragung und diese wird Blogs veröffentlich.

Für Windows Azure Pack

Link: http://blogs.technet.com/b/privatecloud/archive/2014/06/16/we-39-re-listening-contribute-your-feature-suggestions-for-windows-azure-pack.aspx

Für System Center Virtual Machine Manager (SCVMM)

Link: http://blogs.technet.com/b/scvmm/archive/2014/06/11/the-vmm-team-wants-you-to-tell-us-what-you-want.aspx

Also los :-)

Viel Spaß beim Virtualisieren

Alexander Ortha (Technischer Berater Microsoft Server Datacenter & Private/Hybrid Cloud)

Am 30.01.2014 habe ich mit Alexander Ortha gemeinsam einen Vortrag bei der Deutschen Hyper-V Community gehalten. Wir haben eine ganze Menge unserer gesammelten Best Practices zu Hyper-V und System Center Virtual Machine Manager erläutert und im folgenden Video festgehalten:

[View:https://www.youtube.com/watch?v=_cE7tAJzYLo:0:0]

Behandelt werden unter anderem die Themen:

• Hardware-Kompatibilität

• CPU Konfiguration

• Antivirus

• Performance Tuning

• Rollenkombinationen

• Pagefile und Firewall-Konfiguration

• Energiesparoptionen

• Netzwerkkonfigurationen

• VM Sizing

• SCVMM Add-Ons

• SCVMM Library

• SCVMM Service Templates

• SCVMM Update Deployment

• SCVMM und Integrationsdienste

Wenn Ihr Anmerkungen oder weitere Ideen zu dem Thema habt, lasst es uns bitte in den Kommentaren wissen.

Ebenso gibt es eine es auf dem Hyper-V Community Meeting entstandene Aufzeichnung von Carsten Rachfahls Erfahrungen rund um Storage Spaces mit SMB3, welches ihr hier findet.

Viel Spaß mit den Videos wünschen

Benedict Berger und Alexander Ortha

Im PowerShell Script Downloader.ps1 versteckt sich eine komplette Download-Engine für:

• Alle System Center 2012 SP1, System Center 2012 R2 und Windows Azure Pack Installationsvoraussetzungen

• System Center 2012 SP1 und Windows Server 2012

• SQL Server 2008 R2 und SQL Server 2012 Installationsmedien

• Sharepoint Foundation Installationsmedien für SC Service Manager Self-Service Portal

• Windows Automated Deployment Toolkit 8.1

Nach dem Download befinden sich ca. 15GByte Installationsmedien auf der Festplatte. Zusätzlich wird die Ordnerstruktur angelegt, in die die Datenträger von Windows Server 2012 R2 Update und System Center 2012 R2 abgelegt werden. Der Download dieser Datenträger erfolgt manuell, da dazu eine Microsoft-ID erforderlich ist. In die vorbereiteten Ordner werden dazu die 180 Tage-Testversionen von den TechNet Evaluierungsseiten gespeichert, oder aber die Vollversionen aus dem eigenen Volumenlizenzportal. Bis auf eine Ausnahme ist die Quelle der Installationsdatenträger egal. Wird kein Produktschlüssel in der Variable.xml Datei angegeben wird immer eine 180 Tage-Testversion verwendet, sobald ein Produktschlüssel angegeben wird. Die Ausnahme ist in diesem Fall der System Center Data Protection Manager (alle Versionen). Hier reicht es nicht aus, durch die Eingabe eines Produkt-Schlüssels den Datenträger der Testversion in eine Vollversion umzuwandeln, in diesem Fall sind zwingend die Datenträger aus dem Volumenlizenzportal erforderlich. Die Ordnerstruktur unterhalb des Pfades Installer\SystemCenter2012R2 wird folgendermaßen benannt:

Die Installationsmedien werden automatisch entpackt, SQL Service Packs werden in die Installationsquellen geslipstreamed und eine saubere Ordnerstruktur für die Systemvoraussetzungen wird erstellt:

Die Downloader.ps1 benötigt selbst einige Systemvoraussetzungen. Das PowerShell Script wird ausgeführt auf einem Betriebssystem mit Windows 8 oder Windows Server 2012 oder höher, damit die Iso-Dateien direkt im Betriebssystem gemounted werden können.

Des Weiteren ist auf diesem System ein installiertes WinRar oder 7Zip erforderlich um den Exstraktionsvorgang durchführen zu können.

In der Downloader.ps1 selbst sind dabei keine Downloadlinks o.ä. verlinkt, dort befindet sich lediglich die Intelligenz des Downloadmanagers. Der Downloader ist in der Lage bereits vorhandene Dateien zu erkennen und zu überspringen und abgebrochene Downloads fortzusetzen bzw. zurück zu setzen. Die Downloadlinks und deren Validierungen sind enthalten in der Workflow.xml:

Hier am Beispiel der SQL Reporting Services für die Sharepoint Instanz mit einer Validierung der Dateigröße. Die Validierung erfolgt oft über Dateigrößen (in Bytes) oder Versionsnummern. Bei einem neuen Release der Subkomponenten kann es erforderlich sein – bis zum nächsten PDT Release – hier eine manuelle Anpassung vorzunehmen, damit die Downloads und Installationen erfolgreich sind.

Mit der Standardkonfiguration nutzt die Downloader.ps1 den \temp\ Pfad auf dem Systemlaufwerk, in der Variable.xml des PDTs ist dies ggf.  anzupassen:

Die Variable Download gibt den Ablageort des Downloaders an, SourcePath den Ort der entpackten Installationsquellen.

Möchte man nicht die gesamten Dateien herunterladen, sondern ausschließlich die Dateien, die für das derzeit – in der Variable.xml -  konfigurierte System Center Deployment erforderlich sind, verwendet man den folgenden Schalter:

.\Downloader.ps1 –DeploymentOnly

Damit haben wir nun alles beisammen um unser Deployment zu starten, im nächsten Schritt unserer Blogserie werfen wir einen intensiven Blick auf den PDT VMCreator zur automatischen Erstellung von virtuellen Maschinen.

Mit besten Grüßen,

Benedict Berger