Sans barrette supplémentaire ensuite, que garde l’hôte ?

Deux comptes séparés

Le processeur de cette machine a 32 cœurs et 64 threads. La mémoire se choisit à la commande : 128GB ou 256GB de DDR4-3200 ECC RDIMM. Les deux tailles sont deux machines. Après l’installation, aucun module ne s’ajoute. Les threads se partagent dans le temps entre les invités. Les pages mémoire n’apparaissent pas parce qu’un invité est sur-alloué. Deux comptes passent en premier : un pour les threads, un pour la RAM fixe. Les deux commencent par retirer ce que l’hôte garde.

Les disques forment un troisième compte. Le défaut est 2×1TB NVMe, sans RAID matériel, chaque disque en accès direct. La séparation entre disque système et disques d’invités est dans Comment répartir Proxmox sur deux NVMe en accès direct. Une répartition juste ne transforme pas 128GB en 256GB.

Le débit et les adresses ne changent pas le palier de mémoire. Le décompte d’une adresse en plus avec celle qui est incluse est dans Comment compter l’IPv4 incluse et les adresses en plus. Cette note ne règle que les cœurs et la RAM.

Les threads que l’hôte garde

64 threads viennent de 32 cœurs physiques, deux threads SMT par cœur. Un thread SMT est un cœur partiel. Une base de données, une compilation, ou un invité qui exécute lui-même des machines virtuelles, prend son budget en cœurs physiques. Les invités qui attendent surtout le réseau partagent des threads.

L’hôte garde un lot de threads pour l’interface, le réseau et le stockage. Sans ZFS, 4 threads, soit 2 cœurs. Si un pool utilise ZFS, 8 threads, soit 4 cœurs, pour que le scrub et les sommes de contrôle aient encore de la place. Proxmox n’a pas d’interrupteur nommé réserve hôte. L’affinité CPU de chaque machine virtuelle évite ces threads. Sans ZFS, les invités utilisent 4-63 et laissent 0–3. Avec ZFS, ils utilisent 8-63 et laissent 0–7. Les numéros vont de 0 à 63. Un invité sans cette limite occupe encore les threads réservés, donc chaque invité reçoit la même affinité. Les processus de l’hôte peuvent continuer à utiliser tous les threads.

Les vCPU occupés en même temps restent dans les threads qui restent : 60 sans ZFS, 56 avec ZFS. Les sites peuvent dépasser cette somme, parce qu’ils ne tournent pas tous à plein. Tout invité durablement occupé compte ses vCPU comme des cœurs sur 32. Le plafond est 30 cœurs sans ZFS et 28 avec ZFS. Les deux paliers de mémoire utilisent le même processeur. La machine de 256GB n’ajoute pas de cœurs.

Une base avec 8 vCPU compte pour 8 cœurs. Sans ZFS, l’hôte tient déjà 2 cœurs, il reste donc 22 cœurs pour d’autres invités durablement occupés. Dix sites à 2 vCPU chacun font 20 threads et peuvent voisiner cette base. Une base à 16 vCPU plus quatre invités à 8 vCPU occupés chacun font 48 cœurs, au-delà de 30. Les vCPU occupés se réduisent d’abord. La machine de 256GB a toujours 32 cœurs.

Après l’installation, lscpu montre le nombre de nœuds NUMA. Ce 7543P est un processeur monoprise, et le nombre de nœuds peut quand même dépasser un. Dans ce cas, la mémoire et les vCPU d’une base restent sur un seul nœud. Un seul nœud n’appelle pas de placement entre nœuds.

La RAM que l’hôte garde

La documentation Proxmox laisse au moins 1GB libre pour l’hôte quand la mémoire des invités est attribuée. C’est le plancher. Cette machine fait tourner plusieurs invités, et le nœud porte aussi l’interface, les journaux et le cache de pages. Le budget laisse 8GB de plus au nœud, attribués à aucun invité.

L’ARC ZFS se compte à part, et le plafond réel se lit d’abord. Quand le support d’installation place le système sur ZFS, Proxmox VE 8.1 et les versions suivantes écrivent un plafond d’ARC d’environ 10 pour cent de la RAM, et pas au-dessus de 16GB, dans /etc/modprobe.d/zfs.conf. Dix pour cent de 128GB font environ 12,8GB, sous le plafond. Dix pour cent de 256GB dépassent 16GB, le plafond est donc 16GB. Ce plafond reste du côté hôte. Les médias VE 8 anciens, et un pool créé après l’installation, peuvent ne pas avoir ce plafond.

Un pool créé plus tard retombe sur la valeur par défaut de ZFS, environ la moitié de la RAM. À partir de ZFS 2.3, la valeur par défaut peut atteindre 62,5 pour cent. Sur 128GB, cela retire environ 64GB avant qu’un invité existe. Le plafond se règle, puis les invités se créent.

