Markus Bäker

Im Rahmen einer Vortragsserie haben ein Kollege und ich die Neuerungen in Windows Server 2012 vorgestellt.  In diesem Post möchte ich diese nochmal zusammenfassen und einige Details erklären:

In folgenden Bereichen sehe ich Neuerungen:

Limits

• 64vCPUs per Guest
• 4TB per Host
• 320 logical CPUs pro Host
• 1TB pro VM
• 64 Cluster Nodes
• 4000 VMs pro Cluster

Memory Read more…

Im letzten Teil dieser Serie schauen wir uns den System Center 2012 Virtual Machine Manager (SCVMM) an. Hier gibt es wieder einige ganze Reihe von Verbesserungen. Die Verbesserungen teilen sich in zwei Hauptgebiete auf: Dienste und Cloud-Unterstützung und auf der anderen Seite Fabric Management.

Dienste und Cloud-Unterstützung:

• Service Livecycle Management:
• Dienste in SCVMM werden als Template definiert und darüber auch aktualisiert.
• mit SCVMM 2012 können Serveranwendungen jetzt auch über Server App-V abstrahiert werden
• Das komplette Deployment inkl. Load-Balancing, erstellen von VMs, Einbinden von SQL-Datenbanken, Rollout von Webanwendungen wird jetzt unterstützt
• Cloud Verwaltung:
• Clouds können erstellt werden und an Benutzer/Gruppen delegiert werden
• Innerhalb der Cloud kann ein Benutzer die ihm erlaubten Rechte ausüben: z.B. VMs erstellen, löschen, Snapshots, …
• Die Anzahl und Ausstattung der VMs kann wiederum über Quotas begrenzt werden

Fabric Management:

• Infrastruktur:
• Erweitertes Powershell
• VMM Server kann geclustered werden
• automatisierte Updateinstallation von Hyper-V Servern (Live Migration, Updates installieren, Neustart, Kontrolle, Live Migration, …)
• Ressourcenoptimierung:
• verbesserte dynamische Optimierung des Hyper-V Clusters
• Power Optimization: Herunterfahren von Hyper-V Knoten bei geringer Last
• für das Monitoring ist jetzt kein SCOM mehr notwendig. Auslastung der Knoten wird jetzt direkt vom VMM Agent gemessen
• Fabric Management
• Unterstützung von XenServer 6.0+
• Bare Metal Provisionierung von Hyper-V Clustern (Anschalten neuer HW per BMC, PXE Boot in WinPE, Download VHD mit Hyper-V Image, bootfähig machen, Integration von weiteren Treibern, Aufnahme in das AD, Aufnahme in einen Cluster, …)
• Verbessertes Netzwerkmanagement mit VLAN Unterstützung
• Verbessertes Storagemanagement durch Unterstützung der SMI-S Schnittstelle

Wer die Powershell Module von SCVMM und die Community Module zu Hyper-V gleichzeitig benutzen will, bekommt bei einigen Funktionen einen Konflikt.

Eigentlich sind alle Funktionen vom SCVMM eindeutig mit einem SC bezeichnet. So heißt die Funktion, um das Objekt einer Virtuellen Maschine zu erhalten get-SCVirtualMachine. Wahrscheinlich aus historischen Gründen gibt es aber eine Alias namens “get-VM” auf diese Funktion.

Die CodePlex Hyper-V Funktionen haben keinen gesonderten Namensraum. Hier heißt die Funktion für die Virtuelle Maschine einfach get-VM. Dies wäre nicht so schlimm, wenn die Funktion nicht auch intern fleißig genutzt wird. Möchte man die CodePlex Funktionen nutzen, um Differenzielle Disks zu erstellen (etwas  was der SCVMM auch in 2012 nicht anbietet), so funktioniert dies nicht mehr, wenn beide Module geladen sind.

Die direkte Lösung wäre daher, den Alias auf get-SCVirtualMachine wieder zu entfernen.   Neue Aliase sind einfach per “new-Alias” erstellbar. Eine Funktion namens “remove-Alias” existiert aber nicht, da ein Alias für die aktuelle Sitzung definiert und dort auch bis zum Ende bestehen bleibt.

Trotzdem kann man einen Alias mit der generischen Funktion remove-item entfernen. Hier heißt der Alias “Alias:get-VM”. D.h. wie bei der Bezeichnung “ftp:sdfsdf” oder “c:\get-vm” steht Alias: für das Protokoll bzw. den Namensraum, damit die Funktion weiß, an welches Modul sie den Löschbefehl weitergeben muss. Hier ein Beispiel:

