Gestisci le macchine virtuali

Questa pagina descrive come gestire le macchine virtuali su Google Distributed Cloud che esegue VM Runtime su Google Distributed Cloud. Prima di completare i passaggi di questa pagina, devi avere familiarità con VM Runtime su GDC. Per un elenco dei sistemi operativi guest supportati, vedi Sistemi operativi guest verificati per VM Runtime su GDC.

Per scoprire in che modo le macchine virtuali fungono da componente essenziale della piattaforma Distributed Cloud, consulta Estensione di GKE Enterprise per gestire le VM edge on-premise.

I cluster del control plane locale supportano i webhook delle macchine virtuali. Ciò consente a Distributed Cloud di convalidare le richieste degli utenti effettuate al server API Kubernetes locale. Le richieste rifiutate generano informazioni dettagliate sul motivo del rifiuto.

Abilita il supporto del runtime VM su GDC su Distributed Cloud

Per impostazione predefinita, il supporto delle macchine virtuali del runtime VM su GDC è disabilitato su Distributed Cloud. Per attivarla, completa i passaggi descritti in questa sezione. Le istruzioni in questa sezione presuppongono che tu disponga di un cluster Distributed Cloud completamente funzionante.

La risorsa VMRuntime che configura il supporto di VM Runtime su GDC su Distributed Cloud configura anche il supporto GPU sul cluster utilizzando il parametro enableGPU. Assicurati di configurare i due parametri in base alle esigenze del tuo workload. Non devi abilitare il supporto GPU per abilitare VM Runtime su GDC support sul tuo cluster Distributed Cloud.

La seguente tabella descrive le configurazioni disponibili:

Valore enable Valore enableGPU Configurazione risultante
false false I carichi di lavoro vengono eseguiti solo nei container e non possono utilizzare le risorse GPU.
false true I carichi di lavoro vengono eseguiti solo nei container e possono utilizzare le risorse GPU.
true true I carichi di lavoro possono essere eseguiti su macchine virtuali e in container.
Entrambi i tipi di workload possono utilizzare le risorse GPU.
true false I carichi di lavoro possono essere eseguiti su macchine virtuali e in container.
Nessuno dei due tipi di workload può utilizzare le risorse GPU.

Se hai già attivato il supporto GPU, modifica la risorsa VMRuntime per aggiungere il parametro enable, imposta il relativo valore su true e poi applicalo al cluster Distributed Cloud.

Attiva il runtime delle VM sul sottosistema delle macchine virtuali GDC

A seconda del tipo di cluster su cui vuoi abilitare VM Runtime sul sottosistema di macchine virtuali GDC, esegui una delle seguenti operazioni:

  • Per i cluster del control plane Cloud, devi creare manualmente la risorsa VMRuntime.
  • Per i cluster del piano di controllo locale, devi modificare la risorsa VMRuntime esistente.

Per attivare VM Runtime nel sottosistema di macchine virtuali GDC, completa i seguenti passaggi:

  1. A seconda del tipo di cluster di destinazione, crea o modifica la risorsa personalizzata VMRuntime con i seguenti contenuti e applicala al cluster:

    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"

    Non modificare il valore del parametro vmImageFormat. Distributed Cloud non supporta altri formati di dischi virtuali.

    In genere, il completamento di questa procedura richiede diversi minuti.

  2. Utilizza questo comando per verificare che la risorsa personalizzata VMRuntime sia stata applicata al cluster:

    kubectl get vmruntime -o yaml

    Il comando restituisce un output simile al seguente esempio:

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

  3. Utilizza il seguente comando per verificare che il supporto della macchina virtuale di VM Runtime su GDC sia stato abilitato sul cluster:

    kubectl get pods -n vm-system

    Il comando restituisce un output che mostra i pod del sottosistema VM Runtime su GDC in esecuzione sul cluster, simile al seguente esempio:

    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

Concedi all'accesso allo spazio dei nomi di destinazione al registro Distributed Cloud

I passaggi descritti in questa sezione si applicano solo ai cluster del control plane Cloud. Se stai configurando il runtime VM sul sottosistema di macchine virtuali GDC su un cluster del control plane locale, salta questa sezione.

Prima di poter creare una macchina virtuale in uno spazio dei nomi, devi concedere a questo spazio dei nomi l'accesso al registro Distributed Cloud. Il registro contiene i componenti necessari per creare e distribuire le macchine virtuali nel namespace di destinazione. Tieni presente che non puoi eseguire macchine virtuali in spazi dei nomi riservati alla gestione del sistema Distributed Cloud. Per saperne di più, consulta Limitazioni dello spazio dei nomi di gestione.

