====== 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. 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 ---- ===== 🌐 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. [ 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 ] ==== É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"''. 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 ==== É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) ==== 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 } ==== VLAN 218 (physicalworker/ovs-vlan218.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 } ---- ===== 🚀 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. 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 ---- ===== 🏷️ 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 : # ================= 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 ! ==== É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 : oc get hco kubevirt-hyperconverged -n openshift-cnv -o jsonpath='{.spec.kubeMacPoolConfiguration}' ===== 📟 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) ==== # Téléchargement depuis les utilitaires CLI exposés par ton propre cluster OCP curl -kO https://hyperconverged-cluster-cli-download-openshift-cnv.apps../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/ ==== Connexion & Exploitation ==== # Lancement de la console interactive virtctl console fedora-nfs-vm -n default * 👤 **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) ==== # 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 ==== Diagnostic Réseau (OVS / Multus) ==== # 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: ===== 💾 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 : 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 Appliquez le manifest pour lancer la création sur TrueNAS : oc apply -f create-hotplug-volume.yaml ==== É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''**) : oc get dv extra-data-disk -n default ^ 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) : virtctl addvolume fedora-nfs-vm --volume-name=extra-data-disk --persist -n default ==== Diagnostics Généraux d'Exploitation ==== # 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 ---- ===== 💡 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