Virtuelle Maschinen verwalten

Auf dieser Seite wird beschrieben, wie Sie virtuelle Maschinen in Google Distributed Cloud Connected verwalten, auf denen VM Runtime on 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 verbundenen Plattform von Distributed Cloud dienen, finden Sie unter GKE Enterprise erweitern, um lokale Edge-VMs zu verwalten.

Lokale Steuerungsebenencluster unterstützen VM-Webhooks. So kann Distributed Cloud Connected 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 Connect aktivieren

Standardmäßig ist die Unterstützung für virtuelle Maschinen in VM Runtime on GDC für Distributed Cloud Connected 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 Connect-Cluster haben.

Die VMRuntime-Ressource, mit der die Unterstützung von VM Runtime on GDC auf Distributed Cloud Connected konfiguriert wird, konfiguriert auch die GPU-Unterstützung in Ihrem Cluster mit dem Parameter enableGPU. 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 mit Distributed Cloud verbundenen 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 Connected 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

Ziel-Namespace Zugriff auf die Distributed Cloud Connected-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 verbundene 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 Verwaltung von mit Distributed Cloud verbundenen Systemen 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 mit Distributed Cloud verbundene 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 mit Distributed Cloud verbundenen 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.

VM in Distributed Cloud Connect mit Raw-Blockspeicher bereitstellen

In diesem Abschnitt finden Sie Konfigurationsbeispiele, die veranschaulichen, wie Sie eine Linux-VM und eine Windows-VM in einem mit Distributed Cloud verbundenen 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 Connected 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 mit Distributed Cloud verbundenen Cluster direkt mit dem Befehl kubectl virt erstellen, da Distributed Cloud Connected keinen Dateisystemspeicher für virtuelle Maschinen bietet.
  • Blockspeicherressourcen PersistentVolumeClaim 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 auf Distributed Cloud Connect mit Raw-Blockspeicher 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 Connect 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.

VM in Distributed Cloud Connected mit Symcloud Storage bereitstellen

In diesem Abschnitt finden Sie Konfigurationsbeispiele, die veranschaulichen, wie Sie eine Linux-VM und eine Windows-VM in einem mit Distributed Cloud verbundenen 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 Connected 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.

Eine virtuelle Linux-Maschine in Distributed Cloud Connected 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 Connected 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 Connected 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.

Virtuelle Maschinen verwalten, die in Distributed Cloud Connected ausgeführt werden

Eine Anleitung zum Verwalten von virtuellen Maschinen, die auf Distributed Cloud Connected 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 Connect deaktivieren

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

Um VM Runtime on GDC on Distributed Cloud Connected zu deaktivieren, ä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