c_max dans /proc/spl/kstat/zfs/arcstats se lit en octets. Diviser trois fois par 1024 donne des GiB. Si le fichier manque, ZFS n’est pas chargé et l’ARC vaut 0. Pour changer le plafond, écrire zfs_arc_max dans zfs.conf. La valeur est le nombre de GiB multiplié par 1024 au cube. Pour environ 10 pour cent de 128GB, 12GiB valent 12884901888. Sur la machine de 256GB, le plafond ARC est 16GiB, soit 17179869184. Sur les deux tailles, ce plafond est au-dessus du minimum ARC par défaut, environ 1/32 de la RAM, donc cette seule ligne suffit. Ensuite update-initramfs -u, puis redémarrage du nœud. Avant le redémarrage, aucun invité ne se crée sur le nouveau chiffre.

Le plafond dur de la RAM fixe des invités est la RAM physique, moins le plafond ARC, moins 8GB.

Le balloon n’ajoute pas de barrette. Proxmox ne prête de la RAM que lorsque le minimum est sous le maximum, et seulement tant que l’usage de l’hôte reste sous la cible, 80 pour cent par défaut. Il reprend la RAM quand l’hôte est à court. Une base, et tout invité qui exécute lui-même des machines virtuelles, aligne minimum et maximum pour que le cache reste. Les sites peuvent garder un écart. Les parts restent à 1000. KSM ne fusionne que des pages identiques. Il ne transforme pas 128GB en 256GB. KSM reste hors du budget.

Des plans qui tiennent dans 128GB

Les comparaisons ci-dessous sont sans ZFS, avec un plafond dur de 120GB. La RAM fixe signifie minimum égal au maximum. Les vCPU des sites ne comptent pas comme durablement occupés.

Les quatre restent à 120GB ou en dessous, et les cœurs occupés restent sous 30. La marge dépasse 8GB, donc sans ZFS ils peuvent rester sur 128GB. Davantage de sites tiennent encore si chacun est petit et s’ils ne sont pas tous occupés ensemble. La limite de ces lignes est la somme de RAM. Les cœurs ont encore de la place.

Huit cœurs occupés plus les 2 cœurs de l’hôte sont loin de 32. Avec ZFS, le plafond dur est d’environ 107GB. La ligne à 96GB garde environ 11GB et peut rester sur 128GB. La ligne à 104GB n’a plus qu’environ 3GB, ce qui est serré, donc ce plan passe à 256GB.

Des plans qui prennent 256GB

Les trois premières lignes dépassent 120GB, donc 128GB sans ZFS ne les porte pas. La quatrième ligne est à 112GB. Elle ne dépasse pas 120GB, mais il ne reste que 8GB, donc elle est serrée et passe à 256GB. Sans ZFS, le plafond dur de 256GB est 248GB. Les quatre lignes tiennent, et chacune laisse plus de 8GB.

Vingt invités à 8GB, avec 2 vCPU chacun, font 40 threads. Cela reste dans les 60 threads restants. La limite est la RAM. Une base qui veut 128GB fixes ne laisse plus de place, sur la machine de 128GB, pour les 8GB du nœud. Le plafond de 248GB de la machine de 256GB la porte, avec 120GB libres.

Une base de 64GB plus un hôte imbriqué de 48GB font 112GB. Face à 120GB, il reste 8GB, donc le plan passe à 256GB. Si le disque système est déjà en ZFS, le plafond est d’environ 107GB et 112GB le dépassent déjà. Les 48GB de l’hôte imbriqué comptent une fois, en bloc, sur la machine physique. Les petits invités à l’intérieur ne s’ajoutent pas en plus, et pas une seconde fois.

Les deux paliers utilisent un AMD EPYC 7543P, 32 cœurs / 64 threads, 2,8–3,7 GHz, 256MB de L3. La mémoire est de la DDR4-3200 ECC RDIMM. 128GB coûtent $462 par mois. 256GB coûtent $595 par mois. L’écart est de $133. Le palier 256GB ajoute de la mémoire. Le nombre de cœurs reste 32. Les machines sont à Tokyo, au Japon. Proxmox VE 8 et 9 se choisissent sans supplément de système. Les disques par défaut sont 2×1TB NVMe, sans RAID matériel, chacun en accès direct, et l’espace utile est la somme. Le débit est 250M, 1G ou 2G, au supplément mensuel de $0, $255 ou $745, sans plafond de trafic, et il ne change pas le compte de RAM. Une IPv4 est incluse. Les adresses en plus coûtent $2 chacune, jusqu’à 255 de plus. Le montant dû est le total mensuel multiplié par le nombre de mois. Mensuel, trimestriel, semestriel et annuel n’ont pas de remise. Il n’y a pas de frais d’installation. Le nœud se gère en SSH.

Un invité qui fait tourner des invités

La virtualisation imbriquée concerne un invité qui exécute lui-même KVM ou un autre Proxmox. Les sites ordinaires et les bases n’en ont pas besoin. Une fois activée, les invités internes dépensent la RAM et les vCPU de l’invité externe, et l’invité externe dépense la machine physique. Les trois niveaux se retranchent.

Vérifier svm sur l’hôte

Sur le nœud, exécuter grep -m1 svm /proc/cpuinfo. Une sortie signifie que le processeur expose le drapeau AMD svm. Sans sortie, les invités internes n’auront pas d’assistance matérielle. Le plan s’arrête là.

Lire le paramètre imbriqué

