Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

22Nov/170

Hyper-V: Welcher Host ist am besten für eine neue VM geeignet?

Mir stellt sich im Administrations-Alltag immer wieder die Frage, welcher unserer Hyper-V-Hosts derzeit am besten für eine neue VM geeignet ist (Nein, wir verwenden leider kein VMM…). Anstatt aber dabei jedes Mal jeden Host hinsichtlich seiner freien Ressourcen “abzuklappern”, habe ich mir ein entsprechendes PowerShell-Skript geschrieben, was eine passende Function bereithält. Ihr könnt das Skript gerne für eure Zwecke anpassen oder direkt so übernehmen.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
$AllHyperVHosts = "HostNr1","HostNr2","HostNr3"
 
function Get-HyperVHostInfo([string]$HyperVHost)
{
 
    $vCores = ((Get-VM -ComputerName $HyperVHost).ProcessorCount | Measure-Object -Sum).Sum
 
    $Property = "numberOfCores", "NumberOfLogicalProcessors"
    $CPUs = Get-Ciminstance -class Win32_Processor -Property  $Property -ComputerName $HyperVHost| Select-Object -Property $Property 
    $Cores = ($CPUs.numberOfCores | Measure-Object -Sum).Sum
    $logCores = ($CPUs.NumberOfLogicalProcessors | Measure-Object -Sum).Sum
 
    $os = Get-Ciminstance Win32_OperatingSystem -ComputerName $HyperVHost
    $MemFreePct = [math]::Round(($os.FreePhysicalMemory/$os.TotalVisibleMemorySize)*100,2)
 
    $object = New-Object -TypeName PSObject
    $object | Add-Member –MemberType NoteProperty –Name PhysicalCores –Value $Cores
    $object | Add-Member –MemberType NoteProperty –Name LogicalCores –Value $logCores
    $object | Add-Member –MemberType NoteProperty –Name VirtualCores –Value $vCores
    $object | Add-Member –MemberType NoteProperty –Name MemTotalGB -Value ([int]($os.TotalVisibleMemorySize/1mb))
    $object | Add-Member –MemberType NoteProperty –Name MemFreeGB -Value ([math]::Round($os.FreePhysicalMemory/1mb,2))
    $object | Add-Member –MemberType NoteProperty –Name MemFreePct -Value $MemFreePct
 
    Return $object
}
 
ForEach($OneHost in $AllHyperVHosts)
{
    $HostData = Get-HyperVHostInfo -HyperVHost $OneHost
 
    Write-Host "$OneHost has $($Hostdata.PhysicalCores) physical cores, $($Hostdata.LogicalCores) logical cores and $($Hostdata.VirtualCores) virtual cores are used in all VMs overall." -ForegroundColor Yellow
    Write-Host "The Core:vCore ratio is `t`t1:$([math]::Round(($Hostdata.VirtualCores) /  ($Hostdata.PhysicalCores),2))"
    Write-Host "The Log.Core:vCore ratio is `t1:$([math]::Round(($Hostdata.VirtualCores) /  ($Hostdata.LogicalCores),2))"
    Write-Host "The system has $($Hostdata.MemFreeGB)GB of free memory and $($Hostdata.MemTotalGB)GB memory at all, which is $($Hostdata.MemFreePct)% free"
    Write-Host ""
 
}
Write-Host "The conservative approach for logical cores is `t1:8 "

 

Eine Beispielausgabe sieht dann so aus:

hyperv1

5Mrz/170

Hyper-V Server 2012 R2 / 2016 bzw. Server Core: SNMP-Dienst konfigurieren

Wenn man auf einem Hyper-V Server (gemeint ist der kostenlose Server, der ohne GUI, also vergleichbar einer Server Core Installation, und nur mit Hyper-V as Rolle betrieben werden kann) den SNMP-Dienst installiert hat, muss diese noch konfiguriert werden.

Die Installation selber kann remote über den Servermanager oder lokal über PowerShell erfolgen:

snmp0

Add-WindowsFeature -Name SNMP-Service,SNMP-WMI-Provider

snmp0b

