Gérer les machines virtuelles

Cette page explique comment gérer les machines virtuelles sur Google Distributed Cloud exécutant VM Runtime sur Google Distributed Cloud. Avant de suivre les étapes de cette page, vous devez connaître VM Runtime sur GDC. Pour obtenir la liste des systèmes d'exploitation invités compatibles, consultez Systèmes d'exploitation invités validés pour l'environnement d'exécution de VM sur GDC.

Pour découvrir comment les machines virtuelles constituent un composant essentiel de la plate-forme Distributed Cloud, consultez Étendre GKE Enterprise pour gérer les VM périphériques sur site.

Les clusters de plan de contrôle local sont compatibles avec les Webhooks de machine virtuelle. Cela permet à Distributed Cloud de valider les requêtes utilisateur envoyées au serveur d'API Kubernetes local. Les demandes refusées génèrent des informations détaillées sur le motif du refus.

Activer la compatibilité de l'environnement d'exécution des VM sur GDC sur Distributed Cloud

Par défaut, la compatibilité avec les machines virtuelles de l'environnement d'exécution de VM sur GDC est désactivée sur Distributed Cloud. Pour l'activer, suivez les étapes décrites dans cette section. Les instructions de cette section supposent que vous disposez d'un cluster Distributed Cloud entièrement fonctionnel.

La ressource VMRuntime qui configure la compatibilité de l'environnement d'exécution de VM sur GDC sur Distributed Cloud configure également la compatibilité GPU sur votre cluster à l'aide du paramètre enableGPU. Assurez-vous de configurer les deux paramètres en fonction des besoins de votre charge de travail. Vous n'avez pas besoin d'activer la compatibilité avec les GPU pour activer la compatibilité avec l'environnement d'exécution de VM sur GDC sur votre cluster Distributed Cloud.

Le tableau suivant décrit les configurations disponibles :

Valeur enable Valeur enableGPU Configuration obtenue
false false Les charges de travail ne s'exécutent que dans des conteneurs et ne peuvent pas utiliser de ressources GPU.
false true Les charges de travail ne s'exécutent que dans des conteneurs et peuvent utiliser des ressources de GPU.
true true Les charges de travail peuvent s'exécuter sur des machines virtuelles et dans des conteneurs.
Les deux types de charges de travail peuvent utiliser des ressources GPU.
true false Les charges de travail peuvent s'exécuter sur des machines virtuelles et dans des conteneurs.
Aucun type de charge de travail ne peut utiliser de ressources de GPU.

Si vous avez déjà activé la compatibilité avec les GPU, modifiez la ressource VMRuntime pour ajouter le paramètre enable, définissez sa valeur sur true, puis appliquez-la à votre cluster Distributed Cloud.

Activer le sous-système de machine virtuelle de l'environnement d'exécution de VM sur GDC

Selon le type de cluster sur lequel vous souhaitez activer le sous-système de machine virtuelle VM Runtime sur GDC, procédez de l'une des manières suivantes :

  • Pour les clusters de plan de contrôle Cloud, vous devez créer manuellement la ressource VMRuntime.
  • Pour les clusters de plan de contrôle local, vous devez modifier la ressource VMRuntime existante.

Pour activer le sous-système de machine virtuelle VM Runtime sur GDC, procédez comme suit :

  1. Selon le type de cluster cible, créez ou modifiez la ressource personnalisée VMRuntime avec le contenu suivant et appliquez-la à votre 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"

    Ne modifiez pas la valeur du paramètre vmImageFormat. Distributed Cloud n'est compatible avec aucun autre format de disque virtuel.

    Cette opération prend généralement plusieurs minutes.

  2. Exécutez la commande suivante pour vérifier que la ressource personnalisée VMRuntime a été appliquée à votre cluster :

    kubectl get vmruntime -o yaml

    La commande renvoie un résultat semblable à l'exemple suivant :

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

  3. Exécutez la commande suivante pour vérifier que la compatibilité avec les machines virtuelles VM Runtime sur GDC a été activée sur votre cluster :

    kubectl get pods -n vm-system

    La commande renvoie un résultat indiquant les pods du sous-système VM Runtime sur GDC en cours d'exécution sur votre cluster, semblable à l'exemple suivant :

    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

