Virtuelle Maschinen verwalten

Auf dieser Seite wird beschrieben, wie Sie virtuelle Maschinen in Google Distributed Cloud verwalten, auf denen die VM-Laufzeit in Google Distributed Cloud ausgeführt wird. Sie müssen mit der VM Runtime on GDC vertraut sein, bevor Sie die Schritte auf dieser Seite ausführen. Eine Liste der unterstützten Gastbetriebssysteme finden Sie unter Verifizierte Gastbetriebssysteme für VM Runtime auf GDC.

Informationen dazu, wie virtuelle Maschinen als wesentliche Komponente der Distributed Cloud-Plattform dienen, finden Sie unter GKE Enterprise erweitern, um lokale Edge-VMs zu verwalten.

Lokale Steuerungsebenencluster unterstützen VM-Webhooks. So kann Distributed Cloud Nutzeranfragen validieren, die an den lokalen Kubernetes API-Server gesendet werden. Bei abgelehnten Anfragen werden detaillierte Informationen zum Ablehnungsgrund generiert.

VM Runtime on GDC-Unterstützung in Distributed Cloud aktivieren

Standardmäßig ist die Unterstützung virtueller Maschinen für VM Runtime on GDC in Distributed Cloud deaktiviert. Führen Sie die Schritte in diesem Abschnitt aus, um die Funktion zu aktivieren. Bei der Anleitung in diesem Abschnitt wird davon ausgegangen, dass Sie einen voll funktionsfähigen Distributed Cloud-Cluster haben.

Die VMRuntime-Ressource, mit der die Unterstützung von VM Runtime on GDC in Distributed Cloud konfiguriert wird, konfiguriert auch die GPU-Unterstützung in Ihrem Cluster. Dazu wird der Parameter enableGPU verwendet. Konfigurieren Sie die beiden Parameter entsprechend den Anforderungen Ihrer Arbeitslast. Sie müssen die GPU-Unterstützung nicht aktivieren, um die Unterstützung von VM Runtime in GDC in Ihrem Distributed Cloud-Cluster zu aktivieren.

In der folgenden Tabelle werden die verfügbaren Konfigurationen beschrieben:

enable Wert enableGPU Wert Resultierende Konfiguration
false false Arbeitslasten werden nur in Containern ausgeführt und können keine GPU-Ressourcen verwenden.
false true Arbeitslasten werden nur in Containern ausgeführt und können GPU-Ressourcen verwenden.
true true Arbeitslasten können auf virtuellen Maschinen und in Containern ausgeführt werden.
Für beide Arten von Arbeitslasten können GPU-Ressourcen verwendet werden.
true false Arbeitslasten können auf virtuellen Maschinen und in Containern ausgeführt werden.
Für beide Arten von Arbeitslasten können keine GPU-Ressourcen verwendet werden.

Wenn Sie die GPU-Unterstützung bereits aktiviert haben, ändern Sie die VMRuntime-Ressource, um den Parameter enable hinzuzufügen, legen Sie den Wert auf true fest und wenden Sie ihn dann auf Ihren Distributed Cloud-Cluster an.

Aktivieren Sie das VM Runtime on GDC-Subsystem für virtuelle Maschinen.

Führen Sie je nach Art des Clusters, auf dem Sie das VM-Subsystem „VM Runtime on GDC“ aktivieren möchten, einen der folgenden Schritte aus:

  • Bei Clustern mit Cloud-Steuerungsebene müssen Sie die VMRuntime-Ressource manuell erstellen.
  • Bei Clustern mit lokaler Steuerungsebene müssen Sie die vorhandene VMRuntime-Ressource bearbeiten.

