Servervirtualisierung

Die Servervirtualisierung mit den Produkten wie VMWare und Hyper-V ist verantwortlich, dass auch kleinere Unternehmen mit dem Virtualisierungsgedanken spielen.
Der Kerngedanke der Servervirtualisierung ist die virtuelle Maschine (Virtual Machine, VM), welche die Basis für die Serverbetriebssysteme bildet. Der Hypervisor entkoppelt die physikalische Hardware von den virtualisierten Servern, der Zugriff auf die physikalischen Ressourcen wird grundsätzlich durch den Hypervisor sichergestellt.
Es gibt jedoch auch die Möglichkeit (je nach verwendeter Virtualisierungstechnologie, die sogenannte «Pass through» Funktion zu verwenden. So kann beispielsweise eine Festplatte oder ähnliches direkt in die Virtuelle Maschine weitergegeben werden.
Anders als bei der klassischen Paravirtualisierung, welche eine Adaption der Gastbetriebssysteme für die Virtualisierungstechnologie erfordert, können ältere, nicht adaptierte Betriebssysteme über eine Emulation des Host-Betriebssystems betrieben werden. Diese Möglichkeit wird nicht von allen verfügbaren Produkten unterstützt und verursacht logischerweise eine beträchtliche Leistungseinbusse.
Servervirtualisierung entspricht technologisch in der regel der Desktop- und teilweise auch der Anwendungsvirtualisierung. Bei der Servervirtualisierung werden nun aber die in den VMs betriebenen Betriebssysteme direkt genutzt.
Einsatzbeispiele: Kleinunternehmen mit einzelnen Hosts bis zu Cloud-Rechenzentren mit vielen physikalischen Computern.

Der virtuelle Computer

Ein virtueller Computer oder eine VM (Virtual Machine) besteht aus ähnlichen Komponenten wie ein physikalischer Computer. Der unterschied ist, dass keine Hardware vorhanden ist, sondern diese nur Virtuell zur Verfügung gestellt wird und nie mehr Leistung haben kann als der Physikalische Computer. Der Zugriff auf die physikalische Hardware erfolgt über den Hypervisor bzw. den VM-BUS.

Virtuelle Maschinendefinition (VMC, Virtual Machine Configuration)

Die Virtuelle Maschine muss wissen, welche «Hardware» sie zur Verfügung hat. Deswegen besteht anstelle von Hardware eine «Beschreibung» bzw. Konfigurationsdatei, welche oft in einem XML oder Textformat abgespeichert ist mit der Definition der entsprechenden Hardware. Je nach verwendeter Virtualisierungssoftware, kann diese z.B. mit https://notepad-plus-plus.org/ (Notepad ++) oder aber auch über ein GUI bearbeitet werden.

Betriebssystem

Die virtuelle Instanz führt ein Betriebssystem aus, dieses verwendet nun aber nicht die Hardwaretreiber der physikalischen Hardware, sondern sogenannte synthetische Treiber für den Zugriff über den VM-BUS.
Das virtuelle Betriebssystem hat lediglich den Zugriff auf diejenigen Hardwareressourcen, welche dieser VM zugewiesen wurden.

Anwendungen

In dieser VM können Anwendungen ganz normal bzw. wie gewohnt installiert und ausgeführt werden. Diese Anwendungen laufen in der Umgebung des virtuell betriebenen Betriebssystem. Anwendungen sind entkoppelt, damit die Virtualisierung keinen Einfluss auf die Anwendung hat.
Anwendungen bei welches zu Problemen kommen kann:
– An die Hardware, zum Beispiel die MAC-Adresse, gekoppelte Produktaktivierungen (Dies kann je nach Virtualisierung auch umgangen werden, sofern die Ursprüngliche Maschine nicht mehr in Betrieb genommen wird.
– Nicht unterstützte Hardware wie Dongles oder spezielle Schnittstellenkarten.

Start- und Shutdown-Verhalten

Wenn die VM in einer hochverfügbaren, geclusterten Virtualisierungsumgebung ausgeführt werden, sollte die VM im Falle eines Hardwareausfalls automatisch auf einen anderen Host (Server) verschoben werden. In Extremfällen kann aber auch ein kompletter Cluster heruntergefahren werden müssen. Also muss für die VM festgelegt werden, wie sie sich im Falle des Herungerfahrens und wieder Hochfahrens des Hypervisors verhalten soll.

Shutdown-Einstellungen

Folgende Optionen werden in den bekanntesten Virtualisierungen angeboten:

  • Herunterfahren
  • Sichern (das Laufzeitabbild wird in eine Datei gesichert)
  • Ausschalten (nicht empfehlenswert! – Ähnlich wie bei einem Physischen Computer den Stecker ziehen)

Start-Einstellungen

Folgende Optionen werden in den bekanntesten Virtualisierungen angeboten:

  • Automatischer Start
  • Verzögerter Start (normalerweise mit Angaben in Sekunden)
  • Nicht automatisch starten / Ausgeschaltet bleiben
  • Fortsetzen

In Cloud-Umgebungen können zentrale Verwaltungswerkzeuge wie VMWare, vSphere oder Microsoft System Center auch komplexere Startkonfigurationen über sogenannte «Runbooks» gesteuert werden. Beispielsweise, wenn zuerst der Active Directory zur Verfügung stehen muss, wird gewartet, bis der entsprechende Service zur Verfügung steht, bevor die nächste VM startet. Dies kommt zum Beispiel zur Anwendung, wenn Updates installiert wurden und Windows sich zuerst konfigurieren muss, jedoch nicht bekannt ist, wie lange der Vorgang dauert.

Virtuelle Hardware

Die Anforderungen an die virtuelle Hardware ist analog der physikalischen Hardware zu werten. Deshalb umfasst die Konfiguration einer VM analog eines Physikalischen Computers ähnliche Komponenten.
Die vom Hypervisor zur Verfügung gestellte Hardware kann bei den verschiedenen Virtualisierungsprodukten unterschiedlich sein, deckt aber minimal folgende Komponenten ab.

BIOS / Firmware-Einstellungen

Eine VM muss wie ein physikalischer Computer einen Startprozess durchlaufen und benötigt deswegen die entsprechenden Konfigurationsinformationen. Bei älteren Hypervisoren waren dies BIOS-Einstellungen, heute ist bei den meisten VMs der Startprozess durch Firmware gesteuert (Enhanced Firmware Interface, EFI).
In diesem Bereich wird z.B. die Startreihenfolge festgelegt wobei sich die Einstellungen natürlich auf die virtuellen Komponenten beziehen. Eine Ausnahme bildet vielleicht das CD/DVD-Laufwerk oder Festplatte; die Einstellung ist zwar die virtuelle Instanz, diese kann aber bei den meisten Systemen dem physikalischen Laufwerk (pass through) oder einer Abbilddatei (ISO-Datei) zugewiesen werden.

Prozessor

Der Prozessor (CPU, Central Processing Unit) wird nicht im eigentlichen Sinne virtualisiert, da es schlussendlich immer eine physikalische Einheit sein muss, welche die Berechnung ausführt.
Die Leistung der physikalischen CPU ist vergleichbar dem Verfahren eines präemptiven Multitaskingsystem den virtuellen CPUs der VM zugeordnet. Dabei wird ein «Zeitscheinebverfahren» ähnlich dem TDM (Time Division Multiplexing) verwendet. Der Kern einer CPU kennt eigentlich nur den Zustand beschäftig oder unbeschäftigt (idle), alle prozentualen Auslastungen sind jeweils Durchschnittswerte über einen Zeitraum hinweg.
Der Hypervisor verwaltet somit die CPU-Zugriffe und gewährt den VMs je nach Konfiguration der virtuellen Prozessoren Zugriff. Sofern mehrere physikalische Kerne verfügbar sind, können der jeweiligen VM auch mehrere virtuelle CPU zur Verfügung gestellt werden.
Neben der Anzahl der virtuellen Prozessoren können bei der Prozessordefinition zumeist auch noch weitere Konfigurationen vorgenommen werden.

CPU-Limitierung

Die eigentliche Leistungsfähigkeit der CPU kann beschränkt werden, um andere VMs mehr Leistung zur Verfügung zu stellen. Die Limiterung kann absolut oder relativ zur gesamten zur Verfügung stehenden Leistung definiert werden.
Dieser Mechanismus wir auch als «CPU Throttling» bezeichnet.

Prozessorkompatibilität

Aus Kompatibilitätsgründen kann es notwendig sein, spezielle, propritäre Maschinen befehle für eine VM auszuschliessen. Dadurch wir die Kompatibilität der VM beim Verschieben auf andere Prozessorarchitekturen zwar erhöht, aber unter Umständen leidet die Leistung etwas.

Hardwareintegration

Aktuelle Serverprozessoren unterstützen unterschiedliche Verfahren zur Verwaltung des CPU-nahen schnellen Arbeitsspeichers (Chache) wie UMA (Uniform Memory Allocation) oder NUMA (Non-Uniform Memory Allocation).
Im ersten Fall greifen alle physikalischen CPUs auf denselben Arbeitsspeicher zu. Die Zugriffszeiten sind bei diesem Verfahren immer gleich.
Beim NUMA-Verfahren kann es zwar auch geteilten Arbeitsspeicher geben, die einzelnen Prozessoren verfügen aber primär über eigenen, schnell angebundenen Arbeitsspeicher, auf welchen die anderen Prozessoren nur über die langsameren Pfade zugreifen können.

Arbeitsspeicher

Die Arbeitsspeicherverwaltung eines Hypervisors funktioniert nach ähnlichen Prinzipien wie im Abschnitt «Virtueller Speicher», beschriebenen des Virtual Memory Managements.
Wichtige Unterschiede der Arbeitsspeicherverwaltung innerhalb eines Betriebssystemes gegenüber der Speicherverwaltung in Hypervisoren:

  • In einem Betriebssystem teilen sich Anwendungen den Arbeitsspeicher, somit können Anwendungen Dateien teilen. In Hypervisoren wird aus Sicherheitsgründen kein oder nur ein kleiner, vom Hypervisor kontrollierter, gemeinsamer Speicher verwendet. Die VMs sollen nicht direkt über den Arbeitsspeicher kommunizieren können, das ist Teil der Typ-1-Hypervisor-Virtualisierung. VMs sollen hierbei wie Physische Geräte die «Netzwerkkarte» benutzen.
  • Wird im Betriebssystem allen Anwendungen, zumindest der gleichen Architekturebene, gleich viel virtueller Arbeitsspeicher zugewiesen, wird im Hypervisor je nach Bedürfnis der VM die Menge des Arbeitsspeichers konfiguriert.

Aktuelle Hypervisoren unterstützen «dynamische Arbeitsspeicherverwaltung». Bei der Konfiguration des Arbeitsspeichers wird zweischen Startspeicher (in dieser Phase sind noch keine Integrationsdienste für die Kommunikation zwischen Hypervisor und Betriebssystem geladen) und Betriebsarbeitsspeicher (wenn die Kommunikation zwischen Hypervisor und Betriebssystem etabliert ist) unterschieden.
Wird die dynamische Arbeitsspeicherverwaltung nicht genutzt, wird jeweils der definierte physikalische Speicher fest dieser virtuellen Instanz zugewiesen, sobald diese gestartet wird steht der physikalische Speicher nicht mehr für andere Aufgaben zur Verfügung. Gestarteten VMs kann mehr Speicher zugewiesen werden, als physikalisch vorhanden ist. Dies bedeutet jedoch nicht, dass ein «Supercomputer» virtuell geschaffen werden kann, sondern wird der physikalische Arbeitsspeicher überschritten, frieren in der Regel die VMs ein.
Die dynamische Abreitsspeicherverwaltung erlaubt es, den VMs potenziell mehr Arbeitsspeicher zur Verfürung zu stellen, als physikalisch vorhanden ist (overcommitment). Bei dynamisch zugewiesenen Speicher werden in der Regel folgende Werte konfiguriert:

Startspeicher

Dieser Speicher ist beim Startvorgang der VM fest zugewiesen und steht während des gesamten Startprozesses vollumfänglich zur Verfügung. Kann der Hypervisor nicht genügend Arbeitsspeicher frei machen, kann die VM nicht gestartet werden.

Minimaler- / Maximaler- Abreitsspeicher

Sobald die Integrationsdienste funktionieren, welches nach der initialisierung des Gastbetriebssystem gegeben ist, kann der der Instanz zugewiesene Arbeitsspeicher vom Hypervisor im Rahmen dieser Konfiguration angepasst werden.

Reserve

Diesen Prozentsatz des aktuell verwendeten Arbeitsspeichers der VM wird der Hypervisor für die VM reserviert halten. Dieser Speicher kann nicht von anderen VMs verwendet werden, weder als Startspeicher noch als dynamisch genutzer Speicher. Er ist also physikalisch fest zugewiesen.

Gewichtung

Dieser Wert gibt die Gewichtung (Wichtigkeit) der VM gegenüber anderen virtuellen Instanzen an. Eine kleine Gewichtung kann bei knappem Arbeitsspeicher dazu führen, dass die VM nicht gestartet werden kann, oder das der ihr zugewiesene Arbeitsspeicher bis auf das definierte Minimum reduziert wird, damit anderen VMs mehr Arbeitsspeicher zur Verfügung steht.

Festplattenkontroller / Festplatten

Festplatten haben eine ganz spezielle Rolle. Darum werde ich sie im Abschnitt «Die virtuelle Festplatte», speziell behandeln.
Virtuelle Festplatten benötigen wie physikalische Hardware zur Ansteuerung dieser einen Festplatten Kontroller.

IDE-Kontroller unterstützen nur zwei angeschlossene Geräte (Festplatten und / oder CD / DVD-Laufwerke. SCSI-Kontroller unterstützen bis zu 64 angeschlossene Geräte. Dabei wird jedes Gerät (bzw. jede Festplatte) mittels einer ID identifiziert wie bei physikalischen SCSI-Festplatten.

Je nach Implementation und Integration des Hypervisors unterliegen die Kontroller Einschränkungen. So sind zum Beispiel die Festplatten an SCSI-Kontrollern bei Hyper-V Generation 1 VMs nicht startfähig.

Netzwerkkarten

Eine VM benötigt wie ein Physikalischer Computer eine Netzwerkkarte um mit dem Netzwerk / Internet kommunizieren zu können. Somit kann der Hypervisor einer VM eine oder mehrere virtuelle Netzwerkkarten zur Verfügung stellen.
Eine der wichtigsten Konfigurationen ist die Einstellung, mit welchem virtuellen Netzwerk die Netzwerkkarte verbunden ist. Verglichen mit der physikalischen Welt versinnbildlicht dies, an welchen Netzwerkswitch im Patch-Raum die Netzwerkkarte mit einem Kabel angeschlossen werden soll. Es ist also etwas wie ein virtuelles Kabel, auch wenn der Ausdruck so nicht gebraucht wird. Bei Fehlersuchen hilft diese Vorstellung jedoch sehr.

Des Weiteren können virtuelle Netzwerkkarten über folgende Einstellungen verfügen (ein Teil davon steht nur zur Verfügung, wenn auch die physikalische Hardware sie unterstützt).

VLAN / VLAN ID

Der Netzwerkverkehr der entsprechenden Netzwerkkarten wird über ein VLAN-Tag identifiziert und somit einem virtuellen LAN zugewiesen Die Ethernet-Pakede werden dann von den physikalischen Switches gemäss den definierten Regeln behandelt.

Breitbandmanagement

Diverse Hypervisoren unterstützen die Breitbandverwaltung («bandwidh throtteling») auf Ebene der virtuellen Netzwerkkarten.

Hardwarezugriff und «offloading»-Mechanismen

Bestimmte physikalische Hardware stellt technische Mechanismen zur Beschleunigung der Netzwerkzugriffe und zur Entlasung des Betriebssystems bereit. Diese Mechanismen können auch bei virtuellen Netzwerkkarten genutzt werden, wenn sie von der Hardware und dem Hypervisor unterstütz werden.
Dazu gehören:

  • Virtual machine Queue VMQ
  • Single-root I/O Virtualization SR-IOV
  • TCP Checksum Offload
  • IPsec Offload
  • iSCSI Offload
MAC-Zuordnung

Jede Ethernet-Netzwerkkarte benötigt eine eindeutige MAC-Adresse (Media Access Control).
Diese MAC-Adressen werden idealerweise vom Hypervisor oder sogar einer übergeordneten Verwaltungsoftware zentral verwaltet un den einzelnen virtuellen Netzwerkkarten zugewiesen. Die zentrale Verwaltung kann aber auch kartenspezifisch übersteuert werden.

Weitere Konfigurationen

Hypervisoren können weitere Funktionen für die Netzwerkarten zur Verfügung stellen. Dazu gehört zum Beispiel eine Schutzfunktion, damit keine DHCP-Offerten über ein bestimmtes Interface übertragen werden können (DHCP Guard), eine analoge Funktion für IPv6-Router-Adversting-Pakete (Router Guard) oder eine Spiegelungsfunktion für Netzwerkpakete (Port Mirroring) für die Aufzeichnung mit Netzwerküberwachungssoftware.

Weitere Hardware

Je nach Hypervisor werden weitere Hardwarekomponenten zur Verfügung gestellt:

  • «Legacy» Hardware
  • Folppy Disk
  • Serielle Schnittstellen (COM)
  • Fibre Channel Adapter
  • Remote FX Video Adapter
«Legacy»-Geräte

Legacy-Geräte sind die Hinterlassenschaften früherer Technologien. Sie werden häufig verwendet, wenn die neuen Technologien noch nicht alle notwendigen Funktionen unterstützen.

Serielle Schnittstellen (COM)

Serielle Schnittstellen werden heute immer wendiger verwendet, finden aber bei Zugriffen auf ältere oder sehr spezielle Hardware immer noch Verwendung.

Floppy Disk

Virtuelle Floppy Disks werden immer weniger verwendet, können aber zum Beispiel für Antwortdateien bei automatisierten Installationen genutzt werden.

Fiber Channel Adapter

Verfügt der Virtualisierungshost über einen physikalischen Fiber-Channel-Adapter, können den VMs über virteulle FC-Adapter direkte Zugriffe auf FC SAN (Storage Area Networks) ermöglicht werden.

RemoteFX-Videoadapter

Die Funktionen einer physikalischen RemoteFX-Grafikkarte können so der virtuelle Instanz zur Verfügung gestellt werden.


Die letzten beiden Möglichkeiten gehören eher zu den moderneren Technologien, während die ersten drei alle eher zu den Hinterlassenschaften frühererer Technologien gehören.

Die Virtuelle Festplatte

Eine VM kann wie ein physikalischer Computer über eine oder mehrere virtuelle Festplatten verfügen. Aus Sicht des Hypervisors sind die virtuellen Festplatten Dateien auf einer lokalen Ressource. Diese kann eine lokale Festplatte, ein lokales RAID-System, ein direkt angeschlossenes Storage System (DAS) oder ein iSCSI Target in einem SAN sein. In gewissen Fällen wird auch ein NAS (Network Attached Storage) unterstütz, wobei hier bei Weitem nicht alle Technologien die für diesen Zweck notwendige Leistung erbringen.
In der Regel besteht die virtuelle Festplatte (VHD, Virtual Harddisk) aus einer einzelnen Datei; je nach Konfigurationsart und Verwendung der Festplatte können aber auch verschiedene physikalische Dateien die virtuellen Festplatten definieren. Dies ist bei differenziellen Festplatten und auch bei der Verwendung von Snapshots der Fall.

Festplatten fester Grösse – Thick Provisioning

Der für die virtuelle Festplatte definierte Platz wird im physikalischen System fest reserviert und steht nicht mehr für andere Funktionen zur Verfügung. Für das feste Zuweisen der Blöcke für eine virtuelle Festplatte wird auch der begriff «Thick Profisioning» verwendet.

Dynamisch erweiterbare Festplatten – Thin Provisioning

Die virtuelle Festplatte wird zwar ebenfalls mit einer bestimmten Grösse definiert, es wird aber nur der aktuell benötigte Speicherpaltz auf dem physikalischen Medium belegt. Die Speicherdatei wird grösser, je mehr Daten die VM in die VHD schreibt.
Der Mechanismus wird auch als «Thin Provisioning» bezeichnet, wobei der nicht mit dem Thin Provisioning der Speichervirtualisierung verwechselt werden darf, der zwar das selbe Ziel verfolgt, nämlich Speicherplatz erst bei Bedarf zuzuordnen, aber technisch anders realisiert ist.

Differenzielle Festplatte

Beim System der differenziellen Festplatte können mehrere virtuelle Festplatten auf demselben Basisdatenträger basieren. Die spezifischen Modifikationen, welche an einer Festplatte gemacht werden, werden in eine dynamisch wachsende differenzielle Festplatte geschrieben.

Snapshots

Bei Virtuellen Festplatten gibt es die Möglichkeit von Snapshots / Checkpoints, welches bei Physikalischen Festplatten so nicht direkt gibt. Snapshots umfassen nicht nur den Aktuellen Zustand der virtuellen Festplatte, sondern auch die Aktuelle Konfiguration sowie den Inhalt des aktuellen Arbeitsspeichers.
Ein Snapshot hält den aktuellen Systemzustand der VM fest, das heisst, er bildet konsistent den Zustand der VM zum Zeitpunkt der Erstellung des Snapshots ab – Sprich Zustand, Eingeschalten, Ausgeschalten, … Aktuelle Konfiguration etc.
Ist die VM beim Zeitpunkt des Snapshots eingeschalten, wird auch der Arbeitsspeicher «gespeichert» und kann im Falle eines Rollbacks auf diesen Snapshot wieder hergestellt werden.
Auch wenn der Begriff «Snapshot» impliziert, dass eine «Kopie», ein «Abbild» der VM erstellt wird, so ist dies technisch nicht korrekt. Technologisch ist der Snapshot sehr eng mit der differenziellen Festplatte verwandt. Der Snapshot entspricht dabei dem Basisdatenträger. Sobald ein Snapshot erstellt wird, wird der aktuelle Zustand «eingefroren» und die nachfolgenden Änderungen aufgezeichnet in «eigenen» *.vhd / *.vhdx / bzw. *.avhdx Files.
Die so definierten Zetabbilder können nun jederzeit wieder mittels einer Rückkehrfunktion (revert) oder dem Anwenden (apply) eines Snapshots wieder aktiviert werden.

Hinweis: Ein Snapshot ersetzt kein Backup!

Snapshots eignen sich vorallem gut in Testumgebungen, da dies ein sehr leistungsfähiger Mechanismus ist. Allerdings kann diese Technologie auch Gefahren bergen. Diese werden nachfolgend kurz beschrieben.

Festplattenplatz

Da der Snapshot den «alten» Systemzustand einfriert, bleiben auch alle alten Informationen erhalten, müssen gespeichert werden und belegen so physikalischen Speicherplatz. Wird beispielsweise eine VM auf eine neuere Betriebssystemversion aktualisiert, so werden in der aktuellen Konfiguration viele der alten Betriebssystemdateien durch neuere Dateien ersetzt. Der Platz der alten Dateien wird innerhalb des Betriebssystems wieder frei. Da der Snapshot aber weiterhin den Zustand vor der Aktualisierung speichern muss, belegen dort die Dateien der Vorgängerversion weiterhin physikalischen Festplattenplatz.
Der Festplattenplatz kann wieder freigegeben werden, indem ein Snapshot gelöscht wird; dann werden die betroffenen Datenträger zusammengeführt (merging). Nach dem Zusammenführen verschwinden die entsprechenden Snapshot-Dateien, und der Speicherplatz wird freigegeben.

Systemintegrität

Da es sich bei einem Snapshot immer um ein Abbild aus der Vergangenheit handelt, werden beim Anwenden des Snapshots auch die Einstellungen der Konfigurationen der Vergangenheit wieder wirksam.
Speziell bei Client-Servernetzwerken können Probleme mit abgelaufenen Zugriffstickets oder geänderten Kennwörtern auftauchen. Ein typisches Problem kann sein, dass die VM von einem Verzeichnisdienst nicht mehr erkannt wird. In einer Microsoft-Domäne zeigt sich das anhand der Fehlermeldung «Es konnte keine Verbindung zur Domäne hergestellt werden».
Ebenfalls Vorsicht ist bei verteilten Systemen geboten oder auch nur für einfache datenbankbasierte Anwendungen, wenn bei der Anwendung eines Snapshots für einen Teil des Systems plötzlich die verschiedenen Systemkomponenten nicht mehr kompatibel sind.

Formate für virtuelle Festplatten

Bei den virtuellen estplatten sind die Dateisysteme innerhalb der virtuellen Festplatte und der Aufbau der Datei, welche die virtuelle Festplatte im Speichersystem abbildet, zu unterscheiden. Das oder die Dateisysteme innerhalb sind vom Betriebssystem abhängig und unabhängig von der verwendeten Virtualisierungstechnologie.
Die verschiedenen Hersteller verwenden auch unterschiedliche Formate für die virtuellen Festplatten. Die kleineren Anbieter fokussieren aber immer mehr auf die nachfolgenden beschriebenen De-Facto-Standardformate.

Microsoft VHD, VHDX

Microsoft verwendet für die Bezeichnung der virtuellen Festplatten ab Hyper-V 2008 die Bezeichnung VHD, also dieselbe Abkürzung, die auch allgemein als «Virtual Harddisk» verwendet wird.
Das VHD-Format wird auch von folgenden Anbietern unterstützt: Oracle VirtualBox, Sun xVM, Citrix XenServer und auch VMware.
Das VHD-Format wird von Microsoft auch für weitere, nicht direkt mit der Virtualisierung zusammenhängende Mechanismen verwendet:

  • Native Boot to VHD, als Alternative zu Mehrfachbootsystemen
  • Backup, ab Windows Vista wird das VHD-Format als Sicherungsformat verwendet.

Da das VHD-Format auch gemountet werden kann, kann es auch offline, das heisst unabhängig von Virtualisierungs- oder Sicherungstechnologien zum Beispiel für die offline-Wartung von Abbildern oder zum Wiederherstellen von Dateien verwendet werden.
Das VHD-Format unterstützt lediglich eine Festplattengrösse von bis zu 2 TB. Seit Server 2012 / Windows 8 wird das neuere VHDX-Format unterstützt, welches virtuelle Festplatten bis zu einer Grösse von 64 TB unterstützt.
Seit Windows 10 wird ein neues Format VHDS unterstützt, welches das Teilen von virtuellen Festplatten zwischen verschiedenen VMs erlaubt.
Eine spezielle Funktion übernehmen die AVHD-Dateien, das Format wird für differenzielle Festplatten im weitesten Sinne verwendet. Es kommt zum Beispiel bei folgenden Mechanismen zur Anwendung:

  • Snapshots / Checkpoints
  • Basisdatenträger (differenzielle Festplatten)
  • VSS-Sicherungsmechanismen
VMware VMDK

Das VMDK-Format (Virtual Machine Disk) wurde von VMware propritär entwickelt, gilt jetzt aber als offener Standard für die Definition von virtuellen Festplatten. VDMK erlaubte erst auch virtuelle Festplatten bis 2 TB und seit 2013 Festplatten bis 64 TB.
VMDK wir von folgenden Produkten unterstützt: Parallesl Desktop, Sun xVM, VirtaulBox und Norton Ghost.

Virtuelle Netzwerke

Damit virtuelle Computer auf einem Hypervisor untereinander kommunizieren können, benötigen Sie neben den virtuellen Netzwerkkarten auch ein virtuelles Netzwerk.
Der Betriff virtuelles Netzwerk wird in der Regel hostübergreifend verwendet. Abgebildet werden die virtuellen Netzwerke auf den Hypervisoren als virtuelle Switches, an welche die Netzwerkkarten angeschlossen werden.Bei den virtuellen Switches können drei Typen unterschieden werden.

Externe Switches

Externe Switches werden mit einer physikalischen Netzwerkkarte des Hypervisorts verbunden und erlauben es den VMs, direkt auf das physikalische Netzwerk zuzugreifen.
In der Regel kann nur ein virtueller Switch auf ein physikalisches Interface zugreifen. Im Idealfall bekommt das Hostbetriebssystem eine eigene physikalische Netzwerkkarte. Ist nur eine Netzwerkkarte vorhanden, muss der Datenverkehr des Hostbetriebssystems und der VMs über dieselbe Netzwerkkarte laufen.

Private Switches

Der Ausdruck «privat» bezieht sich hier auf den Hypervisor. Das heisst, dass über einen privaten Switch nur Gastbetriebssysteme kommunizieren können, welche
a) auf diesem Host laufen
b) mit diesem Switch verbunden sind.
Auf einem Host können mehrere private Switches definiert und so beispielsweise eine Testumgebung die aktuellen Netzwerkkonditionen mit IP-Subnetz nachgestellt werden.

Interne Switches

Der Unterschied der privaten Switches zu den internen liegt im Einbezug des Hostbetriebssstems. So kann der Host bei privaten Switches nicht über diesen Switch direkt erreicht werden, bei den internen Switches kann das Hostbetriebssystem in die Kommunikation über den internen Switch eingebunden werden.
Gerade bei Typ-2-Hypervisoren wird diese Art Netzwerk gerne verwendet, um die VMs zwar vom physikalischen Netzwerk zu trennen, ihnen aber gleichzeitig über NAT den Zugriff auf die physikalische Netzkarte zu gestatten.
NAT und ein für das interne Netzwerk zu verwendender DHCP-Dienst sind unter Umständen sehr wertvoll, sind aber nicht zwingender Bestandteil eines internen Switches und werden nicht von allen Hypervisoren geboten.

Teaming

Sowohl aus Gründen der Ausfallsicherheit als auch der Leistung können mehrere physikalische Netzwerkkarten zu «Teams» zusammengefasst werden. Da dieses Teaming auch schon unabhängig von der Servervirtualisierung eingesetzt wurde, sind auch heute noch unterschiedliche Ansätze des Netzwerkkarten-Teamings vorhanden.

Hardware / Firmware

Die Funktion des Teamings wird über die Firmware geregelt, die Steuerungssoftware des Hardwareherstellers. Der Hypervisor sieht das Netzwerkkartenteam als einzelnen Anschluss.

Hypervisor

Die Managementsoftware verwaltet ie physikalischen Netzwerkkarten selber. Netzwerkkartenteams können also unabhängig von der Firmware und den Karten definiert werden.

VLANs und virtuelle Switches

Um den verschiedenen Anforderungen in den virtuellen Netzwerken gerecht zu werden, können nun auch noch VLAN-Tags verwendet werden. Die VLANs können auf zwei Ebenen verwendet werden.

Virtueller Switch

Auf externen Switches kann der Netzwerkverkehr des Hostbetriebssystems speziell markiert (getagged) werden, sofern dafür nicht eine separate Netzwerkkarte zur Verfügung gestellt werden kann.

Virtuelle Netzwerkkarte

Der durch die VMs verursachte Netzwerkverkehr wird über die virtuellen Netzwerkkarten einem VLAN zugeiwiesen.
Somit kann als Netzwerkverkehr von VMs auch über verschiedene Hosts hinweg durch VPNs getrennt werden, sorfern das physikalische Netzwerk VPN-fähig ist.

Der Hypervisor stellt Funktionen zur Verfügung, welche von normaler Hardware nicht benötigt oder nicht zur Verfügung gestellt werden.
Eines der offensichtlichen Beispiele dafür ist die Übergabe des Mauszeigers, vom Hostbetriebssystem zum Gastbetriebssystem in der Konsolensitzung und zurück. Normalerweise ist nur ein Betriebssystem für die Verwaltung der Maus zuständig, in einem Hyper-Visor-System muss noch der Mauszeiger korrekt übergeben werden und weitere Mausaktionen demjendigen Betriebssystem übergeben werden, welches der aktuellen Position der Maus zuständig ist.
Ds ist eine der Funktionen welche in der Regel durch die VM-Addition oder Integrationsdienste zur Verfügung gestellt werden müssen; andere Integrationsdienste können je nachdem aktiviert oder deaktiviert werden.

Heartbeat

Damit die Verwaltungssoftware den Betriebszustand der VM erkennen kann, wird ein regelmässiges Signal von der VM an den Hypervisor gesendet. Dieser Mechanismus wird sinnigerweise auch als Heartbeat (Herzschlag) bezeichnet.

Operating System Shutdown

Normalerweise kommt das Signal, um ein Betriebssystem herunterzufahren, entweder von innerhalb des Betriebssystems (der VM) oder übre das Netzwerk (remote shutdown). Der Hypervisor kann über den entsprechenden Dienst auch ohne Netzwerkverbindung oder lokale Anmeldung herunterfahren.

Datenaustausch

Unter Umständen ist es wünschenswert, wenn zwischen Host und VM gewisse Daten ausgetauscht werden können, um zum Beispiel Skripte in eine VM zu kopieren.

Backupintegration

Eine VM kann über die üblichen Sicherungsmechanismen wie ein physikalischer Computer gesichert werden. Es kann aber auch sinnvoll sein, die virtuellen Festplatten als solche auf dem Hypervisor zu sichern (alternativ oder ergänzend).
Damit die VM, im Speziellen die virtuellen Festplatten, konsistent gesichert werden können, wird der entsprechende Integrationsdienst benötigt, welcher verhindert, dass während der Sicherung die virtuellen Festplatten verändert werden.

Zeitsynchronisation

Die VMs können die Systemzeit vom Hypervisor übernehmen wie physikalische Computer von der Hardware. Im Gegensatz zu einer physikalischen Installation übernehmen hier aber normalerweise mehrere VMs die Systemzeit, und anders als bei der physikalischen Installation können die VMs aber die Systemzeit der Hardware nicht zurückschreiben.
Wird die Zeit also durch ein übergeordneten Mechanismus vorgenommen, zum Beispiel die Active Directory Services, muss die Synchronisation mit der Zeit des Hosts ausgeschaltet werden können, insbesondere wenn der Host nicht ebenfalls Mitglied der AD ist.

Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.