Accorder l'accès à l'espace de noms cible au registre Distributed Cloud

Les étapes de cette section ne s'appliquent qu'aux clusters de plan de contrôle Cloud. Si vous configurez le sous-système de machine virtuelle de l'environnement d'exécution de VM sur GDC sur un cluster de plan de contrôle local, ignorez cette section.

Avant de pouvoir créer une machine virtuelle dans un espace de noms, vous devez accorder à cet espace de noms l'accès au registre Distributed Cloud. Le registre contient les composants nécessaires pour créer et déployer vos machines virtuelles dans l'espace de noms cible. N'oubliez pas que vous ne pouvez pas exécuter de machines virtuelles dans les espaces de noms réservés à la gestion du système Distributed Cloud. Pour en savoir plus, consultez Restrictions concernant l'espace de noms de gestion.

Pour accorder à votre espace de noms cible l'accès au registre Distributed Cloud, procédez comme suit :

  1. Corrigez le compte de service par défaut dans l'espace de noms cible avec la clé imagePullSecret nommée gcr-pull :

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

    Remplacez NAMESPACE par le nom de l'espace de noms cible.

  2. Actualisez le secret associé dans l'espace de noms cible :

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

    Remplacez NAMESPACE par le nom de l'espace de noms cible.

    Le secret expire au bout d'une heure. Vous devez l'actualiser manuellement après son expiration.

Installer l'outil de gestion virtctl

Vous avez besoin de l'outil client virtctl pour gérer les machines virtuelles sur votre cluster Distributed Cloud. Pour installer l'outil, procédez comme suit :

  1. Installer l'outil de client virtctl en tant que 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. Vérifiez que le plug-in virt est installé :

    kubectl plugin list

    Si le plug-in a été installé, le résultat de la commande liste kubectl-virt comme l'un des plug-ins.

Provisionner une machine virtuelle sur Distributed Cloud avec un stockage de blocs bruts

Cette section fournit des exemples de configuration qui illustrent comment provisionner une machine virtuelle Linux et une machine virtuelle Windows sur un cluster Distributed Cloud avec un stockage de blocs bruts. Les exemples utilisent le stockage par blocs instancié en tant que PersistentVolume.

Limites de l'utilisation du stockage de blocs bruts

Les limites suivantes s'appliquent lorsque vous exécutez des machines virtuelles avec un stockage de blocs bruts sur Distributed Cloud :

  • Le champ OSType n'est pas compatible avec les spécifications de ressources VirtualMachine sur les clusters du plan de contrôle Cloud. Par conséquent, seuls les méthodes console et vnc sont compatibles pour accéder aux machines virtuelles exécutées sur les clusters du plan de contrôle Cloud.
  • Vous ne pouvez pas créer de machine virtuelle sur un cluster Distributed Cloud directement à l'aide de la commande kubectl virt, car Distributed Cloud ne fournit pas de stockage de système de fichiers aux machines virtuelles.
  • Les ressources PersistenVolumeClaim de stockage par blocs ne sont pas compatibles avec le format d'image de disque qcow2.
  • Le plug-in CDI (Containerized Data Importer) n'est pas compatible avec les ressources DataVolume sur le stockage par blocs, car l'espace de travail temporaire du plug-in ne fonctionne que sur le stockage du système de fichiers. Pour en savoir plus, consultez Espace de travail temporaire.

Provisionner une machine virtuelle Linux sur Distributed Cloud avec un stockage de blocs bruts