Führen Sie die folgenden Schritte aus, um die VM Runtime im GDC-Subsystem für virtuelle Maschinen zu aktivieren:

  1. Erstellen oder ändern Sie je nach Zielclustertyp die benutzerdefinierte VMRuntime-Ressource mit dem folgenden Inhalt und wenden Sie sie auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  # Enable Anthos VM Runtime support
  enabled: true
  # vmImageFormat defaults to "raw" if not set
  vmImageFormat: "raw"

    Ändern Sie den Wert des Parameters vmImageFormat nicht. Distributed Cloud unterstützt keine anderen virtuellen Festplattenformate.

    Dieser Vorgang dauert in der Regel einige Minuten.

  2. Verwenden Sie den folgenden Befehl, um zu prüfen, ob die benutzerdefinierte Ressource VMRuntime auf Ihren Cluster angewendet wurde:

    kubectl get vmruntime -o yaml

    Der Befehl gibt eine Ausgabe ähnlich dem folgenden Beispiel zurück:

     - apiVersion: vm.cluster.gke.io/v1
   kind: VMRuntime
   metadata:
     name: vmruntime
     ...
   spec:
     enabled: true
     vmImageFormat: raw
   status:
     ...
   ready: true
     ...

  3. Mit dem folgenden Befehl können Sie prüfen, ob die Unterstützung von VM Runtime on GDC-VMs in Ihrem Cluster aktiviert wurde:

    kubectl get pods -n vm-system

    Der Befehl gibt eine Ausgabe zurück, die die VM-Laufzeit auf GDC-Subsystem-Pods zeigt, die in Ihrem Cluster ausgeführt werden. Die Ausgabe sieht in etwa so aus:

    NAME                                                READY   STATUS         RESTARTS        AGE
cdi-apiserver-6c76c6cf7b-n68wn                      1/1     Running        0               132m
cdi-deployment-f78fd599-vj7tv                       1/1     Running        0               132m
cdi-operator-65c4df9647-fcb9d                       1/1     Running        0               134m
cdi-uploadproxy-7765ffb694-6j7bf                    1/1     Running        0               132m
macvtap-fjfjr                                       1/1     Running        0               134m
virt-api-77dd99dbbb-bs2fb                           1/1     Running        0               132m
virt-api-77dd99dbbb-pqc27                           1/1     Running        0               132m
virt-controller-5b44dbbbd7-hc222                    1/1     Running        0               132m
virt-controller-5b44dbbbd7-p8xkk                    1/1     Running        0               132m
virt-handler-n76fs                                  1/1     Running        0               132m
virt-operator-86565697d9-fpxqh                      2/2     Running        0               134m
virt-operator-86565697d9-jnbt7                      2/2     Running        0               134m
vm-controller-controller-manager-7844d5fb7b-72d8m   2/2     Running        0               134m
vmruntime-controller-manager-845649c847-m78r9       2/2     Running        0               175m

Zielnamespace Zugriff auf die Distributed Cloud-Registry gewähren

Die Schritte in diesem Abschnitt gelten nur für Cluster mit Cloud-Steuerungsebene. Wenn Sie das VM-Subsystem von VM Runtime on GDC in einem lokalen Steuerungsebenencluster konfigurieren, überspringen Sie diesen Abschnitt.

Bevor Sie eine VM in einem Namespace erstellen können, müssen Sie diesem Namespace Zugriff auf die Distributed Cloud-Registry gewähren. Die Registry enthält Komponenten, die zum Erstellen und Bereitstellen Ihrer VMs im Zielnamespace erforderlich sind. Sie können keine virtuellen Maschinen in Namespaces ausführen, die für die Systemverwaltung von Distributed Cloud reserviert sind. Weitere Informationen finden Sie unter Einschränkungen für Management-Namespaces.

Führen Sie die folgenden Schritte aus, um Ihrem Ziel-Namespace Zugriff auf die Distributed Cloud-Registry zu gewähren:

  1. Patchen Sie das Standarddienstkonto im Ziel-Namespace mit dem Schlüssel imagePullSecret mit dem Namen gcr-pull:

    kubectl patch sa default -p "{\"imagePullSecrets\": [{\"name\": \"gcr-pull\"}]}" -n NAMESPACE

    Ersetzen Sie NAMESPACE durch den Namen des Ziel-Namespace.

  2. Aktualisieren Sie das zugehörige Secret im Ziel-Namespace:

    # Delete existing secret.
kubectl delete secret gcr-pull -n NAMESPACE --ignore-not-found
# Copy the new secret to the target namespace.
kubectl get secret gcr-pull -n vm-system -o yaml | sed "s/namespace: vm-system/namespace: NAMESPACE/g" | kubectl apply -f -

    Ersetzen Sie NAMESPACE durch den Namen des Ziel-Namespace.

    Das Secret läuft nach einer Stunde ab. Sie müssen sie nach Ablauf manuell aktualisieren.

virtctl-Verwaltungstool installieren

Sie benötigen das Clienttool virtctl, um virtuelle Maschinen in Ihrem Distributed Cloud-Cluster zu verwalten. So installieren Sie das Tool:

  1. Installieren Sie das virtctl-CLienttool als kubectl-Plug-in.

    export VERSION=v0.49.0-anthos1.12-gke.7