Nach der Installation würde man auf einem grafischen Server jetzt einfach die Dienste-Konsole oder die Computerverwaltung öffnen und den Dienst dort entsprechend konfigurieren. Die grafischen Werkzeuge stehen aber lokal nicht zur Verfügung. Verwendet man jetzt bspw. die Computerverwaltung von einem grafischen Server aus und verbindet sich von dort mit dem Hyper-V Server bzw. dem als Server Core installierten Server, wird man leider feststellen, dass dort einige Optionen im SNMP-Dienst fehlen:

snmp1

Abhilfe schafft hier die Installation des SNMP-Features auch auf der Maschine, von der aus man mit dem grafischen Werkzeug arbeiten möchte. Danach kann man auch remote die passenden Einstellungen vornehmen:

snmp2

Viel Spaß beim Ausprobieren!

2Dez/160

Windows Server NIC-Teaming: Problem mit doppelter MAC beheben

Auf einem Test-Host unter Windows Server 2016 mit Hyper-V ist mir heute folgende Fehlermeldung im Eventlog aufgefallen:

lbfo1

(MAC Conflict: A port on the virtual switch has the same MAC as one of the underlying team members on Team Nic Microsoft Network Adapter Multiplexor Driver) – Source: MsLbfoSysEvtProvider / Event-ID 16945

Wenn man mittels PowerShell nach den MACs schaut bestätigt sich das auch schnell:

Get-NetAdapter | Sort MacAddress

lbfo2

Als Lösung habe ich die MAC des Teams (mittels PowerShell, da es ein Core-Server ist) geändert:

Get-NetAdapter “Name” | Set-NetAdapter –MacAddress 00-00-00-00-00-00

lbfo3

23Jun/160

Hyper-V-Server / Windows Server Core: Treiber via PowerShell installieren

Wer einen Windows Server 2012 R2 als Core-Server oder den kostenfreien Hyper-V-Server 2012 R2 einsetzt, dem könnte folgendes Problem begegnen: Auf dem Server selber gibt es bekanntlich keine GUI und demnach auch keinen Gerätemanager. Und seit 2012 R2 lässt sich dieser auch nicht remote von einem grafischen Server aus ansprechen!

Was nun also tun, wenn man Treiber installieren/aktualisieren/entfernen will? Dazu möchte ich hier einige Kommandos als Hilfestellung zusammentragen:

 

Installation aller Treiber des aktuellen Verzeichnisses in das Treiber-Repository:

Get-ChildItem -Recurse -Filter *.inf | Select-Object FullName | ForEach-Object {pnputil -a $_.FullName}

Installation eines bestimmten Treibers:

pnputil.exe -i -a C:\Pfad\zum\Treiber.inf

(ACHTUNG: Installiert diesen Treiber für alle "passenden" Geräte!)

Auflisten aller Treiber im Repository (3rd Party):

pnputil.exe -e

Entfernen eines Treibers aus dem Repository:

pnputil.exe -d oemX.inf (Name der INF-Datei über pnputil -e)

Entfernen aller Treiber aus dem Repository:

1..40 | ForEach-Object {pnputil.exe -d "oem$_.inf"} (Die Zahl 40 muss ausgetauscht werden durch die höchste Zahl aus pnputil -e)

Ermitteln der Hardware-ID der Geräte einer bestimmten Geräteklasse (hier: Netzwerkkarten)

devcon.exe listclass net

Anzeigen des von einem Gerät benutzten Treibers:

devcon.exe driverfiles "@PCI\VEN_8086&DEV_10D3&SUBSYS_040D15D9&REV_00\4&60B4255&0&00E4"

Installation eines bestimmten Treibers für ein bestimmtes Gerät:

devcon.exe /r install C:\Pfad\zum\Treiber.inf "@PCI\VEN_8086&DEV_10D3&SUBSYS_040D15D9&REV_00\4&60B4255&0&00E4"

Entfernen eines konkreten Gerätes (nicht nur der Treiber!):

devcon.exe /r remove "@PCI\VEN_8086&DEV_10D3&SUBSYS_040D15D9&REV_00\4&60B4255&0&00E4"

Nach neuen Geräten suchen:

devcon.exe rescan

 

Für einige Varianten ist DevCon.exe nötig. Siehe dazu hier:

https://msdn.microsoft.com/de-de/library/windows/hardware/ff544707(v=vs.85).aspx