$alias= Get-Alias | where {$_.name -eq "Get-VM"}
if ($alias -ne $null) {
   $itemName=$alias.CommandType.ToString()+":"+$alias.name
   Remove-Item $itemName
}

In diesem Blogpost werde ich die Arbeit mit den neuen Custom Properties im SCVMM 2012 vorstellen.

In Vergangenheit gab es eine Reihe von vordefinierten Custom Properties (1-10). Mit SCVMM 2012 gibt es beliebige Erweiterungsfelder, die als Objekt abgebildet sind und an Virtuellen Maschinen, Hosts, Clouds und anderen Objekten hängen können.

Diese Objekte kann man in Powershell mittels get-SCCustomProperty abrufen. Diese Objekte beinhalten aber noch keine Werte, sondern stellen nur die Schlüssel dar. Die eigentlich eingestellten Werte hängen in einer Hashtable an den zu erweiternden Objekten, also z.B. an der jeweiligen Virtuellen Maschine in der Hashtable Eigenschaft CustomProperty. Möchte man den Wert der selbsterstellten Eigenschaft “Kostenstelle” abfragen, so kann man dies über

$kostenstelle=get-SCCustomProperty –Name "Kostenstelle"
$wert=$vm.CustomProperty.get_item($kostenstelle)

Nachfolgend noch eine etwas “komplexere” Funktion, um alle Custom Properties von der Virtuellen Maschine $vm auf die Maschine $targetVM zu übertragen:

if ($vm.CustomProperty.Count -gt 0)
{
    $vm.CustomProperty.Keys | ForEach-Object{
        Set-SCCustomPropertyValue -InputObject $targetvm -CustomProperty (Get-SCCustomProperty -Name $_) -Value $vm.CustomProperty.get_item($_)
    }
}

In der ersten Zeile wird zur Sicherheit überprüft, ob überhaupt Custom Properties an diesem Objekt hängen (HashTable speichert die Anzahl der Einträge in Count). Danach werden alle CustomProperty Objekte aus der Key Eigenschaft ausgelesen und durchlaufen. Durch set-SCCustomPropertyValue wird das Objekt und der Wert an das Zielobjekt übertragen.

Kann mir einer das mal erklären? Löscht man in Hyper-V eine VM, die Snapshots hat, dann werden erst alle Snapshots gelöscht, also in das Hauptfile zurückgeschrieben und dann die entsprechende Disk. Was für einen Sinn macht das?

Besonders extrem wird es, wenn man ein Storage Migration mit SCVMM (System Center Virtual Machine Manager 2012) macht. Dabei wird eine neue VM angelegt, die Disks kopiert und dann die alte VM mit den Disks gelöscht. Was dann bei einer VM mit Snapshots passiert kann man sich denken:

Ansicht des Jobs im SCVMM 2012:

Wie man sieht wurden die Disks innerhalb 3 Minuten kopiert und jetzt (ca. 14:05) hängt er immer noch beim Entfernen der VM.

In der Hyper-V Konsole sieht es zu dem Zeitpunkt so aus:

Destroying ist bei 25%

Ich kann mir den Sinn davon nicht erklären. Vielleicht irgendein anderer hier??

Wenn man am PC ein so ungeduldiger Mensch wie ich ist, dann möchte man bei einer Storage Migration mit dem SCVMM irgendwann mehr sehen, als nur die (bereits relativ detaillierte) Statusanzeige des Jobs in der System Center Virtual Machine Manager (SCVMM)  Konsole.

Der längste Teil des Verschiebens ist im allgemeinen das Kopieren der VHD Dateien. SCVMM verwendet dazu den Bits Agent auf dem Hyper-V Server. Das hat den Vorteil, dass dieser nur die zur Verfügung stehende Bandbreite nutzt und somit nicht den normalen Produktionsverkehr stört.

Auf dem Hyper-V Server ist mittlerweile kein Bitsadmin mehr vorhanden, um den Status dieser Jobs direkt auf der Quelle zu kontrollieren. Dafür gibt es mittlerweile ein Power Shell Modul.

Daher schnell powershell.exe auf der Kommandozeile des Hyper-V Servers 2008 R2 ausgeführt und darin ein

Import-Module BitsTransfer

gestartet, um das entsprechende Bits PS-Modul zu importieren.

Danach kann man sich mittels

Get-BitsTransfer -AllUsers | where {$_.JobState -eq ‘Transferring’} | fl

den Status alle gerade noch laufenden Jobs anzeigen lassen. SCVMM startet bei mehreren Platten bzw. Snapshots mehrere Transferjobs parallel. Daher sind auch bei nur einem Job mehrere Bits-Transfers sichtbar.