gcloud storage cp gs://anthos-baremetal-release/virtctl/${VERSION}/linux-amd64/virtctl /usr/local/bin/virtctl
cd /usr/local/bin
sudo ln -s virtctl kubectl-virt
sudo chmod a+x virtctl
cd -

  2. Überprüfen Sie, ob das Plug-in virt installiert ist:

    kubectl plugin list

    Wenn das Plug-in erfolgreich installiert wurde, wird kubectl-virt in der Ausgabe des Befehls als eines der Plug-ins aufgeführt.

Virtuelle Maschine in Distributed Cloud mit rohem Blockspeicher bereitstellen

In diesem Abschnitt finden Sie Konfigurationsbeispiele, die veranschaulichen, wie Sie eine Linux-VM und eine Windows-VM in einem Distributed Cloud-Cluster mit Raw-Block-Storage bereitstellen. In den Beispielen wird Blockspeicher verwendet, der als PersistentVolume instanziiert wird.

Einschränkungen bei der Verwendung von Rohblockspeicher

Beim Ausführen von VMs mit Raw-Blockspeicher in Distributed Cloud gelten die folgenden Einschränkungen:

  • Das Feld OSType wird in VirtualMachine-Ressourcenspezifikationen in Cloud-Steuerungsebenenclustern nicht unterstützt. Aus diesem Grund werden nur die Methoden console und vnc für den Zugriff auf virtuelle Maschinen unterstützt, die in Clustern der Cloud-Steuerungsebene ausgeführt werden.
  • Sie können keine virtuelle Maschine in einem Distributed Cloud-Cluster direkt mit dem Befehl kubectl virt erstellen, da Distributed Cloud keinen Dateisystemspeicher für virtuelle Maschinen bietet.
  • Blockspeicherressourcen PersistenVolumeClaim unterstützen das Festplattenimageformat qcow2 nicht.
  • Das CDI-Plug-in (Containerized Data Importer) unterstützt keine DataVolume-Ressourcen im Blockspeicher, da der Scratch-Space des Plug-ins nur für Dateisystemspeicher funktioniert. Weitere Informationen finden Sie unter Scratch-Speicherplatz.

Linux-VM mit Raw-Blockspeicher in Distributed Cloud bereitstellen

Das folgende Beispiel zeigt, wie Sie eine Linux-VM mit Raw-Blockspeicher bereitstellen, auf der Ubuntu Server 22.04 ausgeführt wird. Die Installationsquelle ist das ISO-Laufwerk-Image von Ubuntu Server 22.04.

  1. Erstellen Sie eine PersistentVolumeClaim-Ressource mit dem folgenden Inhalt für das Installations-Disc-Image von Ubuntu Server und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: containerized-data-importer
  name: iso-ubuntu
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-block
  volumeMode: Block
  resources:
    requests:
      storage: 5Gi

  2. Erstellen Sie eine PersistentVolumeClaim-Ressource mit dem folgenden Inhalt für die virtuelle Festplatte der VM und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ubuntuhd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: local-block
  volumeMode: Block

  3. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für das Installations-Disc-Image von Ubuntu Server und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-iso-disk"
spec:
  persistentVolumeClaimName: iso-ubuntu
  diskType: cdrom

  4. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für die virtuelle Festplatte der VM und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-main-disk"
spec:
  persistentVolumeClaimName: ubuntuhd

  5. Erstellen Sie eine VirtualMachineType-Ressource mit dem folgenden Inhalt, der die Konfiguration der virtuellen Maschine angibt, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  6. Erstellen Sie eine VirtualMachine-Ressource mit dem folgenden Inhalt, die die virtuelle Maschine im Cluster instanziiert und startet, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: ubu-vm
  name: ubu-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Linux
  compute:
    virtualMachineTypeName: small-2-20
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: ubuntu-main-disk
      boot: true
    - virtualMachineDiskName: ubuntu-iso-disk

    Das Feld osType gilt nur für Cluster mit lokaler Steuerungsebene. Sie ist in lokalen Steuerungsebenenclustern erforderlich, um die folgenden Funktionen zu konfigurieren:

  7. Installieren Sie Ubuntu Server auf der VM:

    1. Warten Sie, bis der importer-Pod das Installations-Disc-Image von Ubuntu Server heruntergeladen hat.

    2. Prüfen Sie den Status der virtuellen Maschine:

      kubectl get gvm VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    3. Melden Sie sich auf der virtuellen Maschine an:

      kubectl virt vnc VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    4. Führen Sie die Installationsschritte für Ubuntu Linux aus.

  8. Bereinigen:

    1. Beenden Sie die virtuelle Maschine:

      kubectl virt stop VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    2. Bearbeiten Sie die YAML-Datei der VM, um den Verweis auf das Installations-Disc-Image zu entfernen:

      kubectl edit gvm VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    3. Starten Sie die virtuelle Maschine:

      kubectl virt start VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    4. Löschen Sie die VirtualMachineDisk- und PersistentVolumeClaim-Ressourcen für das Installations-Disc-Image:

      kubectl delete virtualmachinedisk ubuntu-iso-disk
