10.18. Gestion avancée des machines virtuelles

Procédure

1. Définissez des limites pour une VM en modifiant le manifeste VirtualMachine. Par exemple :

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: with-limits
   spec:
     running: false
     template:
       spec:
         domain:
   # ...
           resources:
             requests:
               memory: 128Mi
             limits:
               memory: 256Mi  1

   1

   Cette configuration est supportée parce que la valeur limits.memory est au moins 100Mi plus grande que la valeur requests.memory.

2. Sauvegarder le manifeste VirtualMachine.

Procédure

1. Ouvrez le CR HyperConverged en exécutant la commande suivante :

   $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

2. Modifiez les champs spec.certConfig comme indiqué dans l'exemple suivant. Pour éviter de surcharger le système, assurez-vous que toutes les valeurs sont supérieures ou égales à 10 minutes. Exprimez toutes les valeurs sous forme de chaînes de caractères conformes au format golang ParseDuration .

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
    name: kubevirt-hyperconverged
    namespace: openshift-cnv
   spec:
     certConfig:
       ca:
         duration: 48h0m0s
         renewBefore: 24h0m0s 1
       server:
         duration: 24h0m0s  2
         renewBefore: 12h0m0s  3

   1

   La valeur de ca.renewBefore doit être inférieure ou égale à la valeur de ca.duration.

   2

   La valeur de server.duration doit être inférieure ou égale à la valeur de ca.duration.

   3

   La valeur de server.renewBefore doit être inférieure ou égale à la valeur de server.duration.

3. Appliquez le fichier YAML à votre cluster.

Procédure

1. Modifiez ou créez un fichier manifeste VirtualMachine. Utilisez la strophe spec.firmware.bootloader pour configurer le mode UEFI :

   Démarrage en mode UEFI avec démarrage sécurisé actif

   apiversion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       special: vm-secureboot
     name: vm-secureboot
   spec:
     template:
       metadata:
         labels:
           special: vm-secureboot
       spec:
         domain:
           devices:
             disks:
             - disk:
                 bus: virtio
               name: containerdisk
           features:
             acpi: {}
             smm:
               enabled: true 1
           firmware:
             bootloader:
               efi:
                 secureBoot: true 2
   ...

   1

   OpenShift Virtualization nécessite que le mode de gestion du système (SMM) soit activé pour que le démarrage sécurisé en mode UEFI se produise.

   2

   OpenShift Virtualization supporte une VM avec ou sans Secure Boot lors de l'utilisation du mode UEFI. Si Secure Boot est activé, le mode UEFI est requis. Cependant, le mode UEFI peut être activé sans utiliser le mode Secure Boot.

2. Appliquez le manifeste à votre cluster en exécutant la commande suivante :

   oc create -f <nom_du_fichier>.yaml

Procédure

1. Configurer un réseau PXE sur le cluster :

   1. Créer le fichier de définition de l'attachement réseau pour le réseau PXE pxe-net-conf:

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'

      1

      Facultatif : La balise VLAN.

      2

      Le plugin cnv-tuning prend en charge les adresses MAC personnalisées.

      Note

      L'instance de machine virtuelle sera connectée au pont br1 via un port d'accès avec le VLAN demandé.

2. Créez la définition de la pièce jointe au réseau en utilisant le fichier que vous avez créé à l'étape précédente :

   $ oc create -f pxe-net-conf.yaml

3. Modifiez le fichier de configuration de l'instance de la machine virtuelle pour y inclure les détails de l'interface et du réseau.

   1. Spécifiez le réseau et l'adresse MAC, si le serveur PXE l'exige. Si l'adresse MAC n'est pas spécifiée, une valeur est attribuée automatiquement.

      Assurez-vous que bootOrder est défini sur 1 afin que l'interface démarre en premier. Dans cet exemple, l'interface est connectée à un réseau appelé <pxe-net>:

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1

      Note

      L'ordre de démarrage est global pour les interfaces et les disques.

   2. Attribuez un numéro de périphérique de démarrage au disque afin de garantir un démarrage correct après le provisionnement du système d'exploitation.

      Réglez la valeur du disque bootOrder sur 2:

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2

   3. Spécifiez que le réseau est connecté à la définition de l'attachement au réseau créée précédemment. Dans ce scénario, <pxe-net> est connecté à la définition d'attachement au réseau appelée <pxe-net-conf>:

      networks:
      - name: default
        pod: {}
      - name: pxe-net
        multus:
          networkName: pxe-net-conf

4. Créer l'instance de la machine virtuelle :

   $ oc create -f vmi-pxe-boot.yaml

1. Attendez que l'instance de la machine virtuelle s'exécute :

   $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
     phase: Running

2. Visualisez l'instance de la machine virtuelle à l'aide de VNC :

   $ virtctl vnc vmi-pxe-boot

3. Observez l'écran de démarrage pour vérifier que le démarrage PXE est réussi.

4. Connectez-vous à l'instance de la machine virtuelle :

   $ virtctl console vmi-pxe-boot