Completa i seguenti passaggi per concedere al tuo spazio dei nomi di destinazione l'accesso al registro Distributed Cloud:

  1. Applica una patch al account di servizio predefinito nello spazio dei nomi di destinazione con la chiave imagePullSecret denominata gcr-pull:

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

    Sostituisci NAMESPACE con il nome dello spazio dei nomi di destinazione.

  2. Aggiorna il secret associato nello spazio dei nomi di destinazione:

    # 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 -

    Sostituisci NAMESPACE con il nome dello spazio dei nomi di destinazione.

    Il segreto scade dopo un'ora. Devi aggiornarlo manualmente dopo la scadenza.

Installa lo strumento di gestione virtctl

Per gestire le macchine virtuali nel tuo cluster Distributed Cloud, devi utilizzare lo strumento client virtctl. Per installare lo strumento, completa i seguenti passaggi:

  1. Installa lo strumento client virtctl come plug-in kubectl:

    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. Verifica che il plug-in virt sia installato:

    kubectl plugin list

    Se il plug-in è stato installato correttamente, l'output del comando elenca kubectl-virt tra i plug-in.

Esegui il provisioning di una macchina virtuale su Distributed Cloud con l'archiviazione a blocchi non elaborata

Questa sezione fornisce esempi di configurazione che illustrano come eseguire il provisioning di una macchina virtuale Linux e di una macchina virtuale Windows su un cluster Distributed Cloud con spazio di archiviazione a blocchi non elaborato. Gli esempi utilizzano lo spazio di archiviazione a blocchi istanziato come PersistentVolume.

Limitazioni dell'utilizzo dell'archiviazione a blocchi non elaborata

Quando esegui macchine virtuali con archiviazione a blocchi non elaborata su Distributed Cloud, si applicano le seguenti limitazioni:

  • Il campo OSType non è supportato nelle specifiche delle risorse VirtualMachine nei cluster del control plane Cloud. Per questo motivo, per accedere alle macchine virtuali in esecuzione sui cluster del control plane Cloud sono supportati solo i metodi console e vnc.
  • Non puoi creare una macchina virtuale su un cluster Distributed Cloud direttamente utilizzando il comando kubectl virt perché Distributed Cloud non fornisce spazio di archiviazione del file system alle macchine virtuali.
  • Le risorse di archiviazione a blocchi PersistenVolumeClaim non supportano il formato dell'immagine disco qcow2.
  • Il plug-in Containerized Data Importer (CDI) non supporta le risorse DataVolume sull'archiviazione a blocchi perché lo spazio di lavoro del plug-in funziona solo sull'archiviazione del file system. Per ulteriori informazioni, consulta Spazio di lavoro.

Esegui il provisioning di una macchina virtuale Linux su Distributed Cloud con l'archiviazione a blocchi non elaborata

L'esempio seguente illustra come eseguire il provisioning di una macchina virtuale Linux con spazio di archiviazione a blocchi non elaborato che esegue Ubuntu Server 22.04. L'origine dell'installazione è l'immagine disco ISO di Ubuntu Server 22.04.

  1. Crea una risorsa PersistentVolumeClaim con i seguenti contenuti per l'immagine del disco di installazione di Ubuntu Server, quindi applicala al cluster:

    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. Crea una risorsa PersistentVolumeClaim con i seguenti contenuti per il disco rigido virtuale della macchina virtuale, quindi applicala al cluster:

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

  3. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'immagine del disco di installazione di Ubuntu Server, quindi applicala al cluster:

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

  4. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'hard disk virtuale della macchina virtuale, quindi applicala al cluster:

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

  5. Crea una risorsa VirtualMachineType con i seguenti contenuti che specificano la configurazione della macchina virtuale, quindi applicala al tuo cluster:

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

  6. Crea una risorsa VirtualMachine con i seguenti contenuti che crea un'istanza e avvia la macchina virtuale sul cluster, quindi applicala al cluster:

    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

    Il campo osType si applica solo ai cluster del control plane locale. È obbligatorio sui cluster del control plane locale per configurare le seguenti funzionalità:

  7. Installa Ubuntu Server sulla macchina virtuale:

    1. Attendi che il pod importer scarichi l'immagine disco di installazione di Ubuntu Server.

    2. Controlla lo stato della macchina virtuale:

      kubectl get gvm VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    3. Accedi alla macchina virtuale:

      kubectl virt vnc VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    4. Completa i passaggi di installazione di Ubuntu Linux.

  8. Pulizia:

    1. Arresta la macchina virtuale:

      kubectl virt stop VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    2. Modifica il file YAML della macchina virtuale per rimuovere il riferimento all'immagine disco di installazione:

      kubectl edit gvm VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    3. Avvia la macchina virtuale:

      kubectl virt start VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    4. Elimina le risorse VirtualMachineDisk e PersistentVolumeClaim per l'immagine disco di installazione:

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

