Hyper-V: Virtuelle Maschine remote mit ISO-Image verbinden

    Remotedateibrowser im Hyper-V ManagerWenn man einen Hyper-V-Host remote über den Hyper-V Manager verwaltet und einer (neuen) VM eine ISO auf einem Share zu­weisen möchte, dann scheitert die Opera­tion an mangelnden Rechten. Will oder kann man das Abbild nicht auf den Host kopieren, dann bieten sich hierfür einige Behelfs­lösungen an.

    Wenn man neue VMs nicht über PXE booten und das OS über das Netz instal­lieren will, dann bleibt als Alternative das Starten der virtuellen Maschinen von DVD. Während VMs der Generation 1 auch von einem physikalischen DVD-Laufwerk booten können, bieten VMs Gen 2 diese Möglichkeit nicht mehr.

    ISO auf Netzfreigabe als Problem

    In der Regel wird man aber ohnehin beiden Arten von VMs mit einer ISO verbinden und von der virtuellen DVD starten. Typischerweise möchte man dann die Installations­medien zentral auf einer Netzfreigabe ablegen, so dass sie für das Setup einer neuen VM von allen Hosts erreichbar sind.

    Während VMware schon mit dem alten vSphere Client und ESXi Free die unkom­plizierte Möglichkeit bot, einer VM physika­lische DVD-Lauf­werke des Clients oder ISO-Dateien von einer Netzwerk­freigabe zuzuordnen, ist Microsoft für diese Aufgabe bis heute aber keine vernünftige Lösung eingefallen.

    Fehlende Rechte für Zugriff auf ISO

    Verwaltet man einen Host remote mit dem Hyper-V Manager und möchte in den Einstellungen einer VM als DVD-Laufwerk eine ISO angeben, dann öffnet sich für die Auswahl der Datei der so genannte Remotedateibrowser. Mit ihm lässt sich nur das Dateisystem des Hosts durchsuchen, ein Abschweifen in das Netzwerk wird mit einer entsprechenden Fehlermeldung unterbunden. Shares sind auf diesem Weg somit nicht erreichbar.

    Der Remotedateibrowser zeigt an, dass er auf das Dateisystem außerhalb des Hyper-V-Hosts nicht zugreifen kann.

    Gibt man stattdessen in der Adressleiste explizit den UNC-Pfad zu einer ISO auf einer Freigabe ein, dann scheitert dieser Versuch mit der Meldung:

    Das Konto "Benutzer" verfügt nicht über die benötigten Rechte zum Öffnen der Anlage.

    Das Problem liegt allerdings weniger beim Konto des Benutzers, sondern darin, dass der Zugriff unter der Kennung des entfernten Hyper-V-Hosts erfolgt.

    Die notorische Fehlermeldung, wenn eine ISO auf einer Netzfreigabe verbunden werden soll.

    Die häufig in Foren empfohlene Maßnahme, dem Computer-Konto des Hosts die nötigen Rechte auf die Freigabe und die ISO-Datei einzuräumen, hilft nicht weiter.

    RDP-Session oder Constrained Delegation

    Zu den weiteren Ratschlägen gehört, dass man sich über RDP-Session auf den Server aufschaltet und dort lokal den Hyper-V Manager startet. Dieses Verfahren scheidet natürlich aus, wenn auf dem Host Server Core oder Nano Server installiert ist.

    Einrichten einer eingeschränkten Delegierung in AD-Benutzer und -Computer.

    Dieser Beitrag auf einem TechNet-Blog schlägt als Lösung vor, für den Account eines jeden Hosts im Active Directory eine Constrained Delegation für die benötigten Netzwerk­freigaben einzurichten. Damit würde man das Rechteproblem des transitiven Zugriffs lösen.

    Rechteproblem auch mit PowerShell

    Greift man stattdessen zu PowerShell, dann sollte man gleich beim Anlegen einer VM in der DVD-Konfiguration Betriebssystem zu einem späteren Zeitpunkt installieren wählen. Danach weist man ihr das ISO-Abbild zu.

    Betriebssystem für die VM später installieren

    Dieses klappt über eine Remote-Session aber nur dann, wenn sich die ISO auf einem Laufwerk des Hosts befindet (sie lässt sich mit PowerShell recht einfach über Copy-Item mit ToSession dorthin kopieren). In diesem Fall verbindet man sich im ersten Schritt durch Eingabe von

    Enter-PSSession -ComputerName <Hyper-V-Server>

    mit dem Server.

    Liegt die ISO hingegen auf einem Share, dann stellt sich das erneut das Problem des transitiven Zugriffs und führt zur gleichen Fehler­meldung wie im Hyper-V Manager. Daher öffnet man in dieser Situation statt einer PS-Session eine RDP-Verbindung mit dem Host und gibt die folgend beschriebenen PowerShell-Befehle dort ein.

    VMs Gen 2 ohne DVD-Laufwerk

    Dabei gilt es die Unterschiede zwischen VMs Gen 1 und 2 zu beachten. Jene der Generation 1 erhalten beim Erstellen automatisch ein DVD-Laufwerk, das an einem IDE-Controller hängt. Ihm muss man nur mehr die ISO-Datei zuweisen:

    Set-VMDvdDrive -VMName MyVM -Path \\server\share\de_windows_10_..._1607_.iso

    Neu erstellte VMs Gen 2 hingegen sind mit keinem DVD-Laufwerk ausgestattet und IDE-Controller sind für sie generell nicht verfügbar. Daher muss man in diesem Fall erst ein solches hinzufügen:

    Add-VMDvdDrive -VMName MyVM -Path \\server\share\de_windows_10_..._1607_.iso

    Sobald das DVD-Laufwerk in einer VM Gen 2 existiert, kann man ihm bei Bedarf später mit Hilfe von Set-VMDvdDrive eine neue ISO zuweisen.

    Alternatives Vorgehen für VMs Gen 1

    Da VMs der Generation 1 auch auf physikalische Laufwerke zugreifen können, bietet sich für sie ein zweites Verfahren an. Dabei mountet man zuerst die ISO-Datei als Laufwerk auf dem Host. Dafür öffnet man wieder eine RDP- bzw. PowerShell-Session (je nachdem, ob die ISO auf einem Share oder dem Host liegt) und stellt die ISO-Datei nach dem Muster

    Mount-DiskImage -ImagePath \\server\share\dvd_9057678.iso

    bereit. Um herauszufinden, welchen Laufwerks­buchstaben das virtuelle Laufwerk erhalten hat, gibt man

    wmic volume get driveletter,label

    ein.

    Die auf dem Host gemountete ISO taucht in der VM als physikalisches Laufwerk auf.

    Nun kehrt man zum lokalen Hyper-V Manager zurück und sollte dort (mit einiger Verzögerung) unter Physisches CD/DVD-Laufwerk den Laufwerks­buchstaben finden, den die ISO-Datei auf dem Host erhalten hat. Den kann man der VM nun zuordnen.

    Keine Kommentare