L'exemple suivant montre comment provisionner une machine virtuelle Linux avec un stockage de blocs bruts exécutant Ubuntu Server 22.04. La source d'installation est l'image disque ISO Ubuntu Server 22.04.

  1. Créez une ressource PersistentVolumeClaim avec le contenu suivant pour l'image de disque d'installation Ubuntu Server, puis appliquez-la à votre 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. Créez une ressource PersistentVolumeClaim avec le contenu suivant pour le disque dur virtuel de la machine virtuelle, puis appliquez-la à votre cluster :

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

  3. Créez une ressource VirtualMachineDisk avec le contenu suivant pour l'image de disque d'installation Ubuntu Server, puis appliquez-la à votre cluster :

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

  4. Créez une ressource VirtualMachineDisk avec le contenu suivant pour le disque dur virtuel de la machine virtuelle, puis appliquez-la à votre cluster :

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

  5. Créez une ressource VirtualMachineType avec le contenu suivant qui spécifie la configuration de la machine virtuelle, puis appliquez-la à votre cluster :

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

  6. Créez une ressource VirtualMachine avec le contenu suivant, qui instancie et démarre la machine virtuelle sur le cluster, puis appliquez-la à votre 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

    Le champ osType ne s'applique qu'aux clusters de plan de contrôle local. Il est obligatoire sur les clusters de plan de contrôle local pour configurer les fonctionnalités suivantes :

  7. Installez Ubuntu Server sur la machine virtuelle :

    1. Attendez que le pod importer télécharge l'image disque d'installation d'Ubuntu Server.

    2. Vérifiez l'état de la machine virtuelle :

      kubectl get gvm VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    3. Connectez-vous à la machine virtuelle :

      kubectl virt vnc VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    4. Suivez la procédure d'installation d'Ubuntu Linux.

  8. Effectuer un nettoyage :

    1. Arrêtez la machine virtuelle :

      kubectl virt stop VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    2. Modifiez le fichier YAML de la machine virtuelle pour supprimer la référence à l'image disque d'installation :

      kubectl edit gvm VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    3. Démarrez la machine virtuelle :

      kubectl virt start VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    4. Supprimez les ressources VirtualMachineDisk et PersistentVolumeClaim pour l'image disque d'installation :

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

Provisionner une machine virtuelle Windows sur Distributed Cloud avec un stockage de blocs bruts

L'exemple suivant montre comment provisionner une machine virtuelle Windows avec un stockage de blocs bruts. Les étapes sont semblables à celles du provisionnement d'une machine virtuelle Linux, avec l'ajout de l'image de disque de pilote virtio, qui est requise pour installer Windows.

  1. Obtenez une copie sous licence de Windows et de son image de support d'installation.

  2. Créez une ressource PersistentVolumeClaim avec le contenu suivant pour l'image de disque d'installation de Windows, puis appliquez-la à votre cluster. Pour obtenir des instructions, consultez À partir d'une image.

  3. Créez une ressource PersistentVolumeClaim avec le contenu suivant pour le pilote virtio, puis appliquez-la à votre 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. Créez une ressource PersistentVolumeClaim avec le contenu suivant pour le disque dur virtuel de la machine virtuelle, puis appliquez-la à votre cluster :

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

  5. Créez une ressource VirtualMachineDisk avec le contenu suivant pour l'image de disque d'installation Windows, puis appliquez-la à votre cluster :

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

  6. Créez une ressource VirtualMachineDisk avec le contenu suivant pour le pilote virtio, puis appliquez-la à votre cluster :

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

  7. Créez une ressource VirtualMachineDisk avec le contenu suivant pour le disque dur virtuel de la machine virtuelle, puis appliquez-la à votre cluster :

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

  8. Créez une ressource VirtualMachineType avec le contenu suivant qui spécifie la configuration de la machine virtuelle, puis appliquez-la à votre cluster :

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

  9. Créez une ressource VirtualMachine avec le contenu suivant, qui instancie et démarre la machine virtuelle sur le cluster, puis appliquez-la à votre 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

    Le champ osType ne s'applique qu'aux clusters de plan de contrôle local. Il est obligatoire sur les clusters de plan de contrôle local pour configurer les fonctionnalités suivantes :

  10. Installez Windows sur la machine virtuelle :

    1. Attendez que le pod importer télécharge l'image disque d'installation de Windows.

    2. Vérifiez l'état de la machine virtuelle :

      kubectl get gvm VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (win-vm dans cet exemple).

    3. Terminez l'installation de Windows en suivant les étapes décrites dans Se connecter à une VM Windows et terminer l'installation de l'OS.

  11. Effectuer un nettoyage :

    1. Arrêtez la machine virtuelle :

      kubectl virt stop VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (win-vm dans cet exemple).

    2. Suivez la procédure décrite dans Détacher l'image ISO et le disque de pilotes.

