Zum Hauptinhalt springen
Version: Weekly Build

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 Versionen ändern.

Mit Virtuellen Maschinen lässt sich eine vollständige Linux- oder Windows-VM parallel zu den containerisierten Workloads in einem Codesphere Workspace bereitstellen. Im Gegensatz zu einem reactive Container bietet eine VM vollen Betriebssystem- und Administratorzugriff, mit konfigurierbarer CPU, Arbeitsspeicher und Speicherplatz sowie interner Vernetzung zum Rest der Landscape.

Virtuelle Maschinen 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 führt VMs mit KubeVirt auf Basis von Kubernetes aus.

Lebenszyklus​

Die Lebensdauer einer VM ist an ihre Landscape gebunden. Die VM wird erstellt, wenn die Landscape bereitgestellt wird, und gelöscht, wenn die Landscape abgebaut wird – zusammen mit allen im Gast vorgenommenen Änderungen. Ein erneutes Deployment der Landscape startet eine neue VM aus dem konfigurierten Image. 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, muss das Feld „image“ auf eine s3://-URL des Objekts gesetzt werden. S3-Quellen benötigen eine auf Team-Ebene konfigurierte Container-Registry für die URL – 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-Gäste benötigen installierte VirtIO-Netzwerktreiber im Gastsystem, 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-Gasts zu verbessern. Diese verbessern die Leistung, ersetzen aber nicht den VirtIO-Netzwerktreiber.
  • Der Disk-Bus ist SATA (nicht VirtIO), daher ist kein VirtIO-Speichertreiber erforderlich. Der Netzwerktreiber wird jedoch weiterhin benötigt.

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

Hinzufügen einer Virtuellen Maschine​

Virtuelle Maschinen werden über den Landscape Config Editor im Bereich CI & Deploy konfiguriert.

  1. Auf die Schaltfläche + Add New Service rechts im Bereich Landscape Deployment klicken und Virtual Machine als Diensttyp auswählen.

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

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

    Konfigurationsformular für Virtuelle Maschinen mit Feldern für Image und Ressourcen

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

    Ausführungsansicht mit der bereitgestellten Virtuellen Maschine

Demo-Image​

Die Funktion lässt sich mit dem folgenden vorgefertigten Demo-containerdisk ausprobieren. Es wird mit einem vorkonfigurierten Login ausgeliefert.

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 Virtuellen Maschine lässt sich direkt aus der UI ein interaktives Fenster zu einer laufenden VM öffnen. Dies ermöglicht eine grafische Sitzung im Gastsystem. Nützlich ist dies für die Ersteinrichtung, die Fehlersuche oder die Arbeit mit VMs, die noch über keinen anderen Netzwerkzugriff verfügen.

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

Netzwerk​

  • Internes Netzwerk: Jede VM wird über einen internen Hostnamen der Form ws-vm-{workspaceId}-{vmName}.workspaces.svc.cluster.local bereitgestellt. Andere Dienste im selben Workspace können die VM unter dieser Adresse erreichen, 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-Dienste erreichen können.

Um einen auf einer VM laufenden HTTP- oder HTTPS-Endpunkt öffentlich verfügbar zu machen, muss ein Headless Service hinzugefügt werden, der eine öffentliche Route an den internen Hostnamen der VM weiterleitet.

Konsolenzugriff​

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

Export von VM-Images​

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