Cause racine — le device virtio-net-pci n'avait pas d'adresse PCI explicite. QEMU assigne les slots dans l'ordre des -device ; le nombre de devices PCI avant le NIC varie avec le nombre de disques, donc le slot du NIC bouge, et Linux nomme l'interface enp0s<slot>.

Précision utile : les sdX (scsi-hd) ne sont pas des devices PCI — ils pendent sur le bus scsi via scsi-id. Seuls le contrôleur scsi et les vdX décalent le NIC.

Correctif — adressage PCI explicite et segmenté sur pci.0 :

Slot	Device
`0x00`–`0x01`	host bridge + PIIX3
`0x02`	laissé libre — neutralise l'incertitude sur le VGA par défaut
`0x03`	`virtio-net-pci` → enp0s3
`0x04`–`0x1d`	réservé multi-NIC
`0x1e`	`virtio-scsi-pci`
`0x1f`	`virtio-blk-pci` (`vda`)

Contrainte matérielle — un bus i440fx a 32 slots (0x00–0x1f) ; 0xff n'est pas adressable. Au-delà de 30 devices il faudrait passer en q35 avec des bridges PCIe.

Invariant de conception — une VM n'a qu'un seul disque vdX ; les disques additionnels passent par le scsi. Un garde-fou retourne une erreur explicite si plus d'un vdX est présent, plutôt que de laisser QEMU planter sur un slot manquant.

Conséquence assumée — bus=pci.0 est conservé sur les trois -device : un passage de la machine en q35 casserait le démarrage (Bus 'pci.0' not found, vérifié sur qemu 11.0.0). À rouvrir le jour où q35 devient nécessaire.

Le correctif ne prend effet qu'au prochain restart complet de la VM : les args QEMU ne sont régénérés qu'à ce moment.

Corrigé et validé sur lab1 le 2026-08-14. **Cause racine** — le device `virtio-net-pci` n'avait pas d'adresse PCI explicite. QEMU assigne les slots dans l'ordre des `-device` ; le nombre de devices PCI *avant* le NIC varie avec le nombre de disques, donc le slot du NIC bouge, et Linux nomme l'interface `enp0s<slot>`. Précision utile : les `sdX` (`scsi-hd`) ne sont **pas** des devices PCI — ils pendent sur le bus scsi via `scsi-id`. Seuls le contrôleur scsi et les `vdX` décalent le NIC. **Correctif** — adressage PCI explicite et segmenté sur `pci.0` : | Slot | Device | |---|---| | `0x00`–`0x01` | host bridge + PIIX3 | | `0x02` | laissé libre — neutralise l'incertitude sur le VGA par défaut | | `0x03` | `virtio-net-pci` → **enp0s3** | | `0x04`–`0x1d` | réservé multi-NIC | | `0x1e` | `virtio-scsi-pci` | | `0x1f` | `virtio-blk-pci` (`vda`) | **Contrainte matérielle** — un bus i440fx a 32 slots (`0x00`–`0x1f`) ; `0xff` n'est pas adressable. Au-delà de 30 devices il faudrait passer en q35 avec des bridges PCIe. **Invariant de conception** — une VM n'a qu'**un seul disque `vdX`** ; les disques additionnels passent par le scsi. Un garde-fou retourne une erreur explicite si plus d'un `vdX` est présent, plutôt que de laisser QEMU planter sur un slot manquant. **Conséquence assumée** — `bus=pci.0` est conservé sur les trois `-device` : un passage de la machine en q35 casserait le démarrage (`Bus 'pci.0' not found`, vérifié sur qemu 11.0.0). À rouvrir le jour où q35 devient nécessaire. Le correctif ne prend effet qu'au prochain **restart complet** de la VM : les args QEMU ne sont régénérés qu'à ce moment.

nicolas.boufideline referenced this issue

2026-08-25 12:39:19 +00:00

gestion multi disque #32

nicolas.boufideline referenced this issue

2026-08-25 20:09:04 +00:00

gestion multi subnet #33

nicolas.boufideline referenced this issue

2026-08-25 21:43:08 +00:00

gestion multi subnet #33

nicolas.boufideline referenced this issue

2026-10-03 15:28:36 +00:00

Lab virtuel multi-nœud : hyperviseurs en KVM imbriqué, route reflectors et switchs L3 en VM #50