Questions d'entraînement — PVE9-ADMIN-50H

Question 1

Un cluster PVE 9 de 8 noeuds heberge 200 VMs Windows Server 2022 identiques (template clone-linked). La consommation RAM agregee est de 1.4TB mais 'free -h' sur chaque noeud montre une utilisation reelle de seulement 60%. KSM est actif. Apres redemarrage simultane de 50 VMs pour patching, vous observez ksmd a 100% CPU sur un coeur pendant 45 minutes avec 'pages_shared' qui stagne. Quelle est la cause racine et l'action corrective ?

Answer

A. ksm_run est a 1 mais pages_to_scan est trop bas ; augmenter /sys/kernel/mm/ksm/pages_to_scan a 10000 et reduire sleep_millisecs a 20

Answer

B. KSM est sature par le rescan complet ; activer KSMtuned avec KSM_THRES_COEF=20 dans /etc/ksmtuned.conf pour declencher dynamiquement selon la pression memoire

Answer

C. Le hugepage transparent (THP) en mode 'always' empeche KSM de fusionner les pages 2MB ; passer THP en 'madvise' via /sys/kernel/mm/transparent_hugepage/enabled

Answer

D. La NUMA balancing interfere avec KSM ; desactiver via sysctl kernel.numa_balancing=0 et redemarrer ksmd

Question 2

Dans un deploiement EVPN multi-DC sur Proxmox VE 9 reliant DC-Paris (AS 65001) et DC-Lyon (AS 65002) via un peering iBGP RR, vous observez que les MAC apprises dans DC-Paris ne sont pas propagees vers DC-Lyon. 'show bgp l2vpn evpn' montre les routes type-2 localement mais la session entre les RR montre 'Established' avec 0 prefixes envoyes. Quelle configuration FRR est manquante ?

Answer

A. La directive 'neighbor X.X.X.X route-reflector-client' dans 'address-family l2vpn evpn' du peer distant

Answer

B. L'activation de 'advertise-all-vni' sous 'address-family l2vpn evpn' sur les RR

Answer

C. Un peering eBGP au lieu d'iBGP car les ASN sont differents entre DCs

Answer

D. La configuration 'no bgp default ipv4-unicast' suivi de 'neighbor X.X.X.X activate' dans la famille l2vpn evpn

Question 3

Sur un noeud PVE 9 isole apres split, vous lancez 'pmxcfs -l' pour acceder a /etc/pve en ecriture locale. Apres modifications urgentes (correction d'un firewall.fw bloquant), le cluster est restaure. Au demarrage normal de pve-cluster, 'journalctl' affiche '[status] notice: cpg_send_message retry 10' puis '[status] notice: cpg_send_message retried 100 times' et finalement '[status] crit: cpg_send_message failed: 6'. Quel est le probleme et la resolution correcte ?

Answer

A. Les modifications locales sont en conflit avec l'etat cluster ; pmxcfs refuse la fusion. Solution : arreter pve-cluster, executer 'pmxcfs -l' a nouveau, exporter les modifs via 'sqlite3 config.db .dump > /tmp/local.sql', puis fusion manuelle apres demarrage normal

Answer

B. Corosync n'est pas pret a accepter les messages CPG ; verifier 'corosync-cfgtool -s' pour confirmer ring actif, 'corosync-quorumtool -s' pour quorum, et redemarrer pve-cluster une fois corosync stable (erreur 6 = CS_ERR_TRY_AGAIN)

Answer

C. Le mode local a corrompu les sequences CPG ; reinitialiser via 'rm /var/lib/pve-cluster/.pmxcfs.lock' et 'systemctl restart pve-cluster corosync' dans cet ordre strict

Answer

D. La taille des messages CPG depasse la limite (modifications volumineuses) ; augmenter 'net.core.rmem_max' a 16777216 via sysctl et ajouter 'totem { netmtu: 9000 }' dans corosync.conf

Question 4

Audit d'un cluster PVE 9 a 7 noeuds : 'corosync-cfgtool -n' sur pve04 affiche pour LINK 0 : 'enabled: 1, connected: 1, mtu: 1397' alors que les autres noeuds reportent 'mtu: 1397' egalement, mais 'pvecm status' montre des reconfigurations frequentes (membership change toutes les 2-3 minutes) avec 'Token Timeout: 6650 ms' dans les logs corosync. La latence ring0 mesuree est de 0.8ms moyenne avec spikes a 450ms. Quelle est l'optimisation correcte ?

Answer

A. Augmenter token timeout : editer /etc/pve/corosync.conf, section totem ajouter 'token: 10000' et 'token_retransmits_before_loss_const: 10', incrementer config_version, valider syntaxe via 'corosync-cfgtool -R' puis recharger sur tous les noeuds

Answer

B. La MTU 1397 indique une encapsulation (VXLAN/IPsec) ; forcer 'netmtu: 1500' dans totem et activer jumbo frames sur le switch pour eliminer la fragmentation cause des spikes

Answer

C. Migrer corosync vers un reseau dedie physique 10GbE sans QoS partagee ; les spikes a 450ms indiquent contention reseau, aucune modification de timeout ne resoudra durablement le probleme de stabilite cluster

Answer

D. Reduire le nombre de noeuds en sub-clusters : 7 noeuds depassent la recommandation Proxmox de 5 noeuds max sans QDevice ; restructurer en 2 clusters de 4 et 3 noeuds avec replication asynchrone

Question 5

Sur un bi-socket EPYC 9354 (2x32 cores, 8 NUMA nodes via NPS=4), vous deployez une VM critique avec GPU passthrough situe sur NUMA node 2. Quelle configuration QEMU/Proxmox optimise la latence memoire et l'acces DMA du GPU ?

Answer

A. cores: 32, sockets: 2, numa: 0, balloon: 0

Answer

B. cores: 16, sockets: 1, numa: 1 avec hostpci0 affecte au node correct + cpu affinity via taskset sur cores du node 2 + hugepages 1G prealloues sur ce node

Answer

C. cores: 64, numa: 1, hugepages: 2 (toutes pages, tous nodes)

Answer

D. cores: 16, numa: 1, cpu: host, balloon: 1024

Examen PVE9-ADMIN-50H — Examen Proxmox VE 9 — Niveau Difficile (50 questions)

À propos de l'examen PVE9-ADMIN-50H

Comment se préparer à l'examen PVE9-ADMIN-50H ?

5 exemples de questions — PVE9-ADMIN-50H

Encore 45 questions dans l'examen complet

📖 Préparez-vous avec nos guides

Commencer l'examen PVE9-ADMIN-50H complet