GnomeZworc
eee15eb68e
Note de version 0.2.0 (Bael), et reprise des huit pages de docs/ qui parlaient de dnsmasq ou du DHCP. Ajouts de fond : la section Backend DHCP de la page de configuration, avec la procédure de bascule manuelle et l'avertissement qu'elle ne migre rien ; la section du serveur intégré dans les services ; et dans la page de diagnostic comment interroger la socket de contrôle, probe étant le point de départ le plus rapide quand une VM n'obtient pas d'adresse. Le nom de version se déduit du rang, pas du numéro : deuxième release, deuxième nom de codenames.md. Construit avec sphinx-build -W --keep-going, sans avertissement. Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>
64 lines
2.5 KiB
ReStructuredText
64 lines
2.5 KiB
ReStructuredText
VPC, subnet et VM
|
|
=================
|
|
|
|
Trois types de ressources, une hiérarchie stricte.
|
|
|
|
.. mermaid::
|
|
|
|
graph TD
|
|
VPC["VPC<br/><i>network namespace</i><br/>cidr"] --> SN1["Subnet<br/><i>bridge + VXLAN</i><br/>interface_ip, cidr"]
|
|
VPC --> SN2["Subnet"]
|
|
SN1 --> VM1["VM<br/><i>QEMU/KVM</i>"]
|
|
SN1 --> VM2["VM"]
|
|
SN2 --> VM2
|
|
|
|
VPC
|
|
---
|
|
|
|
Un VPC est un **network namespace** portant un espace d'adressage (``cidr``). C'est l'unité
|
|
d'isolation : deux VPC ne se voient pas, et peuvent réutiliser les mêmes plages d'adresses.
|
|
|
|
Un VPC ne peut être supprimé que si tous ses subnets le sont déjà — sinon 409.
|
|
|
|
Subnet
|
|
------
|
|
|
|
Un subnet appartient à un VPC et pose, dans son netns, un bridge qui porte ``interface_ip`` — la
|
|
gateway vue par les VM. Il fournit aussi le DHCP — dnsmasq ou le serveur intégré selon
|
|
``dhcp.backend`` — et les routes annoncées aux guests.
|
|
|
|
``iface_type`` est une clé **logique** (``vms``, ``internet``, ``admin``…), traduite en nom de
|
|
bridge physique par la configuration de l'agent. Une clé absente ou inconnue retombe sur
|
|
``default_interface``. Ce niveau d'indirection permet au même appel d'API de fonctionner sur des
|
|
hosts dont le nommage réseau diffère.
|
|
|
|
Le comportement réseau dépend du :doc:`mode </concepts/modes-reseau>`.
|
|
|
|
VM
|
|
--
|
|
|
|
Une VM est un processus QEMU/KVM raccordé à un ou plusieurs subnets par des taps.
|
|
|
|
**Interfaces.** L'ordre du tableau ``interfaces`` détermine le slot PCI (``0x03 + index``), donc
|
|
le nom de l'interface dans le guest. Exactement une interface doit être ``primary`` : elle porte
|
|
la route par défaut et le serveur de metadata. Tous les subnets d'une VM doivent appartenir au
|
|
**même VPC**.
|
|
|
|
**Stockage.** Un seul disque ``vdX`` (virtio-blk) par VM ; les disques supplémentaires passent
|
|
par le contrôleur SCSI (``sdX``). Cette contrainte vient de la carte PCI figée — voir
|
|
:doc:`/architecture/contraintes`.
|
|
|
|
Ce qui est stocké, et où
|
|
------------------------
|
|
|
|
Une ressource ne porte en base que ce qui lui est propre. Une VM stocke le **lien** vers son
|
|
subnet (``vm/<name>/subnet``), pas le VPC ni le bridge ni la gateway : ces valeurs sont lues
|
|
depuis le subnet, leur source canonique. Le schéma complet des clés est dans
|
|
:doc:`/architecture/stockage`.
|
|
|
|
Nommage
|
|
-------
|
|
|
|
L'API est machine-to-machine : elle **ne valide pas** les conventions de nommage, à l'exception
|
|
du motif documenté pour les VPC (``vp-…``). Les exemples de cette documentation suivent la
|
|
convention ``vp-`` / ``sn-`` / ``i-``, mais c'est à l'appelant de la faire respecter.
|