Esegui il provisioning di una macchina virtuale Windows su Distributed Cloud con archiviazione a blocchi non elaborata

L'esempio seguente mostra come eseguire il provisioning di una macchina virtuale Windows con spazio di archiviazione a blocchi non elaborato. I passaggi sono simili al provisioning di una macchina virtuale Linux, con l'aggiunta dell'immagine disco del driver virtio, necessaria per l'installazione di Windows.

  1. Ottieni una copia con licenza di Windows e la relativa immagine del supporto di installazione.

  2. Crea una risorsa PersistentVolumeClaim con i seguenti contenuti per l'immagine del disco di installazione di Windows, quindi applicala al cluster. Per istruzioni, vedi Da immagine.

  3. Crea una risorsa PersistentVolumeClaim con i seguenti contenuti per il driver virtio, quindi applicala al cluster:

    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. Crea una risorsa PersistentVolumeClaim con i seguenti contenuti per l'hard disk virtuale della macchina virtuale, quindi applicala al cluster:

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

  5. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'immagine del disco di installazione di Windows, quindi applicala al cluster:

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

  6. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per il driver virtio, quindi applicala al cluster:

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

  7. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'hard disk virtuale della macchina virtuale, quindi applicala al cluster:

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

  8. Crea una risorsa VirtualMachineType con i seguenti contenuti che specificano la configurazione della macchina virtuale, quindi applicala al tuo cluster:

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

  9. Crea una risorsa VirtualMachine con i seguenti contenuti che crea un'istanza e avvia la macchina virtuale sul cluster, quindi applicala al cluster:

    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

    Il campo osType si applica solo ai cluster del control plane locale. È obbligatorio sui cluster del control plane locale per configurare le seguenti funzionalità:

  10. Installa Windows sulla macchina virtuale:

    1. Attendi che il pod importer scarichi l'immagine disco di installazione di Windows.

    2. Controlla lo stato della macchina virtuale:

      kubectl get gvm VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, win-vm in questo esempio.

    3. Completa l'installazione di Windows seguendo i passaggi descritti in Connettiti alla VM Windows e completa l'installazione del sistema operativo.

  11. Pulizia:

    1. Arresta la macchina virtuale:

      kubectl virt stop VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, win-vm in questo esempio.

    2. Completa i passaggi descritti in Scollega l'immagine ISO e il disco dei driver.

Esegui il provisioning di una macchina virtuale su Distributed Cloud con Symcloud Storage

Questa sezione fornisce esempi di configurazione che illustrano come eseguire il provisioning di una macchina virtuale Linux e di una macchina virtuale Windows su un cluster Distributed Cloud con il livello di astrazione di Symcloud Storage.

Prima di completare i passaggi di questa sezione, devi completare i passaggi descritti in Configurare Distributed Cloud per Symcloud Storage. Se in un secondo momento disattivi Symcloud Storage sul cluster, le macchine virtuali configurate per utilizzare Symcloud Storage non funzioneranno.

Esegui il provisioning di una macchina virtuale Linux su Distributed Cloud con Symcloud Storage

L'esempio seguente illustra come eseguire il provisioning di una macchina virtuale Linux con Symcloud Storage che esegue Ubuntu Server 22.04. L'origine dell'installazione è l'immagine disco ISO di Ubuntu Server 22.04.

  1. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'immagine del disco di installazione di Ubuntu Server, quindi applicala al cluster:

    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. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'hard disk virtuale della macchina virtuale, quindi applicala al cluster:

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

  3. Crea una risorsa VirtualMachineType con i seguenti contenuti che specificano la configurazione della macchina virtuale, quindi applicala al tuo cluster:

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

  4. Crea una risorsa VirtualMachine con i seguenti contenuti che crea un'istanza e avvia la macchina virtuale sul cluster, quindi applicala al cluster:

    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

    Il campo osType si applica solo ai cluster del control plane locale. È obbligatorio sui cluster del control plane locale per configurare le seguenti funzionalità:

  5. Installa Ubuntu Server sulla macchina virtuale:

    1. Attendi che il pod importer scarichi l'immagine disco di installazione di Ubuntu Server.

    2. Controlla lo stato della macchina virtuale:

      kubectl get gvm VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    3. Accedi alla macchina virtuale:

      kubectl virt vnc VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    4. Completa i passaggi di installazione di Ubuntu Linux.

  6. Pulizia:

    1. Arresta la macchina virtuale:

      kubectl virt stop VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    2. Modifica il file YAML della macchina virtuale per rimuovere il riferimento all'immagine disco di installazione:

      kubectl edit gvm VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    3. Avvia la macchina virtuale:

      kubectl virt start VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, ubu-vm in questo esempio.

    4. Elimina la risorsa VirtualMachineDisk per l'immagine del disco di installazione:

      kubectl delete virtualmachinedisk ubuntu-iso-disk

