Desktop-Hypervisoren sind eine beliebte Technologie unter Technophilen. Wir haben alle möglichen Gründe, sie zu benutzen. Einige von uns müssen Software testen, die andere Leute geschrieben haben, um zu sehen, ob sie gut ist. Einige von uns müssen Software testen, die wir selbst geschrieben haben, um zu sehen, ob sie etwas taugt. Manchmal müssen wir Aktivitäten auf eine vorübergehende Umgebung beschränken. In anderen Fällen wollen wir einfach unsere primäre Umgebung aus den Klauen eines invasiven Installationsprogramms heraushalten. Gründe für die Verwendung eines Desktop-Hypervisors zu finden, ist einfach. Die Entscheidung, welchen Desktop-Hypervisor man verwenden sollte, kann jedoch schwieriger sein. In diesem Artikel wird Microsofts Client Hyper-V mit VirtualBox von Oracle verglichen und gegenübergestellt.

In der Regel sage ich niemandem, welches Produkt er verwenden soll. Ich bin der Meinung, dass man das auswählen sollte, was am besten zu den eigenen Bedürfnissen passt. Wenn es nichts gibt, was perfekt passt, sollte man so lange mischen, bis man so nah wie möglich dran ist. Ich mag es nicht, wenn Leute sich zuerst für ein Produkt entscheiden und dann bequeme Rechtfertigungen für diese Wahl vorbringen. Zwei gängige Beispiele sind: „Niemand wurde je gefeuert, weil er IBM gekauft hat“ und „Dieses Produkt ist das beliebteste“. Ich möchte Ihnen nicht vorschreiben, welches Produkt das bessere ist, sondern Sie zu einer fundierten Entscheidung führen. Diese Entscheidung könnte darin bestehen, beide Hypervisoren zu verwenden.

Client Hyper-V und VirtualBox: Ein technologischer Überblick

Wir sind hier alle Techniker, also lassen Sie uns damit beginnen, diese beiden Hypervisoren von einem technologischen Standpunkt aus zu betrachten.

Sie sind nicht vom Typ des anderen

Der offensichtlichste Unterschied zwischen den beiden Produkten ist, dass Client Hyper-V ein Hypervisor vom Typ 1 ist und VirtualBox ein Hypervisor vom Typ 2. Jedes Mal, wenn ich sage „Hyper-V ist ein Hypervisor vom Typ 1“ und dann versuche zu erklären, was ein Hypervisor vom Typ 1 ist, erhalte ich unweigerlich mindestens ein paar Kommentare, die mir sagen, dass meine Beschreibung völlig falsch ist und dass „Hyper-V ist…“, und dann fährt der Kommentator fort, Hyper-V als Hypervisor vom Typ 2 zu beschreiben. Entweder sind meine Erklärungen nicht sehr gut oder die Leute glauben einfach nicht, dass Hyper-V ein Hypervisor vom Typ 1 ist. Ich hoffe, dass der größte Teil davon darin besteht, dass die Grenze zwischen Typ 1 und Typ 2 nicht annähernd so fest ist, wie manche Leute glauben machen wollen, und dass diese Kommentatoren die Dinge deshalb einfach anders sehen.

Wie auch immer, ich werde eine neue Methode zur Erklärung von Typ 1 vs. Typ 2 versuchen, aber sie auf diesen Kontext beschränken.

Hypervisor Startup Process: Oracle VirtualBox

Ich beginne damit, zu erklären, wie VirtualBox gestartet wird. Es handelt sich um einen Hypervisor vom Typ 2 und ist am einfachsten zu verstehen.

1. Der physische Computer wird gestartet
2. Das Boot-System des physischen Computers (BIOS oder UEFI) übergibt die Kontrolle an das auf der Hardware installierte Betriebssystem. Bei VirtualBox kann das Windows, Linux, OSX oder Solaris sein
3. Der Benutzer (das sind Sie) startet die VirtualBox-Anwendung.
4. Der Benutzer (das sind Sie) wählt aus, welche virtuelle(n) Maschine(n) gestartet werden sollen. VirtualBox startet Hosting-Prozesse

Einfach, oder?

Hypervisor Startup Process: Client Hyper-V

Als Hypervisor vom Typ 1 unterscheidet sich die Startroutine von Client Hyper-V auf einer grundlegenden Ebene von der von VirtualBox.