Provisionner une machine virtuelle sur Distributed Cloud avec Symcloud Storage

Cette section fournit des exemples de configuration qui illustrent comment provisionner une machine virtuelle Linux et une machine virtuelle Windows sur un cluster Distributed Cloud avec la couche d'abstraction Symcloud Storage.

Avant de suivre les étapes de cette section, vous devez d'abord suivre celles de la section Configurer Distributed Cloud pour Symcloud Storage. Si vous désactivez ultérieurement Symcloud Storage sur le cluster, les machines virtuelles configurées pour utiliser Symcloud Storage échoueront.

Provisionner une machine virtuelle Linux sur Distributed Cloud avec Symcloud Storage

L'exemple suivant montre comment provisionner une machine virtuelle Linux avec Symcloud Storage exécutant Ubuntu Server 22.04. La source d'installation est l'image disque ISO Ubuntu Server 22.04.

  1. Créez une ressource VirtualMachineDisk avec le contenu suivant pour l'image de disque d'installation Ubuntu Server, puis appliquez-la à votre 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. Créez une ressource VirtualMachineDisk avec le contenu suivant pour le disque dur virtuel de la machine virtuelle, puis appliquez-la à votre cluster :

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

  3. Créez une ressource VirtualMachineType avec le contenu suivant qui spécifie la configuration de la machine virtuelle, puis appliquez-la à votre cluster :

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

  4. Créez une ressource VirtualMachine avec le contenu suivant, qui instancie et démarre la machine virtuelle sur le cluster, puis appliquez-la à votre 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

    Le champ osType ne s'applique qu'aux clusters de plan de contrôle local. Il est obligatoire sur les clusters de plan de contrôle local pour configurer les fonctionnalités suivantes :

  5. Installez Ubuntu Server sur la machine virtuelle :

    1. Attendez que le pod importer télécharge l'image disque d'installation d'Ubuntu Server.

    2. Vérifiez l'état de la machine virtuelle :

      kubectl get gvm VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    3. Connectez-vous à la machine virtuelle :

      kubectl virt vnc VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    4. Suivez la procédure d'installation d'Ubuntu Linux.

  6. Effectuer un nettoyage :

    1. Arrêtez la machine virtuelle :

      kubectl virt stop VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    2. Modifiez le fichier YAML de la machine virtuelle pour supprimer la référence à l'image disque d'installation :

      kubectl edit gvm VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    3. Démarrez la machine virtuelle :

      kubectl virt start VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (ubu-vm dans cet exemple).

    4. Supprimez la ressource VirtualMachineDisk pour l'image disque d'installation :

      kubectl delete virtualmachinedisk ubuntu-iso-disk

Provisionner une machine virtuelle Windows sur Distributed Cloud avec Symcloud Storage