5. Vérifiez les interfaces et l'adresse MAC sur la machine virtuelle et que l'interface connectée au pont a l'adresse MAC spécifiée. Dans ce cas, nous avons utilisé eth1 pour le démarrage PXE, sans adresse IP. L'autre interface, eth0, a reçu une adresse IP de OpenShift Container Platform.

   $ ip addr

Procédure

1. Dans la configuration de votre machine virtuelle, ajoutez les paramètres resources.requests.memory et memory.hugepages.pageSize au paramètre spec.domain. L'extrait de configuration suivant concerne une machine virtuelle qui demande un total de 4Gi de mémoire avec une taille de page de 1Gi:

   kind: VirtualMachine
   ...
   spec:
     domain:
       resources:
         requests:
           memory: "4Gi" 1
       memory:
         hugepages:
           pageSize: "1Gi" 2
   ...

   1

   La quantité totale de mémoire demandée pour la machine virtuelle. Cette valeur doit être divisible par la taille de la page.

   2

   La taille de chaque grande page. Les valeurs valables pour l'architecture x86_64 sont 1Gi et 2Mi. La taille de la page doit être inférieure à la mémoire demandée.

2. Appliquer la configuration de la machine virtuelle :

   oc apply -f <virtual_machine>.yaml

Procédure

1. Dans la console OpenShift Container Platform, cliquez sur Virtualization VirtualMachines dans le menu latéral.
2. Sélectionnez une machine virtuelle pour ouvrir la page VirtualMachine details.
3. Dans l'onglet Scheduling, cliquez sur l'icône représentant un crayon à côté de Dedicated Resources.
4. Sélectionnez Schedule this workload with dedicated resources (guaranteed policy).
5. Cliquez sur Save.

Procédure

1. Dans la console web de OpenShift Container Platform, cliquez sur Virtualization VirtualMachines dans le menu latéral.
2. Sélectionnez la machine virtuelle à laquelle vous souhaitez attribuer le périphérique.

3. Dans l'onglet Details, cliquez sur GPU devices.

   Si vous ajoutez un périphérique vGPU en tant que périphérique hôte, vous ne pouvez pas accéder au périphérique avec la console VNC.

4. Cliquez sur Add GPU device, entrez dans Name et sélectionnez l'appareil dans la liste Device name.
5. Cliquez sur Save.
6. Cliquez sur l'onglet YAML pour vérifier que les nouveaux appareils ont été ajoutés à la configuration de votre cluster dans la section hostDevices.

Procédure

1. Créez un fichier YAML avec le contenu suivant :

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm2-rhel84-watchdog
     name: <vm-name>
   spec:
     running: false
     template:
       metadata:
        labels:
           kubevirt.io/vm: vm2-rhel84-watchdog
       spec:
         domain:
           devices:
             watchdog:
               name: <watchdog>
               i6300esb:
                 action: "poweroff" 1
   ...

   1

   Spécifiez l'action watchdog (poweroff, reset, ou shutdown).

   L'exemple ci-dessus configure le dispositif de surveillance i6300esb sur une VM RHEL8 avec l'action de mise hors tension et expose le dispositif en tant que /dev/watchdog.

   Ce dispositif peut maintenant être utilisé par le binaire chien de garde.

2. Appliquez le fichier YAML à votre cluster en exécutant la commande suivante :

   oc apply -f <nom_du_fichier>.yaml

1. Exécutez la commande suivante pour vérifier que la VM est connectée au dispositif de surveillance :

   $ lspci | grep watchdog -i

2. Exécutez l'une des commandes suivantes pour confirmer que le chien de garde est actif :

   • Déclencher une panique du noyau :

     # echo c > /proc/sysrq-trigger

   • Mettre fin au service de chien de garde :

     # pkill -9 watchdog

Procédure

1. En tant qu'utilisateur root, installez le paquetage watchdog et ses dépendances :

   # yum install watchdog

2. Décommentez la ligne suivante dans le fichier /etc/watchdog.conf et enregistrez les modifications :

   #watchdog-device = /dev/watchdog

3. Activer le service watchdog pour qu'il démarre au démarrage :

   # systemctl enable --now watchdog.service

Procédure

1. Définir un nouveau storageClassName en modifiant la ressource personnalisée (CR) HyperConverged.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: rhel8-image-cron
       spec:
         template:
           spec:
             storageClassName: <appropriate_class_name>
   ...

2. Définissez la nouvelle classe de stockage par défaut en exécutant les commandes suivantes :

   $ oc patch storageclass <current_default_storage_class> -p '{"metadata" : {"annotations":{"storageclass.kubernetes.io/is-default-class":\N "false"}}}'

   $ oc patch storageclass <appropriate_storage_class> -p '{"metadata" : {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Procédure

1. La commande suivante permet d'ouvrir le CR HyperConverged pour l'éditer :

   $ oc edit -n openshift-cnv HyperConverged