1. Der physische Computer wird gestartet
2. Das Boot-System des physischen Computers (BIOS oder UEFI) übergibt die Kontrolle an Hyper-V
3. Hyper-V startet das Verwaltungsbetriebssystem. Das Management-Betriebssystem kann nur Windows, Windows Server oder Hyper-V Server sein
4. Als Reaktion auf automatische Einstellungen oder manuelle Anweisungen des Benutzers (das sind Sie) erstellt Hyper-V Partitionen für virtuelle Maschinen

Es gibt Unterschiede in der Art und Weise, wie die verschiedenen Hypervisoren vom Typ 1 und Typ 2 ihre Ziele erreichen, daher kann ich nicht einfach ein paar pauschale Aussagen machen und dann weggehen. Wir werden uns einige der allgemeinen Unterschiede ansehen.

Die Bedeutung der Typunterschiede

Sie können eine Menge schriftliches Material über die Unterschiede zwischen Typ 1 und Typ 2 Hypervisoren finden. In Anbetracht der Möglichkeiten moderner Hardware, Virtualisierungssoftware und Betriebssysteme ist das meiste Material von fragwürdigem Wert. Ich werde die fragwürdigen Teile überspringen und mich nur mit dem befassen, was wir verifizieren können.

Für diese Diskussion ist der wichtigste Unterschied zwischen Typ 1 und 2, dass ein Hypervisor vom Typ 1 immer eingeschaltet ist. Die einzige Möglichkeit, Client Hyper-V zu „stoppen“, besteht darin, den Computer auszuschalten oder die Rolle zu entfernen. Sicher, Sie können den Dienst „Hyper-V Virtual Machine Management“ beenden, aber das ist nicht Hyper-V. Es ist ein Verwaltungsdienst. Ich vermute, dass man ihm deshalb diesen speziellen Namen gegeben hat. Wenn Sie ihn stoppen, können Sie keine virtuellen Maschinen mehr verwalten, aber die virtuellen Maschinen oder der Hypervisor werden dadurch nicht beeinträchtigt. Sie können Hyper-V nicht sehen, indem Sie das Verwaltungsbetriebssystem durchstöbern.

Andererseits kann VirtualBox nach Belieben geöffnet und geschlossen werden. Sie können die VirtualBox-Anwendung, ihren Dienst und ihre virtuellen Maschinen im Task-Manager des Verwaltungsbetriebssystems finden. Wenn Sie die Hauptschnittstelle schließen, werden alle aktiven virtuellen Maschinen weiter ausgeführt, da VirtualBox seinen Hypervisor-Kernel im Speicher belässt. Wenn Sie die letzte virtuelle Maschine von VirtualBox beenden, gibt es keine VirtualBox mehr. Sie müssen es erneut starten, um virtuelle Maschinen zum Laufen zu bringen.

Die Typunterschiede von Client Hyper-V und VirtualBox haben mehrere Konsequenzen:

• Das Management-Betriebssystem von Client Hyper-V verwendet vCPU wie die virtuellen Maschinen
• Sie müssen Hyper-V-Leistungszähler verwenden, um etwas über die Ressourcennutzung von Client Hyper-V zu erfahren, und das sagt nicht alles
• Die Hardware-Zuweisung funktioniert anders
• Die Ressourcenpriorität funktioniert anders

Hyper-V vs. VirtualBox: Hardware-Zugriff

Wenn ich die Beschwerden über den Client Hyper-V lese, stehen Hardware-Probleme ganz oben auf dem Stapel. Unweigerlich werden Vergleiche zu VirtualBox, VMware Workstation/Player und anderen Typ-2-Hypervisoren gezogen. Die Beschwerdeführer versäumen es selten zu erwähnen, dass es bei diesen Produkten so gut wie keine Geräteprobleme gibt. Die Wurzel des Problems liegt direkt beim Hypervisor-Typ.

Wenn VirtualBox (oder ein anderer Hypervisor vom Typ 2) eine virtuelle Maschine erzeugt, läuft ihr Container innerhalb des Verwaltungsbetriebssystems, in dem die Anwendungen leben. Wie andere Anwendungen haben sie keinen direkten Hardware-Zugriff; sie müssen den Gerätezugriff über das Betriebssystem anfordern.

Betrachten wir zum Beispiel die Zuweisung meiner Sound-Hardware durch meinen Windows 10-Desktop:

