Differences

This shows you the differences between two versions of the page.

--- openshift:virtual_machines [2026/10/16 16:00] – created jonathan
+++ openshift:virtual_machines [2026/10/16 17:33] (current) – jonathan
@@ Line 240: / Line 240: @@
 ----
+===== 🏷️ 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) =====
@@ Line 299: / Line 345: @@
 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 ====