L'exemple suivant montre comment provisionner une machine virtuelle Windows avec Symcloud Storage. Les étapes sont semblables à celles du provisionnement d'une machine virtuelle Linux, avec l'ajout de l'image de disque de pilote virtio, qui est requise pour installer Windows.

  1. Obtenez une copie sous licence de Windows et de son image de support d'installation.

  2. Créez une ressource VirtualMachineDisk avec le contenu suivant pour l'image de disque d'installation Windows, puis appliquez-la à votre 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

    Remplacez NAT_GATEWAY par l'URL complète de l'image disque ISO d'installation de Windows cible.

  3. Créez une ressource VirtualMachineDisk avec le contenu suivant pour le pilote virtio, puis appliquez-la à votre 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. Créez une ressource VirtualMachineDisk avec le contenu suivant pour le disque dur virtuel de la machine virtuelle, puis appliquez-la à votre cluster :

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

  5. Créez une ressource VirtualMachineType avec le contenu suivant qui spécifie la configuration de la machine virtuelle, puis appliquez-la à votre cluster :

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

  6. Créez une ressource VirtualMachine avec le contenu suivant, qui instancie et démarre la machine virtuelle sur le cluster, puis appliquez-la à votre 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

    Le champ osType ne s'applique qu'aux clusters de plan de contrôle local. Il est obligatoire sur les clusters de plan de contrôle local pour configurer les fonctionnalités suivantes :

  7. Installez Windows sur la machine virtuelle :

    1. Attendez que le pod importer télécharge l'image disque d'installation de Windows.

    2. Vérifiez l'état de la machine virtuelle :

      kubectl get gvm VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (win-vm dans cet exemple).

    3. Terminez l'installation de Windows en suivant les étapes décrites dans Se connecter à une VM Windows et terminer l'installation de l'OS.

  8. Effectuer un nettoyage :

    1. Arrêtez la machine virtuelle :

      kubectl virt stop VM_NAME

      Remplacez VM_NAME par le nom de la machine virtuelle (win-vm dans cet exemple).

    2. Suivez la procédure décrite dans Détacher l'image ISO et le disque de pilotes.

Provisionner une machine virtuelle sur Distributed Cloud à l'aide de virtctl

Si vous n'avez pas besoin de la personnalisation fournie par la création de vos propres spécifications de ressources pour vos machines virtuelles, vous pouvez provisionner une machine virtuelle sur Distributed Cloud à l'aide de l'outil de ligne de commande virtctl, comme décrit dans Créer une VM.

Gérer les machines virtuelles exécutées sur Distributed Cloud

Pour savoir comment gérer les machines virtuelles exécutées sur Distributed Cloud, consultez la documentation suivante sur l'environnement d'exécution des VM sur GDC :

Pour gérer les machines virtuelles exécutées sur des clusters de plan de contrôle local, vous devez d'abord configurer la connectivité kubectl.

Configurer l'appareil ttyS0 pour l'accès à la console série des machines virtuelles Linux

Si vous prévoyez d'accéder à vos machines virtuelles Linux à l'aide de la console série (kubectl virt console), assurez-vous que le périphérique de console série ttyS0 a été configuré sur le système d'exploitation invité. Pour configurer cet appareil, procédez comme suit :

  1. Instanciez le périphérique série ttyS0 dans le système :

    setserial -g /dev/ttyS0

  2. Configurez le bootloader grub pour qu'il utilise le périphérique série ttyS0 en ajoutant les lignes suivantes à votre fichier de configuration /etc/default/grub. La première ligne remplace votre variable GRUB_CMDLINE_LINUX existante.

    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. Appliquez la nouvelle configuration grub à votre secteur de démarrage :

    update-grub

  4. Redémarrez la machine virtuelle.

Désactiver l'environnement d'exécution de VM sur GDC sur Distributed Cloud

Suivez les étapes de cette section pour désactiver VM Runtime sur GDC sur Distributed Cloud. Avant de pouvoir désactiver l'environnement d'exécution des VM sur GDC sur Distributed Cloud, vous devez arrêter et supprimer toutes les machines virtuelles de votre cluster Distributed Cloud, comme décrit dans Supprimer une VM.

Pour désactiver VM Runtime sur GDC sur Distributed Cloud, modifiez la ressource personnalisée VMRuntime en définissant le paramètre de spécification enabled sur false comme suit, puis appliquez-le à votre 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"

Étapes suivantes