Ich habe mehrere Sound-Hardware-Geräte und mehrere Anwendungen. Der gesamte Hardwarezugriff und die Zuweisung erfolgt über das Betriebssystem. Hinweis: Die obige Darstellung dient nur zur Veranschaulichung. Sie verwenden Volume Mixer nicht, um VirtualBox-Gäste mit Sound-Hardware zu verbinden.

Wenn Sie also einen VirtualBox-Gast einschalten, können Sie seinen Anwendungscontainer verwenden, um den Zugriff auf die Hardware anzufordern.

Nun denken Sie an Client Hyper-V. Das Verwaltungsbetriebssystem läuft in einer eigenen Partition, getrennt von den Gastbetriebssystemen. Im Gegensatz zu VirtualBox haben die Gastbetriebssysteme von Client Hyper-V keinen Einblick in das Management-Betriebssystem. Sie können nicht einfach die API des Verwaltungsbetriebssystems aufrufen, wie es VirtualBox-Gäste können, da sie nicht darauf zugreifen können. Es gibt Funktionen in Client Hyper-V, die Ihnen helfen können, diesen Unterschied zu beheben, aber das alles wird durch grundlegende Unterschiede in den Hypervisor-Technologien verursacht.

Aus diesem Abschnitt mitnehmen: Wenn Sie USB-angeschlossene Hardware und externe Festplatten mit Ihren virtuellen Gastmaschinen verwenden möchten, werden Sie es mit VirtualBox leichter haben.

Hyper-V vs. VirtualBox: Hardware-Präsentation

Dieser Abschnitt knüpft stark an den vorherigen Abschnitt an. Wenn Sie die Einstellungsregisterkarten einer virtuellen Maschine in VirtualBox durchblättern, werden Sie eine Menge Dinge finden, die Sie in Hyper-V nicht sehen werden. Sie müssen sich zwischen einem PIIX3- oder einem ICH9-Chipsatz entscheiden. Sie müssen zwischen einem Intel-Audiocontroller, einem ICH AC97-Audiocontroller und einem SoundBlaster 16-Audiocontroller wählen. Wenn Sie einer virtuellen Maschine erlauben, einen USB-Controller zu haben, müssen Sie zwischen einem 1.1-, 2.0- oder 3.0-Gerät wählen. Hyper-V verlangt von Ihnen keine derartige Auswahl.

Der Unterschied hängt auch mit der ganzen Typ 1 vs. Typ 2 Diskussion zusammen. Hypervisoren vom Typ 2 sind für eine viel größere Bandbreite an Umgebungen ausgelegt, was eine Reihe von Problemen mit sich bringt. Um diese Probleme zu lösen, machen Hypervisoren vom Typ 2 ausgiebig Gebrauch von Emulation. Bei der Emulation ahmt ein Softwarekonstrukt die Schnittstellen eines Hardwaregeräts nach. VirtualBox emuliert all die Dinge, die ich im vorangegangenen Absatz aufgeführt habe, und noch mehr. Client Hyper-V emuliert nur sehr wenig – am bemerkenswertesten sind sein IDE-Controller und der Legacy-Netzwerkadapter.

Die Emulation löst das Problem der breiten Anwendbarkeit. Wie Sie sich vorstellen können, hat diese Vielseitigkeit ihren Preis. Der gesamte Zweck von Spezialhardware wie Netzwerkkarten und Videoadaptern besteht darin, dass sie ihre jeweilige Arbeitslast bewältigen, damit die Last nicht auf andere Schultern fällt. Da sie speziell für ihre Aufgaben entwickelt wurden, erfüllen sie diese (vermutlich) besser als andere Komponenten, die für andere Zwecke entwickelt wurden. Bei emulierter Hardware übernimmt Ihre Allzweck-CPU die gesamte Verantwortung der dedizierten Hardware.

Aus diesem Abschnitt können Sie mitnehmen: VirtualBox arbeitet mit einer breiteren Palette von Hardware auf einer breiteren Palette von Systemen auf Kosten eines leistungsbeeinträchtigenden Overheads.

Hyper-V vs. VirtualBox: Ressourcenpriorität

Da VirtualBox nur innerhalb des auf der Hardware installierten Betriebssystems läuft, ist es der Gnade des Schedulers dieses Betriebssystems ausgesetzt. Einer der Gründe, warum ich die typische Diskussion über CPU-Ringe übersprungen habe, ist, dass VirtualBox diesen Dialog enthält:

Das bedeutet, dass VirtualBox auf dieselben Funktionen zugreifen kann, die viele Leute nur mit CPU-Ring-1 und den Erweiterungen des Virtual Machine Monitors assoziieren, die von „echten“ Typ-1-Hypervisoren verwendet werden.