kubectl delete pvc iso-ubuntu

Windows-VM in Distributed Cloud mit Raw-Blockspeicher bereitstellen

Das folgende Beispiel veranschaulicht, wie Sie eine Windows-VM mit Raw-Blockspeicher bereitstellen. Die Schritte ähneln dem Bereitstellen einer virtuellen Linux-Maschine. Zusätzlich ist das virtio-Treiber-Laufwerk-Image erforderlich, um Windows zu installieren.

  1. Besorgen Sie sich eine lizenzierte Kopie von Windows und das Image des Installationsmediums.

  2. Erstellen Sie eine PersistentVolumeClaim-Ressource mit dem folgenden Inhalt für das Installations-Disc-Image von Windows und wenden Sie sie dann auf Ihren Cluster an. Eine Anleitung finden Sie unter Aus Bild.

  3. Erstellen Sie eine PersistentVolumeClaim-Ressource mit folgendem Inhalt für den virtio-Treiber und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: containerized-data-importer
  name: virtio-driver
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso"
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-block
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi

  4. Erstellen Sie eine PersistentVolumeClaim-Ressource mit dem folgenden Inhalt für die virtuelle Festplatte der VM und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: windowshd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: local-block
  volumeMode: Block

  5. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für das Installations-Disc-Image von Windows und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "windows-iso-disk"
spec:
  persistentVolumeClaimName: iso-windows
  diskType: cdrom

  6. Erstellen Sie eine VirtualMachineDisk-Ressource mit folgendem Inhalt für den virtio-Treiber und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "win-virtio-driver"
spec:
  persistentVolumeClaimName: virtio-driver
  diskType: cdrom

  7. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für die virtuelle Festplatte der VM und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "windows-main-disk"
spec:
  persistentVolumeClaimName: windowshd

  8. Erstellen Sie eine VirtualMachineType-Ressource mit dem folgenden Inhalt, der die Konfiguration der virtuellen Maschine angibt, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  9. Erstellen Sie eine VirtualMachine-Ressource mit dem folgenden Inhalt, die die virtuelle Maschine im Cluster instanziiert und startet, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: win-vm
  name: win-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Windows
  compute:
    virtualMachineTypeName: my-vmt
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: windows-main-disk
      boot: true
    - virtualMachineDiskName: windows-iso-disk
    - virtualMachineDiskName: win-virtio-driver

    Das Feld osType gilt nur für Cluster mit lokaler Steuerungsebene. Sie ist in lokalen Steuerungsebenenclustern erforderlich, um die folgenden Funktionen zu konfigurieren:

  10. Windows auf der VM installieren:

    1. Warten Sie, bis der importer-Pod das Windows-Installations-Disc-Image heruntergeladen hat.

    2. Prüfen Sie den Status der virtuellen Maschine:

      kubectl get gvm VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel win-vm.

    3. Schließen Sie die Windows-Installation ab, indem Sie den Schritten unter Verbindung zur Windows-VM herstellen und Betriebssysteminstallation abschließen folgen.

  11. Bereinigen:

    1. Beenden Sie die virtuelle Maschine:

      kubectl virt stop VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel win-vm.

    2. Führen Sie die Schritte unter ISO-Image und Treiber-CD trennen aus.

Virtuelle Maschine in Distributed Cloud mit Symcloud Storage bereitstellen

In diesem Abschnitt finden Sie Konfigurationsbeispiele, die veranschaulichen, wie Sie eine Linux-VM und eine Windows-VM in einem Distributed Cloud-Cluster mit der Symcloud Storage-Abstraktionsschicht bereitstellen.

Bevor Sie die Schritte in diesem Abschnitt ausführen, müssen Sie zuerst die Schritte unter Distributed Cloud für Symcloud Storage konfigurieren ausführen. Wenn Sie Symcloud Storage später im Cluster deaktivieren, schlagen virtuelle Maschinen fehl, die für die Verwendung von Symcloud Storage konfiguriert sind.