Tipparchiv

Der Artikel wird künftig weiter ergänzt...

7Jun/160

Hyper-V: PowerShell-Skript um nicht benutzte bzw. verwaiste VHD / VHDX Dateien zu finden

Auf einem Hyper-V System sammeln sich über die Jahre einige virtuelle Festplatten-Dateien im VHD- bzw. VHDX-Format an. Aber werden diese wirklich noch alle gebraucht? Das ist häufig schwer zu sagen, da insbesondere durch das Löschen von VMs nur deren Beschreibungs-Dateien, nicht aber die Festplatten gelöscht werden. Ähnliches kann passieren, wenn man die Replikation einer VM beendet.

Um nun diejenigen VHDs, die von keiner VM mehr genutzt werden, zu finden, habe ich ein Skript geschrieben. Dieses berücksichtigt auch, dass sich mehrere VHD/VHDX Dateien in einer Differenzierungskette befinden könnten.

Das Skript sowie eine Beschreibung findet ihr hier:

https://gallery.technet.microsoft.com/scriptcenter/Get-AbandonedVHDs-V1-to-8bfb28d9

Dem Skript kann neben einem oder mehreren Suchordnern auch u.a. eine Option übergeben werden, die direkt die nicht benötigten Dateien löscht. Das ist aber nicht ganz ungefährlich, ggf. haben die VHDs ja eine andere Funktion und sind gar nicht für Hyper-V. Denkbar wäre z.B., dass ein iSCSI-Software-Target im Einsatz ist, oder aber auch die Windows Server Sicherung.

script

20Nov/150

Windows Server 2016 – Technical Preview 4

Seit ein paar Stunden ist die TP4 des künftigen Windows Server 2016 für die Öffentlichkeit verfügbar. Der Download kann u.a. über die MSDN oder das Eval-Center erfolgen:

https://technet.microsoft.com/de-de/evalcenter/dn781243.aspx

Eine der großen neu verfügbaren Funktionen ist “Hyper-V Container”. Damit das funktionieren kann, muss die Nested Virtualization möglich sein, die bereits seit kurzem in Windows 10 (Fast Ring) verfügbar ist.

Weitere Informationen auf diesem Blog-Post des Lead Program Managers des Windows Server Programms:

http://blogs.technet.com/b/virtualization/archive/2015/11/19/announcing-the-release-of-hyper-v-containers-in-windows-server-2016-technical-preview-4.aspx

Weiterhin werden heute TP4-Releases der System Center Produkte erwartet. Es bleibt also spannend!

13Nov/150

SCVMM 2012 R2: Konsole stürzt nach dem Hinzufügen einer Benutzerdefinierten Eigenschaft (“Custom Property”) ab

Heute hatte ich folgenden Effekt:

Nach dem Erstellen einer neuen “Custom Property” mit dem Namen “HDD-Typ SSD,SAS,SATA” (Sonderzeichen wie Klammern und Schrägstriche sind nicht zulässig und werden von der GUI abgefangen) stürzt die SCVMM Konsole sofort ab und lässt sich auch nicht wieder starten.

SCVMM_CustomProp0SCVMM_CustomProp0a

Der erste Fehler hat den Ereignisnamen “CLR20r3” an der “VmmAdminUI.exe”. Vermutlich gibt es für dieses Problem mittlerweile einen Patch, aber die verwendete Umgebung war nicht komplett gepatcht. Also musste eine Alternative her. Naheliegend war das Löschen der neu angelegten Eigenschaft, aber dies musste ohne GUI erfolgen (diese ließ sich wegen des Crashes ja nicht starten). Also bleibt nur die PowerShell…

Zunächst habe ich mit “Get-SCCustomProperty” nach der betreffenden Eigenschaft gesucht:

SCVMM_CustomProp0b

Der komplette Aufruf:

Get-SCCustomProperty | Where Name -NotLike "Custom*"

Danach kann man diese mit “Remove-SCCustomProperty” löschen:

SCVMM_CustomProp0c

Der komplette Aufruf:

Get-SCCustomProperty -Name "HDD-Typ SSD, SAS, SATA" | Remove-SCCustomProperty

Danach startet auch die Konsole wieder!