Allerdings ist VirtualBox immer noch an die Beschränkungen des auf der Hardware installierten Betriebssystems gebunden. Wenn Sie ein ausuferndes Flash-Spiel haben, das Speicher und CPU in Ihrem Hardware-Betriebssystem beansprucht, kann und wird das Betriebssystem die Leistung Ihrer virtuellen VirtualBox-Maschinen in beliebigem Maße beeinträchtigen. Wenn es darauf ankommt, können Sie den Task-Manager verwenden, um jeden VirtualBox-Prozess oder -Gast zu beenden.

Im Gegensatz dazu bietet Client-Hyper-V die gleichen Priorisierungssteuerungen wie sein serverbasierter großer Bruder. Sie können CPU und Arbeitsspeicher priorisieren, Storage Quality of Service aktivieren und Netzwerkbandbreitenbeschränkungen für alle Ihre virtuellen Maschinen festlegen.

Aus diesem Abschnitt mitnehmen: Client-Hyper-V gewährt eine fein abgestufte Kontrolle über die Ressourcenpriorisierung; VirtualBox nicht.

Hyper-V vs. VirtualBox: Videobeschleunigung

Dieser Abschnitt unterscheidet sich ein wenig von der vorangegangenen Diskussion, da nichts hier allgemeingültig sein wird. Ich werde darüber berichten, wie die Unterschiede zwischen den beiden Hypervisoren meine Erfahrungen beeinflusst haben. Ihre Erfahrungen können variieren.

Beide Clients, Hyper-V und VirtualBox, emulieren Video. Nach meinen Erfahrungen konnte ich nicht feststellen, dass der eine besser ist als der andere, wenn es um die 2D-Beschleunigung geht. Ich glaube nicht, dass ich viel von der 2D-Beschleunigung verlange, aber ich weiß auch, dass die meisten modernen Desktop-Betriebssysteme die 2D-Beschleunigung auf eine Weise nutzen, die nicht immer offensichtlich ist, bis sie nicht verfügbar ist. Zwei Hauptbeispiele sind Schriftglättung und Fensteranimationen. Ich glaube nicht, dass die 2D-Beschleunigung für einen der beiden Hypervisoren ausschlaggebend sein sollte.

3D-Beschleunigung ist eine andere Geschichte. Client Hyper-V bietet RemoteFX. Nach meinen Experimenten funktioniert es innerhalb der Grenzen, für die es konzipiert ist, sehr gut. RemoteFX projiziert die Grafikkarte nicht in das Gastbetriebssystem, sodass Sie nicht auf alle Funktionen zugreifen können. RemoteFX hat auch auf jedem System funktioniert, das ich jemals versucht habe, es zu benutzen, solange es den erforderlichen 3D-beschleunigten WDDM-kompatiblen Treiber enthielt.

3D-Beschleunigung in VirtualBox ist eine ganz andere Geschichte. Ich habe völlig versagt, es jemals zu bekommen, um gut genug, um auch eine grundlegende Windows-Desktop richtig angezeigt. Ich habe nie auch nur annähernd irgendwelche 3D-Beschleunigungsfunktionen ausprobiert. Ich kann also keine aussagekräftigen Vergleiche zwischen den beiden anstellen.

Fazit aus diesem Abschnitt: Die 2D-Beschleunigung scheint bei beiden gleich zu sein. Die 3D-Beschleunigung scheint in Client Hyper-V zuverlässiger zu sein.

Hyper-V Vs. VirtualBox: Kompatibilität virtueller Festplatten

VirtualBox unterstützt mehrere virtuelle Festplattenformate. Sie können wählen zwischen:

• VDI, dem nativen VirtualBox-Format
• VMDK, VMwares Format
• VHD, Microsofts Format
• HDD, Parallels Format
• QED und QCOW, das in QEMU und anderen Hypervisoren verwendet wird

Sie können VHDX nicht mit VirtualBox verwenden. Die Möglichkeit, das Festplattenformat eines anderen Hypervisors zu verwenden, bedeutet nicht zwangsläufig, dass Sie eine virtuelle Festplatte problemlos von einem Hypervisor auf einen anderen übertragen können.

