Das Betriebssystem kann nicht mehr selbst entscheiden, welche Prozesse wann genau ausgeführt werden sollen, denn die Virtualisierungslösung kann die Ausführung des gesamten virtualisierten Systems anhalten oder verzögern.

Das Betriebssystem kann nicht mehr direkt auf die Hardware von Netzwerkkarten oder Speichersystemen zugreifen, sondern muss hierfür auf eine Funktion der Virtualisierungslösung zugreifen. Dafür muss mehrfach zwischen Gast und Wirt umgeschaltet werden. Dies verringert nicht nur den maximal möglichen Durchsatz, sondern erhöht vor allem die Latenz.

Sind die Festplatten nicht lokal auf dem Virtualisierungsserver installiert, sondern z.B. über ein SAN angebunden, kommt noch die Latenz für den Transfer über das SAN hinzu. Auf verschiedenen SAN-Lösungen können aber sehr unterschiedliche Latenzzeiten beobachtet werden. Lösungen, die auf iSCSI basieren, tendieren eher zu hohen Latenzzeiten. Lösungen mit Fibre Channel oder FCoE (Fibre Channel over Ethernet) tendieren eher zu besseren Latenzzeiten. Durch zusätzliche Schichten wie z.B. Storage-Virtualisierung können noch zusätzliche Latenzen hinzukommen.

Die meisten Aufgaben eines Intra2net Systems werden typischerweise durch die Latenz von Festplattenzugriffen beschränkt und nicht durch Festplattendurchsatz oder fehlende CPU-Leistung. Dieser Punkt kann die Leistung eines Intra2net Systems also merklich beeinträchtigen.

Wir empfehlen, dies durch den Einsatz schnellerer Festplatten (15.000 RPM) oder Solid-State-Disks zu kompensieren.

Außerdem empfehlen wir das virtuelle Laufwerk für das Intra2net System nicht als dynamisch wachsend / bei Bedarf zugeteilt zu konfigurieren, sondern von Anfang an vollständig zuzuweisen und zu allokieren. Wenn das Laufwerk erst bei Bedarf wächst, kostet dies Performance bei Schreibzugriffen. Außerdem werden zusätzliche Verwaltungsinformationen benötigt, die vor einem Zugriff erst abgerufen und danach evtl. angepasst werden müssen. Bei klassischen Festplatten werden durch die ungleichmäßige Aufteilung der Blöcke zusätzliche Repositionierungen der Schreib-/Leseköpfe benötigt.

Wird das Intra2net System als Router und Firewall eingesetzt und stellt damit die Verbindung zum Internet her, kommt er direkt mit Netzwerkpaketen aus dem Internet in Berührung. Das Intra2net System ist dafür konzipiert und kann mit nicht standardkonformen oder gar bösartigen Paketen korrekt umgehen. Auch werden evtl. erkannte Lücken in den Treibern oder Funktionen zeitnah durch Updates geschlossen.

Wird das Intra2net System als virtuelle Maschine betrieben und seine Netzwerkkarten über die regulären Netzwerkfunktionen eines Virtualisierungssystems verwaltet, dann wird das Virtualisierungssystem diesen Paketen ungefiltert ausgesetzt. Dies gilt normalerweise für den Netzwerkkartentreiber und den virtuellen Switch.

Virtualisierungssysteme sind in der Regel nicht als Firewall konzipiert. Daher werden Updates der Treiber für die Netzwerkkarten und den virtuellen Switch nicht so kritisch eingestuft und dementsprechend weniger schnell verteilt und eingespielt. Dies erhöht letztendlich das Risiko von Störungen oder Angriffen.

Wir raten daher dringend davon ab, Netzwerkkarten, die direkt mit dem Internet verbunden sind, über die regulären Netzwerkfunktionen des Virtualisierungssystems (typischerweise virtuelle Switches) anzubinden.

Stattdessen empfehlen wir, die entsprechenden Netzwerkkarten als komplette PCI-Geräte an die virtuelle Maschine durchzureichen. Das Intra2net System steuert damit die Hardware über PCI-Zugriffe direkt an und die Virtualisierungslösung kommt gar nicht erst mit diesen Netzwerkpaketen in Berührung.

Achtung

Beachten Sie, dass diese Funktion nicht von allen Virtualisierungssystemen angeboten wird und auch dann nur mit Unterstützung der Hardware (Intel VT-d bzw. AMD-Vi in Prozessor und Chipsatz sowie passenden Beschreibungstabellen im BIOS) verfügbar ist. Prüfen Sie daher bereits in der Planungsphase die Kompatibilität. Außerdem ist beim Durchreichen von kompletten PCI-Geräten in der Regel keine Live-Migration der VM mehr möglich. Eine VM muss daher vor einer Migration auf eine andere Hardware erst heruntergefahren werden.

Verwenden Sie alternativ eine zusätzliche Hardware-Firewall oder installieren das Intra2net System nicht als virtuelle Maschine, sondern auf dedizierter Hardware.