JoLeKing

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Guide d'Architecture & Déploiement : OpenShift Virtualization ======

Ce document décrit l'architecture, la configuration réseau et stockage, ainsi que les procédures d'exploitation pour faire tourner des machines virtuelles (VMs) d'entreprise sur notre cluster de serveurs physiques HPE ProLiant DL360.

----

===== 📌 Architecture Globale =====

L'infrastructure repose sur un modèle de virtualisation hybride combinant serveurs physiques et stockage partagé centralisé :
  * **Hyperviseurs :** Serveurs bare-metal HPE ProLiant Gen9/Gen10 (''dl360g9-3'' actif, et bientôt ''dl360g9-4'') sous Red Hat Enterprise Linux CoreOS (RHCOS) avec support KVM.
  * **Stockage des VMs :** Pool de stockage centralisé NFS v4.2 hébergé sur **TrueNAS Core** (''10.194.16.14'').
  * **Réseau VMs :** Commutateur virtuel **Open vSwitch (OVS)** isolé sur des liaisons physiques dédiées (''ens1f1'') avec tagging 802.1Q dynamique géré par **OVN-Kubernetes**.

----

===== 💾 1. Préparation & Configuration du Stockage (NFS TrueNAS) =====

La configuration du stockage est le pilier central de l'architecture. Elle permet d'assurer la persistance des disques virtuels et d'autoriser la migration à chaud (//Live Migration//) des VMs entre nos hyperviseurs.

==== Étape 1 : Permissions côté TrueNAS (Critique) ====
Pour que les processus de virtualisation d'OpenShift (les pods d'importation et le runtime QEMU s'exécutant avec l'UID ''107'') puissent lire et écrire sur le partage, les permissions NFS doivent être configurées comme suit sur TrueNAS :
  * **Export NFS :** ''/mnt/pool1/nfs/mtrllabocp''
  * **Sécurité / Permissions :** Activé en lecture/écriture (''Read/Write'').
  * **Maproot / Mapall :** Configurer **Mapall User: root** (ou s'assurer que les permissions du dossier physique sur le pool sont en ''chmod -R 777'' pour éviter les redémarrages en boucle de l'importateur CDI avec l'erreur ''Permission denied'').

==== Étape 2 : Configuration de la StorageClass OCP (nfs-csi-rwx) ====
Nous utilisons le provisionneur de sous-répertoires NFS d'OpenShift pour structurer nos fichiers de disques durs virtuels. Nous configurons ''onDelete: "delete"'' conjointement au ''pathPattern'' pour s'assurer que les dossiers temporaires ou disques supprimés soient nettoyés proprement sur TrueNAS.

<code yaml>
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-csi-rwx
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  # 1. Regroupe et préfixe tous les PVCs proprement dans le dossier /vms
  pathPattern: "vms/\${.PVC.namespace}-\${.PVC.name}"
  # 2. Supprime proprement les sous-dossiers lors de la suppression d'une VM (pas d'archivage parasite)
  onDelete: "delete"
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - nfsvers=4.2
</code>

----

===== 🌐 2. Préparation & Configuration Réseau (OVS & OVN Localnet) =====

Pour isoler hermétiquement le trafic réseau de nos VMs tout en leur permettant de communiquer directement avec nos switchs physiques externes, nous utilisons une interface dédiée **''ens1f1''** rattachée à un pont Open vSwitch.

<code>
       [ VM Fedora (vlan217-nic / vlan218-nic) ]
                          |
             [ Bridge OVS interne: br-int ]
                          |
             [ OVN localnet bridge-mapping ]
                          |
             [ Bridge OVS physique: br-vms ]
                          |
             [ Interface Physique: ens1f1 ] ===> [ Switch Physique Trunk ]
</code>

==== Étape 1 : NMState - Création du Pont OVS Physique (br-vms) ====
Nous utilisons l'opérateur **Kubernetes NMState** pour provisionner de manière déclarative l'infrastructure réseau. Ce profil cible uniquement les serveurs physiques étiquetés avec le label ''physicalworker: "true"''.

<code yaml>
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ovs-vm-traffic-policy
spec:
  nodeSelector:
    physicalworker: "true"
  desiredState:
    interfaces:
      # 1. Interface physique Trunk
      - name: ens1f1
        type: ethernet
        state: up
        ipv4:
          enabled: false
        ipv6:
          enabled: false
      # 2. Création du pont OVS dédié
      - name: br-vms
        description: "Dedicated OVS Bridge for Virtual Machines on ens1f1"
        type: ovs-bridge
        state: up
        bridge:
          options:
            stp: false
          port:
            - name: ens1f1
    # 3. Association logique du pont OVS au moteur OVN-Kubernetes
    ovn:
      bridge-mappings:
        - localnet: vms-localnet
          bridge: br-vms
          state: present
</code>

==== Étape 2 : Création des Réseaux Virtuels (Multus NADs) ====
L'intégration des VLANs se fait de manière dynamique à l'aide de définitions de réseaux secondaires basées sur le pilote officiel d'OpenShift ''ovn-k8s-cni-overlay''. Cette méthode évite de devoir créer des sous-interfaces étiquetées complexes sur chaque nœud hôte.

**Règle d'or de DokuWiki / Multus :** La configuration ''config'' doit être déclarée à plat (sans tableau ''plugins: [...]''), sous forme de chaîne de caractères YAML (''config: |-''), et contenir impérativement les clés d'identification réseau ''netAttachDefName'' et ''nadName''.

==== VLAN 217 (physicalworker/ovs-vlan217.yaml) ====

<code yaml>
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: ovs-vlan217-net
  namespace: default
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "ovs-vlan217-net",
      "type": "ovn-k8s-cni-overlay",
      "topology": "localnet",
      "netAttachDefName": "default/ovs-vlan217-net",
      "nadName": "default/ovs-vlan217-net",
      "physicalNetworkName": "vms-localnet",  
      "vlanID": 217
    }