Hinweis: Zur Nutzung der SC-Kommandos muss das entsprechende Modul geladen sein. Dies geht am einfachsten, in dem man auf dem SCVMM-Server selbst die “Virtual Maschine Manager Command Shell” startet:

SCVMM_CustomProp3

8Jan/150

Hyper-V Server: Tatsächlichen freien Speicher der VMs auswerten

Wenn man in einer Hyper-V VM einen Blick auf den belegten bzw. freien RAM wirft, dann wird man häufig feststellen, dass nicht mehr viel übrig ist – und zwar dann, wenn man “Dynamic Memory”, den “Dynamischen Arbeitsspeicher” aktiviert hat. Dieser sorgt dafür, dass eine VM die Menge an Arbeitsspeicher bekommt, die sie aktuell benötigt – zumindest, solange noch Speicher frei ist und sich die VM in den vom Admin gesteckten Grenzen bewegt. So kann man seit dem Windows Server 2012 bzw. seit Hyper-V 3.0 drei verschiedene Werte konfigurieren:

DynMem0

Es lässt sich neben dem Startwert (Wieviel RAM bekommt die VM, wenn sie eingeschaltet wird?) weiterhin festlegen, wieviel die VM mindestens haben muss (Sie kann nie weniger haben, als hier festgelegt ist) und welche Menge ihr maximal zur Verfügung stehen könnte (Vorausgesetzt, es ist genügend RAM vorhanden; hier lässt sich auch ein Wert festlegen, der über dem insgesamt vorhandenen RAM liegt).

Bei Bedarf kann der “Minimale RAM” auch unter dem “Startwert” liegen – dies ist vor allem dann sinnvoll, wenn die VM während des Starts und der Anfangszeit nach dem Boot viel Speicher benötigt, um z.B. Dienste und Anwendungen zu starten, dann im Alltagsbetrieb aber mit weniger auskommt.

Nehmen wir nun an, eine VM hat folgende Konfiguration:

  • Start: 2GB
  • Min: 512MB
  • Max: 3GB

Nun wird sie also beim Einschalten zunächst 2GB bekommen, nach dem erfolgreichen Start ihres Betriebssystems den tatsächlichen RAM-Bedarf an Hyper-V melden und Hyper-V weist der VM dann diesen Bedarf plus einen Sicherheitsaufschlag (den “Arbeitsspeicherpuffer”) zu. Dieser ist nötig, damit die VM nicht jedes weitere benötigte Megabyte speicher einzeln anfordern muss, sondern dies immer “paketweise” tun kann.

Benötigt die VM nun mehr, dann bekommt sie mehr – solange, bis entweder das Maximum der VM-Konfiguration erreicht oder der RAM des Host-Systems voll ist. Einem System im laufenden Betrieb mehr RAM zuzuweisen ist nicht so kompliziert und ging bereits lange vor dem Virtualisierungszeitalter (ja, da musste man dann noch echte Speicherriegel in den Server stecken!).

Spannender wird der Vorgang, einer VM Speicher wegzunehmen, z.B. wenn sie eben nach dem Starten weniger Speicher benötigt, als im Startwert festgelegt. Wirklich Speicher “wegnehmen” kann man nicht. Dies wird durch eine Technik namens “Balooning” gelöst. Wenn der VM nun z.B. 512MB RAM weggenommen werden sollen, dann wird stattdessen in der VM (bzw. in deren Speicherbereich) eine “Ballon aufgeblasen”, der diese 512MB RAM belegt – die VM glaubt also, der Speicher wäre weiterhin vorhanden, aber aktuell belegt. Der Hypervisor “weiss” nun, dass er diesen RAM anderweitig vergeben kann, da er ja nicht wirklich belegt ist. Soll die VM wieder mehr Speicher bekommen, wird der Ballon stückweise kleiner gemacht, bis er verschwindet.

DynMem1

(In der Abbildung sehen wir eine VM, die nach dem Start, der mit 2GB RAM durchgeführt wurde,
nur noch 661MB benötigt und inkl. Aufschlag 788MB RAM zugewiesen bekommen hat)