cat /sys/module/kvm_amd/parameters/nested vaut 1 quand le côté hôte est déjà actif. La valeur 0 signifie d’arrêter d’abord tous les invités. Créer ou compléter /etc/modprobe.d/kvm-amd.conf avec options kvm-amd nested=1. Le nom du module dans cette ligne porte un trait d’union. Le chemin sysfs porte un tiret bas. Les deux noms désignent le même module. Si le fichier a déjà des lignes, les compléter. Ne pas écraser le fichier. Puis redémarrer le nœud.

L’invité externe utilise le CPU host

Sur le nœud, exécuter qm set 101 --cpu host. Remplacer 101 par l’identifiant de l’invité externe. Le même réglage est Matériel, Processeur, Type : host. Après le changement, arrêter l’invité depuis le nœud puis le démarrer, pour que QEMU soit recréé avec le CPU host. Un redémarrage dans le système invité n’applique pas le nouveau type.

Une fois l’invité démarré, refaire la vérification svm à l’intérieur. Une sortie signifie que les invités internes peuvent utiliser l’assistance matérielle. Un invité externe avec 8 vCPU donne à tous les invités internes ces mêmes 8, pas des cœurs physiques en plus. Trois invités internes à 4 vCPU chacun font 12, déjà au-delà des 8 externes. La couche interne est sur-allouée. Les 32 cœurs physiques ne grandissent pas.

Retirer la RAM externe une seule fois

Un invité externe doté de 48GB doit contenir la RAM fixe interne plus ce que le système externe garde, dans ces 48GB. Trois invités internes à 8GB font 24GB. Le système externe garde 8GB. 48GB couvrent cela. Un invité interne de plus à 32GB fait 24+32+8 = 64, au-delà de 48. Agrandir d’abord l’invité externe. Cet agrandissement revient sur le budget physique : 48GB qui deviennent 64GB se retranchent à nouveau du plafond physique.

Replacer cette couche sur le tableau précédent. Sans ZFS et avec un plafond de 120GB, une base de 64GB plus cet invité externe de 48GB font 112GB, avec 8GB de reste, donc le plan passe à 256GB. Les 24GB à l’intérieur de l’invité externe sont déjà dans les 48GB. L’imbrication convient à un laboratoire et à quelques petits invités dans un seul invité externe. La couche interne ne se remplit pas à la densité de la machine physique. La RAM déjà donnée à l’invité externe ne se donne pas aussi aux autres invités du nœud.

Fermer le compte avant de commander

Le budget compte les invités allumés ensemble, pas chaque invité qui a tourné une fois dans la semaine. Un invité de compilation éteint dans la journée reste hors de la somme du jour. S’il tourne avec la base la nuit, la nuit est une seconde somme. Les deux sommes doivent tenir dans le plafond dur, avec plus de 8GB de reste, avant que 128GB soit la commande. Une somme seulement de jour, qui ignore la nuit, manque de RAM après l’installation, et aucun module ne s’ajoute.

1. Décider si le disque système est en ZFS. Si oui, inclure le plafond ARC. Si non, l’ARC vaut 0. Un pool créé plus tard reçoit d’abord un plafond d’environ 10 pour cent, et pas au-dessus de 16GB.
2. Le nœud garde 8GB. Sans ZFS, l’affinité évite 0–3. Avec ZFS, elle évite 0–7.
3. Additionner la RAM fixe des invités qui tournent ensemble. Un hôte imbriqué compte une fois, en bloc. Les invités internes ne s’ajoutent pas une seconde fois.
4. La somme reste sur 128GB seulement si elle est dans le plafond dur et si le plafond moins la somme dépasse 8GB. Sinon, commander 256GB.
5. Additionner les vCPU durablement occupés, comme des cœurs. Le plafond est 30 sans ZFS et 28 avec ZFS. Au-delà, aucun palier de mémoire n’ajoute de cœurs.
6. Choisir Proxmox VE 8 ou 9. Séparer disque système et disques d’invités comme dans la note sur les disques. Après le SSH vers le nœud, vérifier svm, le paramètre imbriqué et l’ARC avec les commandes ci-dessus.

Un ensemble de journée : base fixe à 64GB et 8 vCPU, minimum aussi à 64GB ; quatre applis à 8GB ; deux sites à 4GB. La somme de RAM est 104GB. Sans ZFS, le plafond est 120GB, il reste donc 16GB, plus que 8GB, et la commande reste à 128GB. La base est 8 cœurs, l’hôte 2, les applis et les sites ne sont pas durablement occupés. Avec ZFS, le plafond est d’environ 107GB, il reste environ 3GB, et la commande passe à 256GB. Si la base elle-même est fixe à 128GB, ce seul invité dépasse déjà 120GB, donc la commande est 256GB. Sans ZFS, le plafond de 256GB est 248GB. Une base de 128GB plus les 40GB d’origine des applis et des sites font 168GB, avec 80GB libres.

Le compte des cœurs est le même sur les deux paliers. Le compte de RAM ne l’est pas. Si la somme de RAM fixe et la marge ne tiennent pas dans 128GB, la commande est la machine de 256GB.