</code>

==== VLAN 218 (physicalworker/ovs-vlan218.yaml) ====

<code yaml>
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: ovs-vlan218-net
  namespace: default
spec:
  config: |-
    {
      "cniVersion": "0.3.1",
      "name": "ovs-vlan218-net",
      "type": "ovn-k8s-cni-overlay",
      "topology": "localnet",
      "netAttachDefName": "default/ovs-vlan218-net",
      "nadName": "default/ovs-vlan218-net",
      "physicalNetworkName": "vms-localnet",  
      "vlanID": 218
    }
</code>

----

===== 🚀 3. Déploiement d'une Machine Virtuelle Multi-NIC =====

Voici le manifest complet à utiliser pour instancier notre VM Fedora de référence. Elle est configurée avec **3 interfaces réseau** (1 réseau de pod par défaut pour OpenShift, 1 carte sur le VLAN 217 et 1 carte sur le VLAN 218).

Le stockage utilise le mode de téléchargement fiable ''source: registry'' depuis Quay.io pour éliminer définitivement les instabilités liées aux téléchargements d'URLs HTTP.

<code yaml>
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: fedora-nfs-vm
  namespace: default
spec:
  runStrategy: Always
  dataVolumeTemplates:
    - metadata:
        name: fedora-nfs-disk
      spec:
        pvc:
          accessModes:
            - ReadWriteMany
          resources:
            requests:
              storage: 20Gi
          storageClassName: nfs-csi-rwx
          volumeMode: Filesystem
        source:
          registry:
            url: "docker://quay.io/containerdisks/fedora:40"
  template:
    metadata:
      labels:
        kubevirt.io/vm: fedora-nfs-vm
    spec:
      nodeSelector:
        physicalworker: "true"
      domain:
        cpu:
          cores: 2
          sockets: 1
          threads: 1
        resources:
          requests:
            memory: 2Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          # ================= MULTI-NIC CONFIGURATION =================
          interfaces:
            # NIC 1 : Réseau interne SDN OpenShift
            - name: default
              masquerade: {}
            # NIC 2 : Patte VLAN 217 (OVS Bridge br-vms)
            - name: vlan217-nic
              bridge: {}
            # NIC 3 : Patte VLAN 218 (OVS Bridge br-vms)
            - name: vlan218-nic
              bridge: {}
          # ==========================================================
      networks:
        - name: default
          pod: {}
        - name: vlan217-nic
          multus:
            networkName: default/ovs-vlan217-net
        - name: vlan218-nic
          multus:
            networkName: default/ovs-vlan218-net
      volumes:
        - name: rootdisk
          dataVolume:
            name: fedora-nfs-disk
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |-
              #cloud-config
              user: fedora
              password: fedora_password
              chpasswd: { expire: False }
              ssh_pwauth: True
</code>

----

===== 🏷️ 6. Configuration d'Adresses MAC Statiques (Multi-NIC) =====