2. Modifiez le CR HyperConverged en ajoutant le modèle et la source de démarrage appropriés dans la section dataImportCronTemplates. Par exemple :

   Exemple sous CentOS 7

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: centos7-image-cron
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
       spec:
         schedule: "0 */12 * * *" 2
         template:
           spec:
             source:
               registry: 3
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 10Gi
         managedDataSource: centos7 4
         retentionPolicy: "None" 5

   1

   Cette annotation est requise pour les classes de stockage dont la valeur volumeBindingMode est fixée à WaitForFirstConsumer.

   2

   Planification du travail spécifié au format cron.

   3

   Permet de créer un volume de données à partir d'une source de registre. Utilisez la valeur par défaut pod pullMethod et non node pullMethod , qui est basée sur le cache de docker node. Le cache docker node est utile lorsqu'une image de registre est disponible via Container.Image, mais que l'importateur CDI n'est pas autorisé à y accéder.

   4

   Pour que l'image personnalisée soit détectée comme source de démarrage disponible, le nom de l'image managedDataSource doit correspondre au nom du modèle DataSource, qui se trouve sous spec.dataVolumeTemplates.spec.sourceRef.name dans le fichier YAML du modèle VM.

   5

   Utilisez All pour conserver les volumes et les sources de données lorsque la tâche cron est supprimée. Utilisez None pour supprimer les volumes et les sources de données lorsque la tâche cron est supprimée.

Procédure

1. Utilisez la commande oc get pour dresser la liste des dataImportChronTemplates dans le CR HyperConverged.

2. Vérifier l'état de la source de démarrage.

   Exemple de sortie

   ...
   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   ...
   spec:
     ...
   status: 1
     ...
     dataImportCronTemplates: 2
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: centos-7-image-cron
       spec:
         garbageCollect: Outdated
         managedDataSource: centos7
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status:
         commonTemplate: true 3
       ...
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: user-defined-dic
       spec:
         garbageCollect: Outdated
         managedDataSource: user-defined-centos-stream8
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 pullMethod: node
                 url: docker://quay.io/containerdisks/centos-stream:8
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status: {} 4
   ...

   1

   Le champ status pour le CR HyperConverged.

   2

   Le champ dataImportCronTemplates, qui répertorie toutes les sources de démarrage définies.

   3

   Indique une source de démarrage définie par le système.

   4

   Indique une source de démarrage définie par l'utilisateur.

Procédure

1. Connectez-vous à la console web de OpenShift Container Platform.

2. Créer l'espace de noms requis pour l'opérateur Kube Descheduler.

   1. Naviguez jusqu'à Administration Namespaces et cliquez sur Create Namespace.
   2. Entrez openshift-kube-descheduler-operator dans le champ Name, entrez openshift.io/cluster-monitoring=true dans le champ Labels pour activer les métriques du déscheduler, et cliquez sur Create.

3. Installez l'opérateur Kube Descheduler.

   1. Naviguez jusqu'à Operators OperatorHub.
   2. Tapez Kube Descheduler Operator dans le champ de filtre.
   3. Sélectionnez le site Kube Descheduler Operator et cliquez sur Install.
   4. Sur la page Install Operator, sélectionnez A specific namespace on the cluster. Sélectionnez openshift-kube-descheduler-operator dans le menu déroulant.
   5. Ajustez les valeurs de Update Channel et Approval Strategy aux valeurs souhaitées.
   6. Cliquez sur Install.

4. Créer une instance de déscheduler.

   1. Dans la page Operators Installed Operators, cliquez sur Kube Descheduler Operator.
   2. Sélectionnez l'onglet Kube Descheduler et cliquez sur Create KubeDescheduler.

   3. Modifiez les paramètres si nécessaire.

      1. Pour expulser des pods au lieu de simuler les expulsions, remplacez le champ Mode par Automatic.

      2. Développez la section Profiles et sélectionnez DevPreviewLongLifecycle. Le profil AffinityAndTaints est activé par défaut.

         Important

         Le seul profil actuellement disponible pour OpenShift Virtualization est DevPreviewLongLifecycle.

Procédure

1. Avant de démarrer la VM, ajoutez l'annotation descheduler.alpha.kubernetes.io/evict au CR VirtualMachine:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   spec:
     template:
       metadata:
         annotations:
           descheduler.alpha.kubernetes.io/evict: "true"

2. Si vous n'avez pas déjà défini le profil DevPreviewLongLifecycle dans la console web lors de l'installation, spécifiez le profil DevPreviewLongLifecycle dans la section spec.profile de l'objet KubeDescheduler:

   apiVersion: operator.openshift.io/v1
   kind: KubeDescheduler
   metadata:
     name: cluster
     namespace: openshift-kube-descheduler-operator
   spec:
     deschedulingIntervalSeconds: 3600
     profiles:
     - DevPreviewLongLifecycle
     mode: Predictive 1

   1

   Par défaut, le descheduler n'évince pas les pods. Pour évincer des pods, définissez mode à Automatic.