Zum Hauptinhalt springen
Version: Weekly Build

Virtual Machines

title: "Virtuelle Maschinen" slug: /runtimes/virtual-machines sidebar_position: 4​

Virtuelle Maschinen

Preview-Funktion

Virtuelle Maschinen sind eine Preview-Funktion. Das hier beschriebene Verhalten, die Konfiguration und die Einschränkungen können sich in zukünftigen Releases ändern.

Mit Virtual Machines lässt sich eine vollständige Linux- oder Windows-VM parallel zu den containerisierten Workloads in einem Codesphere-Workspace bereitstellen. Anders als ein Reactive-Container bietet eine VM vollen Betriebssystem- und Administratorzugriff, mit konfigurierbarer CPU, konfigurierbarem Arbeitsspeicher und Speicherplatz sowie interner Vernetzung mit dem Rest der Landscape.

Virtual Machines sind hinter dem virtual-machines Preview-Flag verborgen. Die Funktion muss für die jeweilige Installation aktiviert werden, bevor VMs im Landscape Config Editor erscheinen.

Codesphere betreibt VMs mit KubeVirt auf Basis von Kubernetes.

Lebenszyklus​

Die Lebensdauer einer VM ist an ihre Landscape gebunden. Die VM wird beim Deployment der Landscape erstellt und beim Entfernen der Landscape gelöscht, zusammen mit allen im Gast-System vorgenommenen Änderungen. Ein erneutes Deployment der Landscape startet eine neue VM auf Basis des konfigurierten Images. Der Zustand der vorherigen VM bleibt nicht erhalten.

Images​

Codesphere-VMs unterstützen QCOW2- und Raw-Disk-Images, die entweder aus einer Container Registry (docker://) oder einem S3-kompatiblen Bucket (s3://) stammen.

Disk-Images aus einer Container Registry müssen containerdisk-Images sein. Ein containerdisk verpackt eine VM-Disk innerhalb eines Container-Images und verteilt sie über eine Container Registry.

Um einen S3-kompatiblen Bucket zu verwenden, wird das Feld "image" auf eine s3://-URL für das Objekt gesetzt. S3-Quellen benötigen eine Container Registry auf Team-Ebene, die für die URL konfiguriert ist – dieselben Zugangsdaten, die auch für private Container-Images verwendet werden. Dies gilt auch für öffentliche Buckets. Bei einer Container Registry enthalten die Felder Username und Password/access token den Registry-Benutzernamen und das Passwort. Bei einer S3-Quelle werden sie stattdessen für die Access Key ID und den Secret Access Key verwendet.

Windows-VMs​

Windows-Gastsysteme benötigen installierte VirtIO-Netzwerktreiber innerhalb des Gastsystems, um Netzwerkzugriff zu erhalten. Die Netzwerkschnittstelle der VM ist virtio-net, die über Masquerade bereitgestellt wird, und Windows liefert dafür standardmäßig keinen Treiber mit.

  • Hyper-V-Enlightenments (relaxed, VAPIC, spinlocks) sind aktiviert, um die Performance des Windows-Gastsystems zu verbessern. Diese verbessern die Performance, ersetzen aber nicht den VirtIO-Netzwerktreiber.
  • Der Disk-Bus ist SATA (nicht VirtIO), daher ist kein VirtIO-Speichertreiber erforderlich. Der Netzwerktreiber wird trotzdem benötigt.

Startet eine Windows-VM ohne Netzwerkverbindung, ist der fehlende VirtIO-Netzwerktreiber die wahrscheinlichste Ursache.

Eine virtuelle Maschine hinzufügen​

Virtual Machines werden über den Landscape Config Editor im Bereich CI & Deploy konfiguriert.

  1. Auf die Schaltfläche + Add New Service auf der rechten Seite des Bereichs Landscape Deployment klicken und Virtual Machine als Service-Typ auswählen.

    Dialog zum Hinzufügen einer neuen virtuellen Maschine im Landscape Config Editor

  2. Die VM konfigurieren. Name der VM, Disk-Image und Compute-Ressourcen festlegen.

    Konfigurationsformular für virtuelle Maschine mit Feldern für Image und Ressourcen

  3. Die Landscape speichern und synchronisieren. Nach dem Deployment erscheint die VM zusammen mit den anderen bereitgestellten Services.

    Ausführungsansicht mit der bereitgestellten virtuellen Maschine

Demo-Image​

Die Funktion lässt sich mit folgendem vorgefertigten Demo-containerdisk ausprobieren. Es enthält einen vorkonfigurierten Login.

Ubuntu 24.04 (XFCE-Desktop)

  • Image: docker://ghcr.io/codesphere-cloud/vm-demo/ubuntu-xfce:24.04
  • Mindestressourcen: 1 CPU, 1 GiB Arbeitsspeicher, 5 GiB Speicherplatz
  • Benutzername: codesphere
  • Passwort: codesphere

VM-Zugriff​

Über die Schaltfläche VNC an der bereitgestellten Virtual Machine lässt sich direkt aus der UI ein interaktives Fenster zu einer laufenden VM öffnen. Dies ermöglicht eine grafische Sitzung im Gast-System. Nützlich ist dies für die Ersteinrichtung, die Fehlerbehebung oder die Arbeit mit VMs, die noch über keinen anderen Netzwerkzugriff verfügen.

Die VNC-Sitzung unterstützt jeweils nur eine gleichzeitige Verbindung. Startet ein zweiter Benutzer eine VNC-Sitzung, wird die erste Verbindung getrennt.

Netzwerk​

  • Interne Vernetzung: Jede VM wird über einen internen Hostnamen der Form ws-vm-{workspaceId}-{vmName}.workspaces.svc.cluster.local bereitgestellt. Andere Services im selben Workspace erreichen die VM unter dieser Adresse oder innerhalb desselben Workspace unter dem Kurznamen ws-vm-{workspaceId}-{vmName}.
  • Ausgehender Zugriff: Das Netzwerk verwendet Pod-Masquerade (NAT), sodass VMs das Internet und andere Workspace-Services erreichen können.

Um einen auf einer VM laufenden HTTP- oder HTTPS-Endpunkt öffentlich bereitzustellen, wird ein Headless Service hinzugefügt, der eine öffentliche Route an den internen Hostnamen der VM weiterleitet.

Konsolenzugriff​

Eine textbasierte serielle Konsole zur VM ist für ein zukünftiges Release geplant. Bis dahin kann die unter VM-Zugriff beschriebene grafische VNC-Konsole verwendet werden.

Exportieren von VM-Images​

Der Export einer laufenden VM zurück in ein Container-Image ist für ein zukünftiges Release geplant. Damit lässt sich eine konfigurierte VM erfassen und als neues Basis-Image wiederverwenden.