Esegui il provisioning di una macchina virtuale Windows su Distributed Cloud con Symcloud Storage

L'esempio seguente illustra come eseguire il provisioning di una macchina virtuale Windows con Symcloud Storage. I passaggi sono simili al provisioning di una macchina virtuale Linux, con l'aggiunta dell'immagine disco del driver virtio, necessaria per l'installazione di Windows.

  1. Ottieni una copia con licenza di Windows e la relativa immagine del supporto di installazione.

  2. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'immagine del disco di installazione di Windows, quindi applicala al cluster:

    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

    Sostituisci NAT_GATEWAY con l'URL completo dell'immagine disco ISO dell'installazione di Windows di destinazione.

  3. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per il driver virtio, quindi applicala al cluster:

    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. Crea una risorsa VirtualMachineDisk con i seguenti contenuti per l'hard disk virtuale della macchina virtuale, quindi applicala al cluster:

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

  5. Crea una risorsa VirtualMachineType con i seguenti contenuti che specificano la configurazione della macchina virtuale, quindi applicala al tuo cluster:

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

  6. Crea una risorsa VirtualMachine con i seguenti contenuti che crea un'istanza e avvia la macchina virtuale sul cluster, quindi applicala al cluster:

    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

    Il campo osType si applica solo ai cluster del control plane locale. È obbligatorio sui cluster del control plane locale per configurare le seguenti funzionalità:

  7. Installa Windows sulla macchina virtuale:

    1. Attendi che il pod importer scarichi l'immagine disco di installazione di Windows.

    2. Controlla lo stato della macchina virtuale:

      kubectl get gvm VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, win-vm in questo esempio.

    3. Completa l'installazione di Windows seguendo i passaggi descritti in Connettiti alla VM Windows e completa l'installazione del sistema operativo.

  8. Pulizia:

    1. Arresta la macchina virtuale:

      kubectl virt stop VM_NAME

      Sostituisci VM_NAME con il nome della macchina virtuale, win-vm in questo esempio.

    2. Completa i passaggi descritti in Scollega l'immagine ISO e il disco dei driver.

Esegui il provisioning di una macchina virtuale su Distributed Cloud utilizzando virtctl

Se non hai bisogno della personalizzazione fornita dalla scrittura delle tue specifiche di risorse per le tue macchine virtuali, puoi eseguire il provisioning di una macchina virtuale su Distributed Cloud utilizzando lo strumento a riga di comando virtctl, come descritto in Creare una VM.

Gestire le macchine virtuali in esecuzione su Distributed Cloud

Per istruzioni sulla gestione delle macchine virtuali in esecuzione su Distributed Cloud, consulta la seguente documentazione sul runtime VM su GDC:

Per gestire le macchine virtuali in esecuzione sui cluster del control plane locale, devi prima configurare la connettività kubectl.

Configurare il dispositivo ttyS0 per l'accesso alla console seriale alle macchine virtuali Linux

Se prevedi di accedere alle tue macchine virtuali Linux utilizzando la console seriale (kubectl virt console), assicurati che il dispositivo della console seriale ttyS0 sia stato configurato sul sistema operativo guest. Per configurare questo dispositivo, completa i seguenti passaggi:

  1. Crea un'istanza del dispositivo seriale ttyS0 nel sistema:

    setserial -g /dev/ttyS0

  2. Configura il bootloader grub per utilizzare il dispositivo seriale ttyS0 aggiungendo le seguenti righe al file di configurazione /etc/default/grub. La prima riga sostituisce la variabile GRUB_CMDLINE_LINUX esistente.

    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. Applica la nuova configurazione grub al settore di avvio:

    update-grub

  4. Riavvia la macchina virtuale.

Disabilita il runtime VM su GDC su Distributed Cloud

Segui i passaggi descritti in questa sezione per disabilitare VM Runtime su GDC su Distributed Cloud. Prima di poter disattivare il runtime VM su GDC su Distributed Cloud, devi arrestare ed eliminare tutte le macchine virtuali sul tuo cluster Distributed Cloud come descritto in Eliminare una VM.

Per disabilitare VM Runtime su GDC su Distributed Cloud, modifica la risorsa personalizzata VMRuntime impostando il parametro spec enabled su false come segue, quindi applicalo al cluster:

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"

Passaggi successivi