Linux-VM in Distributed Cloud mit Symcloud Storage bereitstellen

Im folgenden Beispiel wird gezeigt, wie Sie eine Linux-VM mit Symcloud Storage bereitstellen, auf der Ubuntu Server 22.04 ausgeführt wird. Die Installationsquelle ist das ISO-Laufwerk-Image von Ubuntu Server 22.04.

  1. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für das Installations-Disc-Image von Ubuntu Server und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: ubuntu-iso-disk
spec:
  size: 20Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: https://releases.ubuntu.com/jammy/ubuntu-22.04.3-live-server-amd64.iso

  2. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für die virtuelle Festplatte der VM und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: "ubuntu-main-disk"
spec:
  size: 200Gi
  storageClassName: robin

  3. Erstellen Sie eine VirtualMachineType-Ressource mit dem folgenden Inhalt, der die Konfiguration der virtuellen Maschine angibt, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  4. Erstellen Sie eine VirtualMachine-Ressource mit dem folgenden Inhalt, die die virtuelle Maschine im Cluster instanziiert und startet, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: ubu-vm
  name: ubu-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Linux
  compute:
    virtualMachineTypeName: small-2-20
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: ubuntu-main-disk
      boot: true
    - virtualMachineDiskName: ubuntu-iso-disk

    Das Feld osType gilt nur für Cluster mit lokaler Steuerungsebene. Sie ist in lokalen Steuerungsebenenclustern erforderlich, um die folgenden Funktionen zu konfigurieren:

  5. Installieren Sie Ubuntu Server auf der VM:

    1. Warten Sie, bis der importer-Pod das Installations-Disc-Image von Ubuntu Server heruntergeladen hat.

    2. Prüfen Sie den Status der virtuellen Maschine:

      kubectl get gvm VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    3. Melden Sie sich auf der virtuellen Maschine an:

      kubectl virt vnc VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    4. Führen Sie die Installationsschritte für Ubuntu Linux aus.

  6. Bereinigen:

    1. Beenden Sie die virtuelle Maschine:

      kubectl virt stop VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    2. Bearbeiten Sie die YAML-Datei der VM, um den Verweis auf das Installations-Disc-Image zu entfernen:

      kubectl edit gvm VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    3. Starten Sie die virtuelle Maschine:

      kubectl virt start VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel ubu-vm.

    4. Löschen Sie die VirtualMachineDisk-Ressource für das Installations-Disc-Image:

      kubectl delete virtualmachinedisk ubuntu-iso-disk

Windows-VM in Distributed Cloud mit Symcloud Storage bereitstellen

Das folgende Beispiel veranschaulicht, wie Sie eine Windows-VM mit Symcloud Storage bereitstellen. Die Schritte ähneln dem Bereitstellen einer virtuellen Linux-Maschine. Zusätzlich ist das virtio-Treiber-Laufwerk-Image erforderlich, um Windows zu installieren.

  1. Besorgen Sie sich eine lizenzierte Kopie von Windows und das Image des Installationsmediums.

  2. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für das Installations-Disc-Image von Windows und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-iso-disk
  namespace: default
spec:
  size: 5Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: WINDOWS_ISO_URL

    Ersetzen Sie NAT_GATEWAY durch die vollständige URL zum ISO-Datenträger-Image der Windows-Zielinstallation.

  3. Erstellen Sie eine VirtualMachineDisk-Ressource mit folgendem Inhalt für den virtio-Treiber und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-virtio-driver
  namespace: default
spec:
  size: 1Gi
  storageClassName: robin
  diskType: cdrom
  source:
    http:
      url: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

  4. Erstellen Sie eine VirtualMachineDisk-Ressource mit dem folgenden Inhalt für die virtuelle Festplatte der VM und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineDisk
metadata:
  name: windows-main-disk
  namespace: default
spec:
  size: 15Gi
  storageClassName: robin

  5. Erstellen Sie eine VirtualMachineType-Ressource mit dem folgenden Inhalt, der die Konfiguration der virtuellen Maschine angibt, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachineType
metadata:
  name: small-2-20
spec:
  cpu:
    vcpus: 2
  memory:
    capacity: 20Gi

  6. Erstellen Sie eine VirtualMachine-Ressource mit dem folgenden Inhalt, die die virtuelle Maschine im Cluster instanziiert und startet, und wenden Sie sie dann auf Ihren Cluster an:

    apiVersion: vm.cluster.gke.io/v1
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: win-vm
  name: win-vm #  Propagate the virtual machine name to the VMI