Par défaut, KubeVirt attribue une adresse MAC aléatoire aux interfaces réseau de la VM à chaque démarrage complet (transition de l'état ''Stopped'' à ''Running''). 

Pour des VMs d'entreprise, cette variation peut perturber l'attribution de baux DHCP statiques ou corrompre les configurations réseau gérées par des outils invités (comme ''NetworkManager'' sous Fedora/RHEL ou ''Netplan'' sous Ubuntu/Debian).

==== Étape 1 : Définition des Adresses MAC dans le YAML ====

Pour figer une adresse MAC de manière persistante sur une interface réseau, il suffit de rajouter le paramètre **''macAddress''** sous la carte virtuelle concernée dans la section ''interfaces'' de la VM :

<code yaml>
          # ================= CONFIGURATION DES CARTES RÉSEAU (NICs) =================
          interfaces:
            # NIC 1 : Réseau par défaut (Kubernetes SDN interne)
            - name: default
              masquerade: {}
              
            # NIC 2 : VLAN 217 avec une adresse MAC fixe
            - name: vlan217-nic
              bridge: {}
              macAddress: "02:00:00:00:02:17"   # <--- Adresse MAC Statique !
              
            # NIC 3 : VLAN 218 avec une adresse MAC fixe
            - name: vlan218-nic
              bridge: {}
              macAddress: "02:00:00:00:02:18"   # <--- Adresse MAC Statique !
</code>

==== Étape 2 : Règles d'Or pour la Sélection des adresses MAC ====

Lors de l'attribution manuelle de vos adresses MAC, respectez impérativement ces trois règles d'ingénierie réseau :
  * **MAC Localement Administrées (LAA) :** Pour éviter tout conflit avec des cartes physiques réelles de constructeurs sur votre réseau Bell, utilisez des adresses MAC locales. Le **premier octet** de votre adresse MAC doit obligatoirement se terminer par **2, 6, A, ou E** (exemples : ''02:xx:xx...'', ''06:xx:xx...'', ''0A:xx:xx...'', ''0E:xx:xx...'').
  * **Unicité Absolue :** Assurez-vous qu'aucune VM de votre segment réseau de niveau 2 ne partage la même adresse MAC sous peine de provoquer du //mac-flapping// sur vos switchs physiques Cisco/Juniper.
  * **Compatibilité CNI :** Les pilotes d'OpenShift ''ovn-k8s-cni-overlay'' et le standard ''linux-bridge'' gèrent nativement et de manière transparente le //pass-through// de ces adresses MAC personnalisées.

==== Étape 3 : Gestion Automatique de Pool (KubeMacPool) ====

Pour un déploiement de VMs à grande échelle, la gestion manuelle des adresses MAC devient complexe. OpenShift Virtualization intègre par défaut **KubeMacPool**, un contrôleur qui alloue et réserve automatiquement un pool d'adresses MAC uniques et persistantes pour chaque carte réseau secondaire créée.

Vous pouvez vérifier que KubeMacPool est actif et inspecter sa plage d'adresses MAC globale avec cette commande :

<code bash>
oc get hco kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.kubeMacPoolConfiguration}'
</code>


===== 📟 4. Utilisation de la Console Virtuelle (virtctl) =====

Pour administrer la VM depuis la console de ton terminal local sous Xubuntu, l'outil dédié **virtctl** est indispensable.

==== Installation de virtctl (Xubuntu) ====

<code bash>
# Téléchargement depuis les utilitaires CLI exposés par ton propre cluster OCP
curl -kO https://hyperconverged-cluster-cli-download-openshift-cnv.apps.<CLUSTER>.<FQDN>/amd64/linux/virtctl.tar.gz

# Extraction et installation dans le PATH système
tar xzvf virtctl.tar.gz
chmod +x virtctl
sudo mv virtctl /usr/local/bin/
</code>

==== Connexion & Exploitation ====

<code bash>
# Lancement de la console interactive
virtctl console fedora-nfs-vm -n default
</code>

  * 👤 **Utilisateur par défaut :** ''fedora''
  * 🔑 **Mot de passe par défaut :** ''fedora_password''
  * 🚪 **Quitter la console virtuelle :** Appuie simultanément sur **''Ctrl + ]''**.

----

===== 🛠️ 5. Boîte à Outils de Troubleshooting (Commandes Vitales) =====

Conserve ces commandes à portée de main dans ton DokuWiki pour diagnostiquer rapidement les anomalies sur ton lab.

==== Diagnostic Stockage (NFS) ====

<code bash>
# Vérifier l'état global du DataVolume de disque virtuel
oc get dv -n default

# Consulter les logs de l'importateur CDI si le disque reste bloqué
oc logs -n default -l cdi.kubevirt.io/testing=manifest-test-pvc

