Zum Hauptinhalt springen
Version: Weekly Build

Virtuelle Maschinen

Virtuelle Maschinen ermöglichen das Deployment einer vollständigen Linux- oder Windows-VM neben den containerisierten Workloads in einem Codesphere Workspace. Im Gegensatz zu einem reactive Container bietet eine VM vollständigen Betriebssystem- und Administratorzugriff, mit konfigurierbarer CPU, Speicher und Storage sowie interner Netzwerkanbindung an die restliche Landschaft.

Virtuelle Maschinen sind durch das virtual-machines Flag gesperrt. Das Feature muss für die Installation aktiviert sein, bevor VMs im Landscape Config Editor erscheinen.

Codesphere betreibt VMs mit KubeVirt auf Basis von Kubernetes.

Lebenszyklus​

Die Lebensdauer einer VM ist an ihre Landschaft gebunden. Die VM wird beim Deployment der Landschaft erstellt und beim Abbau der Landschaft gelöscht, zusammen mit allen innerhalb des Gastsystems vorgenommenen Änderungen. Ein erneutes Deployment der Landschaft startet eine neue VM aus dem konfigurierten Image. Der Zustand der vorherigen VM bleibt nicht erhalten.

Images​

Codesphere VM unterstützt 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, setze das Image-Feld auf eine s3://-URL für das Objekt. S3-Quellen benötigen eine konfigurierte Resource Group Container Registry für die URL, dieselben Zugangsdaten, die 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 jedoch nicht den VirtIO-Netzwerktreiber.
  • Der Disk-Bus ist SATA (nicht VirtIO), sodass kein VirtIO-Storage-Treiber erforderlich ist. Der Netzwerktreiber wird dennoch benötigt.

Startet 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. Klicke auf die Schaltfläche + Add New Service auf der rechten Seite des Bereichs Landscape Deployment und wähle Virtual Machine als Service-Typ.

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

  2. Konfiguriere die VM. Lege den VM-Namen, das Disk-Image und die Compute-Ressourcen fest.

    Konfigurationsformular für Virtuelle Maschinen mit Image- und Ressourcenfeldern

  3. Speichere und synchronisiere die Landschaft. Nach dem Deployment erscheint die VM zusammen mit den anderen deployten Services.

    Execution-Ansicht mit der deployten Virtuellen Maschine

Demo-Image​

Das Feature kann mit dem folgenden fertigen Demo-containerdisk ausprobiert werden. 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 Speicher, 5 GiB Storage
  • Ubuntu Login Username: codesphere
  • Ubuntu Login Password: codesphere

Windows Server 2022 (Desktop Experience, Evaluation)​

  • Image: docker://ghcr.io/codesphere-cloud/vm-demo/windows-server:2022
  • Mindestressourcen: 2 CPU, 4 GiB Speicher, 15 GiB Storage
  • Windows Login Username: codesphere
  • Windows Login Password: SphereCode!

VM-Zugriff​

Über die Schaltfläche VNC an der deployten Virtuellen Maschine lässt sich direkt aus der Benutzeroberfläche ein interaktives Fenster zu einer laufenden VM öffnen. Dies ermöglicht eine grafische Sitzung im Gastsystem. Es ist nützlich für die Ersteinrichtung, die Fehlerbehebung oder für 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 Services 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 nutzt 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, füge dem Workspace Router ein custom target hinzu, das einen öffentlichen Pfad an den internen Hostnamen der VM weiterleitet.

Konsolenzugriff​

Eine textbasierte serielle Konsole zur VM ist für eine zukünftige Version geplant. Verwende vorerst die grafische VNC-Konsole, die unter VM-Zugriff beschrieben ist.

Exportieren 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.