Da einige der Systeme sich im Netzwerk von manchen Quellen anpingen ließen, von anderen nicht, hatte ich einen Blick auf die ARP-Tabelle eines der Hosts, von wo aus ein Ping nicht möglich war, geworfen:

Dort war mir dann etwas aufgefallen – nämlich dass eine konkrete MAC-Adresse mehreren IP-Adressen zugeordnet war – mit anderen Worten: Mehrere Hosts im Netzwerk hatten scheinbar die selbe MAC-Adresse!

Um dies zu verifizieren, habe ich mir dann die MACs aller VMs auf den betroffenen Hosts anzeigen lassen:

Get-VMNetworkAdapter -VMName * -ComputerName "HOST01","HOST02","HOST03" | Select-Object VMName,MacAddress | Sort-Object MacAddress

Hier bestätigt sich die vorherige Erkenntnis: 4 der verwendeten MACs werden durch mehr als eine VM genutzt! Aber woher kommt das?

Alle Hyper-V-Hosts wurden im selben Netzwerk und nacheinander aufgesetzt. Dennoch zeigt sich, dass zwei der Hosts den selben MAC Address Pool verwenden:

Die Lösung besteht also aus 2 Teilen:

• MAC Address Pool auf mindestens einem der beiden Hosts ändern
• Betroffenen VMs eine neue MAC-Adresse (oder einfach eine neue NIC) verpassen

Ich habe keine Ahnung, wie dieser Fehler zustande gekommen ist, denn eigentlich prüfen Hyper-V Hosts beim Setup, ob der MAC-Address-Bereich von anderen Hosts verwendet wird, aber diese Prüfung war hier wohl irgendwie wenig erfolgreich… Naja, egal. Fehler gefunden, behoben, alles gut

Für dieses Problem gibt es im Allgemeinen das Feature „Processor compatibility“ in Hyper-V (Im Deutschen als „Prozessorkompatibilitätsmodus“ bezeichnet, in der GUI heisst es dann „Zu einem physischen Computer mit einer anderen Prozessorversion migrieren“ bzw. „Migrate to physical computer with a different processor version“). Dieses Feature kann man natürlich problemlos über die GUI ein- und ausschalten:

Allerdings ergeben sich hier schnell 2 Herausforderungen:

• Das Feature lässt sich nur ändern, während die VM ausgeschaltet ist
• In einem Cluster laufen schnell mal eine 2-stellige Anzahl VMs

Das kann man natürlich wie so vieles sehr elegant per PowerShell lösen, also habe ich dafür ein passendes Skript geschrieben. Dieses kann entweder zum ein- oder ausschalten des Features benutzt werden und iteriert dabei über einen Cluster und behandelt dabei dann alle VMs im Cluster, bei denen das Feature noch nicht korrekt eingestellt ist, in dem die VMs bei Bedarf zuerst gestoppt, das Feature gesetzt und dann falls vorher laufend die VM wieder startet. Am Ende wird dann noch der Gesamtzustand ausgegeben.

Das Skript findet ihr auf meinem GitHub Repo, siehe hier:

scripts/HyperV/EnableOrDisableCPUCompatibilityOnHyperVCluster.ps1 at master · HaikoHertes/scripts (github.com)

Damit kann man nun also entweder bei unterschiedlicher Hardware die CPU-Kompatibilität für alle VMs erhöhen oder, nachdem man z.B. die CPUs überall auf den selben Stand gebracht hat, das Feature wieder deaktivieren.

Nichts neues, aber da es mir heute wieder über den Weg gelaufen ist: Wenn man mittels Hyper-V Manager eine VM von einem Host auf einen anderen live verschieben, dann gibt es im Wesentlichen zwei mögliche Protokolle: CredSSP und Kerberos.

CredSSP ist in der Anendung grundsätzlich einfach, hat aber einen entscheidenden Nachteil: Man muss interaktiv (!) an dem Host angemeldet sein, von dem man die VM (weg) verschieben will. Andernfalls bekommt man einen hübschen Fehler:

Der Fehlertext lautet:

Fehler beim Herstellen einer Verbindung mit dem Host “DERHOSTNAME”: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).

Failed to establish a connection with host “THEHOSTNAME”: No credentials are available in the security package (0x8009030E)

Insbesondere auf Core-Servern bleibt hier also nur eine Möglichkeit: Man muss auf Kerberos umstellen! Dazu jedoch müssen sich die Server, zwischen denen man verschieben möchte, für das Protokoll “cifs” und “Microsoft Virtual System Migration Service” vertrauen.

Das könnte man jetzt im ActiveDirectory manuell konfigurieren – aber spätestens bei einer zweistelligen Anzahl an Hosts ist das eine sehr mühsame Klickerei. Also warum nicht PowerShell bemühen? Ich habe mir dazu schon vor einer ganzen Weile ein recht kurzes Skript geschrieben, was jeden der aufgeführten Host gegen jeden anderen berechtigt bzw. die Kerberos-Delegierung einrichtet.

Hier das Skript im Textlaut. Viel Spaß damit!

$Domain = 'domain.local'

# Actually not needed anymore, but who knows...
Import-Module ActiveDirectory
# Put the NetBIOS names of your hosts here
$HyperVHosts = "HOST1","HOST2","HOST3","HOST4","HOST5"

ForEach($Host1 in $HyperVHosts)
{
    ForEach($Host2 in $HyperVHosts)
    {
        If($Host1 -ne $Host2)
        {
            "Delegating from $Host1 to $Host2..."
            Get-ADComputer $Host1 | Set-ADObject -Add @{"msDS-AllowedToDelegateTo" = "Microsoft Virtual System Migration Service/$($Host2).$($Domain)", "cifs/$($Host2).$($Domain)", "Microsoft Virtual System Migration Service/$Host2", "cifs/$Host2"}
            Get-ADComputer $Host1 | Set-ADAccountControl -TrustedForDelegation:$false -TrustedToAuthForDelegation:$true
        }
    }
}

Download des Skriptes siehe hier:

https://github.com/HaikoHertes/scripts/blob/master/HyperV/SetTrustedForDelegationOnAllHyperVHosts.ps1

Welcher meiner Hyper-V Hosts ist dafür am besten geeignet?

Klar, jetzt könnte man einfach im SCVMM nachsehen, ja gar die Bereitstellung darüber abwickeln und sich den besten Host vorschlagen lassen. Was aber, wenn man keinen SCVMM hat (so wie wir)? Dann hilft einem zum Glück die PowerShell – und mein kleines Script!

Dieses fragt alle aufgelisteten Hyper-V-Hosts nach deren Hardware-Ressourcen ab und listet diese dann auf. Dabei werden folgende Informationen ausgegeben:

• Anzahl physischer und logischer Cores
• Anzahl bereits verwendeter vCores
• Verhältnis zwischen logischen und virtuellen Cores (Sollte 1:8 nicht übersteigen)
• Vorhandener RAM gesamt
• Belegter RAM

Im Script enthalten ist eine Funktion, die entsprechende Objekt liefert, wodurch sich das Script auch in andere Automatisierungen einbauen lässt. Ihr findet das Script als Download weiter unten. Hier erstmal das Listing:

$AllHyperVHosts = "HOST1","HOST2","HOST3","HOST4"

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 "

Das Script als *.ps1 Datei gibt es hier:

https://gallery.technet.microsoft.com/scriptcenter/PowerShell-Get-vCore-507be5dc

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

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

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

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:

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:

Viel Spaß beim Ausprobieren!

(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

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

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

http://www.wintotal.de/tipparchiv/?id=2075

Der Artikel wird künftig weiter ergänzt…

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.

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!