# Lister les fichiers physiquement écrits sur le montage TrueNAS
sudo mount 10.194.16.14:/mnt/pool1/nfs/mtrllabocp /tmp/nfs && ls -la /tmp/nfs/vms/ && sudo umount /tmp/nfs
</code>

==== Diagnostic Réseau (OVS / Multus) ====

<code bash>
# Visualiser la configuration et les interfaces logiques en temps réel sur le nœud physique
oc debug node/dl360g9-3 -- chroot /host ovs-vsctl show

# Inspecter l'état réseau configuré et appliqué par NMState sur l'hôte physique
oc get nodenetworkstate dl360g9-3 -o yaml

# Inspecter les événements d'initialisation réseau ou d'attribution d'interfaces sur le pod
oc describe pod -l kubevirt.io/vm=fedora-nfs-vm -n default | grep -A 10 Events:
</code>


===== 💾 8. Procédure Officielle : Création et Attachement de Disques Additionnels (Hotplug) =====

Cette section décrit la procédure d'ingénierie standard pour provisionner un nouveau disque dur virtuel vierge et l'attacher à chaud (sans aucune coupure de service) à une machine virtuelle existante en cours d'exécution.

==== Pourquoi utiliser un DataVolume plutôt qu'un PVC brut ? ====

Dans un stockage de type NFS (mode ''Filesystem''), le moteur de virtualisation KubeVirt requiert impérativement un fichier image structuré nommé **''disk.img''** à la racine du volume pour émuler un disque physique brut (périphérique de bloc) à la VM.
  * Un PVC Kubernetes brut créé un répertoire vide sur TrueNAS, ce qui provoque un plantage immédiat de l'émulateur QEMU (erreur ''disk.img: no such file or directory'') et place la VM en ''CrashLoopBackOff''.
  * L'utilisation d'un **''DataVolume''** avec l'instruction ''blank: {}'' délègue à l'importateur CDI d'OpenShift le provisionnement automatique du dossier NFS ET la création du fichier ''disk.img'' à la taille spécifiée.

==== Étape 1 : Le Payload de création du volume (create-hotplug-volume.yaml) ====

Créez le fichier de configuration suivant :

<code yaml>
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: extra-data-disk
  namespace: default
spec:
  source:
    # Force l'importateur CDI à générer le fichier disk.img requis par QEMU/KVM
    blank: {}
  pvc:
    accessModes:
      # RWX requis pour supporter la Live Migration de la VM vers un autre hyperviseur
      - ReadWriteMany
    resources:
      requests:
        storage: 15Gi
    storageClassName: nfs-csi-rwx
    volumeMode: Filesystem
</code>

Appliquez le manifest pour lancer la création sur TrueNAS :
<code bash>
oc apply -f create-hotplug-volume.yaml
</code>

==== Étape 2 : Validation du provisionnement ====

Avant de rattacher le disque à la VM, assurez-vous que l'importateur d'OpenShift a terminé la création et le formatage physique du fichier image sur le stockage NFS (le statut doit afficher **''Succeeded''**) :

<code bash>
oc get dv extra-data-disk -n default
</code>
^ NAME ^ PHASE ^ PROGRESS ^ OWNER ^
| extra-data-disk | Succeeded | 100.0% | |

==== Étape 3 : Injection à chaud dans la VM active ====

Une fois le volume prêt, utilisez ''virtctl'' pour connecter le disque en direct. L'argument ''--persist'' garantit que l'association de ce disque est écrite définitivement dans la configuration YAML de la VM (survivant aux reboots et aux migrations) :

<code bash>
virtctl addvolume fedora-nfs-vm --volume-name=extra-data-disk --persist -n default



==== Diagnostics Généraux d'Exploitation ====

<code bash>
# Suivre l'historique complet des événements du namespace par ordre chronologique
oc get events -n default --sort-by='.metadata.creationTimestamp'

# Forcer l'étiquetage correct d'un nœud physique
oc label node dl360g9-4 physicalworker=true --overwrite
</code>

----

===== 💡 Trucs importants et Bonnes Pratiques à retenir =====

  * **Nettoyage régulier de l'espace TrueNAS :** Le provisionneur NFS renomme les répertoires d'essais manuels ratés ou supprimés sous le préfixe ''archived-''. Ils occupent de l'espace disque inutilement. Tu peux supprimer en toute sécurité tous les dossiers commençant par ''archived-'' directement depuis ton partage TrueNAS.
  * **Ne jamais supprimer ''openshift-virtualization-os-images'' à la main :** Ces volumes NFS hébergent les sources de démarrage standard de l'opérateur (Golden Images). Si tu les effaces sur TrueNAS, OpenShift lancera instantanément des c