Soweit die Technik, die in der Praxis sehr gut funktioniert. Jedoch hat sie einen Haken: Die VM im obigen Beispiel, welche nach dem erfolgreichen Start einen RAM-Bedarf von bspw. 661MB an Hyper-V meldet und 20% “Aufschlag” bekommt, soll nun 788MB RAM zugewiesen bekommen (Also 1260MB weniger als beim Start). In der Realisierung sieht sie weiterhin ihre 2GB – davon aber einmal die 1260MB Differenz (den “Ballon”) plus den tatsächlichen RAM-Bedarf (also 661MB) belegt. In der Konsequenz sind als (z.B. im TaskManager) 1921MB (1,87GB) belegt – von 2048MB insgesamt – also nur noch ca. 6% frei!

DynMem2 Der Taskmanager innerhalb der VM zeigt etwa zur selben Zeit, zu der der vorherige Screenshot erzeugt wurde, einen RAM-Verbrauch von 1,8GB und freien Speicher in Höhe von 204MB. Das hier etwas mehr RAM frei ist als bei der Rechnung oben liegt daran, dass die VM etwas mehr Speicherbedarf an Hyper-V meldet als tatsächlich bereits belegt sind.

Eine entsprechende Serverüberwachung, die es nicht besser weiss, meldet nun also, dass der RAM zu Neige geht. Das Fatale dabei ist aber, dass wenn man dieser VM z.B. einen größeren Startwert gibt, bspw. 3GB, dann wird die Rechnung noch schlimmer:

  • 3072MB beim Start
  • Nach dem Start 661MB belegt, 788MB zugewiesen
  • Ballon iHv 2284MB
  • Als belegt zu sehender Speicher: 2945MB (Ballon + 661MB tatsächlicher Bedarf)
  • Übrig bleiben dann 127MB (Der Puffer) – was hier nur noch etwa 4% (statt 6% bei 2GB Start-RAM) entspricht!

Dies geschieht, obwohl die VM augenscheinlich mehr RAM hat (oder zumindest haben KÖNNTE) und immer noch den selben Bedarf (von 661MB) hat! Hier darf man sich also nicht täuschen lassen.

Als Lösung könnte man den RAM-Verbrauch der VMs mittels PowerShell analysieren und dann bspw. bei Unterschreitung eines Schwellwertes bzgl. des freien RAMs alamieren. Ein solcher Aufruf, der den freien RAM aller VMs in Prozenten zeigt, könnte dabei so aussehen:

DynMem3

Zum Kopieren:

1
2
3
4
5
6
Get-VM | Where DynamicMemoryEnabled | Where State -eq "Running"
    Format-Table Name,
                 @{n='Benötigt(GB)';e={$_.MemoryDemand/1GB};FormatString='N3'},
                 @{n='Zugewiesen(GB)';e={$_.MemoryAssigned/1GB};FormatString='N3'},
                 @{n='Frei/Aktuell (%)';e={100-($_.MemoryDemand/$_.MemoryAssigned*100)};FormatString='N2'},
                 @{n='Frei/Max (%)';e={100-($_.MemoryDemand/$_.MemoryMaximum*100)};FormatString='N2'} -AutoSize

Die Spalte “Frei/Aktuell” liefert einen Wert, wieviel Speicher bezogen auf den aktuell zugewiesenen Wert frei ist (dieser Wert sollte sich in etwa in der Größe des Speicherpuffers bewegen, solange genügend RAM verfügbar ist und die VM mehr RAM als das Minimum benötigt).

Die letzte Spalte “Frei/Max” zeigt, wieviel Speicher bezogen auf den maximal möglichen RAM der VM noch frei ist. Erst wenn dieser Wert zu niedrig wird (bspw. unter 20% fällt) besteht Bedarf, der VM mehr RAM zuzuweisen.

Insgesamt sehen dann die Werte in der PowerShell, dem Taskmanager der VM und dem Hyper-V Manager so aus:

DynMem4 (Anklicken zum Vergrößern)

3Dez/140

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):

HVFreeSpace01

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:

HVFreeSpace03

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:

HVFreeSpace04

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!

HVFreeSpace02

(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:

HVFreeSpace05

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

13Okt/140

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.

Checkpoints1

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:

Checkpoints2

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

Checkpoints3

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:

Checkpoints4

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:

HyperV1

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