spec:
  osType: Windows
  compute:
    virtualMachineTypeName: my-vmt
  interfaces:
    - name: eth0
      networkName: pod-network
      default: true
  disks:
    - virtualMachineDiskName: windows-main-disk
      boot: true
    - virtualMachineDiskName: windows-iso-disk
    - virtualMachineDiskName: win-virtio-driver

    Das Feld osType gilt nur für Cluster mit lokaler Steuerungsebene. Sie ist in lokalen Steuerungsebenenclustern erforderlich, um die folgenden Funktionen zu konfigurieren:

  7. Windows auf der VM installieren:

    1. Warten Sie, bis der importer-Pod das Windows-Installations-Disc-Image heruntergeladen hat.

    2. Prüfen Sie den Status der virtuellen Maschine:

      kubectl get gvm VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel win-vm.

    3. Schließen Sie die Windows-Installation ab, indem Sie den Schritten unter Verbindung zur Windows-VM herstellen und Betriebssysteminstallation abschließen folgen.

  8. Bereinigen:

    1. Beenden Sie die virtuelle Maschine:

      kubectl virt stop VM_NAME

      Ersetzen Sie VM_NAME durch den Namen der virtuellen Maschine, in diesem Beispiel win-vm.

    2. Führen Sie die Schritte unter ISO-Image und Treiber-CD trennen aus.

Eine virtuelle Maschine in Distributed Cloud mit virtctl bereitstellen

Wenn Sie die Anpassung, die durch das Schreiben eigener Ressourcenspezifikationen für Ihre virtuellen Maschinen bereitgestellt wird, nicht benötigen, können Sie eine virtuelle Maschine in Distributed Cloud mit dem virtctl-Befehlszeilentool wie unter VM erstellen beschrieben bereitstellen.

Auf Distributed Cloud ausgeführte virtuelle Maschinen verwalten

Eine Anleitung zum Verwalten von virtuellen Maschinen, die in Distributed Cloud ausgeführt werden, finden Sie in der folgenden Dokumentation zu VM Runtime on GDC:

Wenn Sie virtuelle Maschinen verwalten möchten, die in Clustern mit lokaler Steuerungsebene ausgeführt werden, müssen Sie zuerst die kubectl-Verbindung konfigurieren.

ttyS0-Gerät für den Zugriff auf die serielle Konsole virtueller Linux-Maschinen konfigurieren

Wenn Sie über die serielle Konsole (kubectl virt console) auf Ihre virtuellen Linux-Maschinen zugreifen möchten, muss das serielle Konsolengerät ttyS0 im Gastbetriebssystem konfiguriert sein. Führen Sie die folgenden Schritte aus, um dieses Gerät zu konfigurieren:

  1. Instanziieren Sie das serielle Gerät ttyS0 im System:

    setserial -g /dev/ttyS0

  2. Konfigurieren Sie den grub-Bootloader für die Verwendung des seriellen Geräts ttyS0, indem Sie die folgenden Zeilen in Ihre /etc/default/grub-Konfigurationsdatei einfügen. Die erste Zeile ersetzt Ihre vorhandene GRUB_CMDLINE_LINUX-Variable.

    GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8'
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --speed=19200 --unit=0 --word=8 --parity=no --stop=1"

  3. Wenden Sie die neue grub-Konfiguration auf Ihren Bootsektor an:

    update-grub

  4. Starten Sie die virtuelle Maschine neu.

VM Runtime on GDC in Distributed Cloud deaktivieren

Führen Sie die Schritte in diesem Abschnitt aus, um VM Runtime on GDC in Distributed Cloud zu deaktivieren. Bevor Sie die VM-Laufzeit auf GDC in Distributed Cloud deaktivieren können, müssen Sie alle virtuellen Maschinen in Ihrem Distributed Cloud-Cluster beenden und löschen, wie unter VM löschen beschrieben.

Wenn Sie die VM-Laufzeit auf GDC in Distributed Cloud deaktivieren möchten, ändern Sie die benutzerdefinierte Ressource VMRuntime, indem Sie den Spezifikationsparameter enabled wie folgt auf false festlegen, und wenden Sie sie dann auf Ihren Cluster an:

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  # Disable Anthos VM Runtime
  enabled: false
  # vmImageFormat defaults to "raw" if not set
  vmImageFormat: "raw"

Nächste Schritte