Nehmen Sie aus diesem Abschnitt mit, dass es sich hierbei um fast allgemeine Informationen handelt, da die Möglichkeit, mehrere virtuelle Festplattenformate zu verwenden, nicht so nützlich ist, wie es auf den ersten Blick erscheinen mag. Wenn Sie versuchen wollen, eine virtuelle Festplatte von einer Plattform auf eine andere zu verschieben, ohne einen Konverter zu verwenden, ist VirtualBox die beste Wahl.

Hyper-V vs. VirtualBox: Andere Videofunktionen

VirtualBox bietet einige Videofunktionen, mit denen Client Hyper-V nicht direkt konkurriert.

• Client Hyper-V kann nur auf einem Monitor oder auf allen Monitoren angezeigt werden. Sie können zwischen einem und acht Monitoren für VirtualBox festlegen.
• VirtualBox bietet einen Servermodus, der es entfernten Computern ermöglicht, sich mit dem in der Hardware installierten Betriebssystem zu verbinden, um die Konsole eines oder mehrerer bestimmter Gäste anzuzeigen. Jeder Endpunkt erlaubt mehrere gleichzeitige Remote-Verbindungen. Der Hyper-V-Client bietet mit vmconnect eine ähnliche Funktionalität.exe, aber es ist nicht so vielseitig.
• VirtualBox kann eine Videoaufzeichnung eines Gastbetriebssystems machen.
• VirtualBox erlaubt es Ihnen, eine virtuelle Maschine in den „Seamless“-Modus zu versetzen. Anwendungen, die Sie in der virtuellen Maschine starten, erscheinen und funktionieren so, als würden sie im auf der Hardware installierten Betriebssystem laufen.

Aus diesem Abschnitt mitnehmen: Wenn eine dieser Funktionen für Sie interessant ist, ist VirtualBox die einzige Wahl.

Hyper-V vs. VirtualBox: Zugang zum Quellcode

VirtualBox ist eine Open-Source-Software. Wenn Ihnen etwas nicht gefällt und Sie glauben, dass Sie es besser machen können, dann tun Sie es doch. Wenn Sie einfach nur wissen wollen, wie es funktioniert, laden Sie den Quellcode herunter und machen Sie sich an die Arbeit.

Microsoft öffnet sich allmählich der Idee von Open Source und hat einen großen Teil des Codes an die Gemeinschaft weitergegeben. Windows ist notorisch abwesend. Soweit ich weiß, ist die Hyper-V-Codebasis sehr eng mit Windows verbunden. Ich bezweifle, dass der Code von Hyper-V jemals veröffentlicht wird.

Aus diesem Abschnitt mitnehmen: Wenn die Verwendung eines Open-Source-Hypervisors für Sie wichtig ist, disqualifiziert das den Client Hyper-V.

Hyper-V vs. VirtualBox: Nutzungslizenz

Client Hyper-V wird als Bestandteil von Windows 10 Professional und Enterprise SKUs ausgeliefert. Wenn Sie anderweitig lizenziert sind, um eines dieser Produkte zu verwenden, dann sind Sie lizenziert, um Client Hyper-V zu verwenden.

Oracle lizenziert das aktuelle Kernpaket von VirtualBox (Versionen 5.x+) unter GPLv2. Sie bieten auch einige „Erweiterungen“ unter einer separaten Lizenz namens „VirtualBox Personal Use and Evaluation License“ an. Ich persönlich nutze keine dieser Funktionen, obwohl sie einige der oben erwähnten Funktionen umfassen. Ich habe mich nicht eingehend mit den Bedingungen dieser Lizenz befasst, aber sie scheint recht großzügig zu sein. Wie immer empfehle ich Ihnen, sich bei Fragen zur Lizenzierung von einem ausgebildeten Rechtsberater beraten zu lassen.

Was die Lizenzen für Gastbetriebssysteme angeht, so ist das eine andere Geschichte. Weder Client Hyper-V noch VirtualBox sehen überhaupt Lizenzen für Gastbetriebssysteme vor. Wenn Sie eine beliebige Variante von Windows oder Windows Server in einem Gastbetriebssystem unter einem der beiden Hypervisoren installieren, müssen Sie die Hardware ordnungsgemäß lizenzieren.

Aus diesem Abschnitt mitnehmen: die Lizenzierung ist immer wichtig.

Erwerb von Client Hyper-V und VirtualBox

Wenn Sie Windows 10 Professional oder Enterprise verwenden, müssen Sie nur die Hyper-V-Rolle aktivieren, um sie zu nutzen.

VirtualBox ist auf der Website des Unternehmens erhältlich: https://www.virtualbox.org/