Accueil › Certifications › PVE9-L2 › Questions gratuites

Questions gratuites PVE9-L2 — Proxmox VE 9 Certified Administrator (Level 2)

Téléchargez gratuitement 96 questions d'entraînement pour la certification PVE9-L2 proposée par Proxmox. Toutes les questions sont accompagnées de corrections détaillées avec explications techniques.

Caractéristiques de l'examen blanc

Code de certificationPVE9-L2
ÉditeurProxmox
Nombre de questions96
TypeQCM avec 4 réponses possibles
Niveauassociate
CatégorieIT
Prix100% gratuit

Aperçu de 8 questions représentatives

Voici un échantillon aléatoire de 8 questions tirées de notre base d'entraînement PVE9-L2. Pour accéder aux 96 questions complètes, lancez l'examen blanc gratuitement.

Question 1
Un administrateur gère un cluster Proxmox VE de 4 nœuds avec 12 OSD Ceph au total. Il crée un pool RBD avec size=3 et min_size=2. Pendant une maintenance, 2 OSD tombent simultanément sur des nœuds différents. Quel est le comportement attendu du cluster concernant les données de ce pool ?
  1. Le pool passe en état dégradé mais reste accessible en lecture et écriture, car min_size=2 garantit que tant que 2 copies au moins existent pour chaque PG, les I/O sont autorisées ; Ceph lance automatiquement le recovery dès que possible
  2. Le pool est immédiatement mis en lecture seule pour protéger l'intégrité des données, car la perte de 2 OSD signifie que certains placement groups n'ont plus que 1 copie, ce qui est inférieur à size=3 et déclenche le mode protégé
  3. Le cluster suspend toutes les I/O sur le pool et attend le retour des OSD défaillants, car avec size=3 Ceph n'autorise aucune opération tant que les 3 réplicas ne sont pas disponibles pour chaque placement group
  4. Le pool reste pleinement fonctionnel sans dégradation visible, car 10 OSD restants sur 12 représentent plus de 80% de la capacité et la CRUSH map redistribue automatiquement et instantanément les données manquantes
Question 2
Dans un cluster Proxmox VE, une VM configurée en HA avec la politique 'migrate' subit une panne du nœud hôte. L'administrateur s'attend à une migration live mais constate que la VM a été redémarrée sur un autre nœud. Quelle est l'explication technique de ce comportement ?
  1. La politique 'migrate' tente une migration live lors d'une maintenance planifiée, mais lors d'une panne de nœud (node failure), le fencing force un reboot du nœud défaillant et la VM est redémarrée (restart) sur un nœud survivant car la migration live est impossible depuis un nœud hors service
  2. La politique 'migrate' a échoué car la bande passante réseau était insuffisante pour transférer la mémoire de la VM, et le HA Manager a basculé automatiquement vers la politique 'restart' comme mécanisme de fallback
  3. La politique 'migrate' ne s'applique qu'aux conteneurs LXC et non aux VM KVM, ce qui explique pourquoi le HA Manager a utilisé la politique par défaut 'restart' pour cette machine virtuelle QEMU
  4. La politique 'migrate' nécessite que le stockage soit en mode 'local-lvm' et non partagé, car la migration live repose sur la réplication locale des données via pvesr avant le basculement
Question 3
Un serveur Proxmox utilisant un pool ZFS de 8 disques en RAID-Z2 affiche des performances d'écriture dégradées. L'administrateur constate via 'zpool iostat -v 5' que les latences d'écriture dépassent régulièrement 50 ms. Les VMs hébergées exécutent principalement des bases de données PostgreSQL avec des écritures synchrones fréquentes. Quelle est la solution la plus appropriée ?
  1. Ajouter un périphérique SLOG (Separate Log) constitué d'un SSD NVMe à haute endurance en mirror pour accélérer les écritures synchrones du ZIL (ZFS Intent Log)
  2. Ajouter un périphérique L2ARC constitué d'un SSD NVMe pour mettre en cache les données fréquemment lues et ainsi libérer de la bande passante d'écriture sur les disques
  3. Activer la compression LZ4 sur le dataset avec 'zfs set compression=lz4 rpool/data' pour réduire le volume de données écrites sur les disques et améliorer les performances d'écriture
  4. Augmenter la valeur de 'zfs_txg_timeout' de 5 à 30 secondes pour regrouper davantage d'écritures dans chaque transaction group et réduire la fréquence des écritures sur les disques
Question 4
Suite à une restructuration, l'entreprise doit migrer plusieurs VMs d'un cluster Proxmox VE 9 (cluster-prod) vers un tout nouveau cluster Proxmox VE 9 (cluster-dr) situé dans un autre datacenter. Les deux clusters n'ont aucun lien corosync entre eux. Quelle est la méthode recommandée par Proxmox pour réaliser cette migration cross-cluster ?
  1. Utiliser la fonctionnalité 'Proxmox Remote Migration' disponible dans l'API Proxmox VE 9, qui permet de migrer des VMs entre clusters distincts en établissant une connexion API directe entre les nœuds source et cible via leurs certificats TLS
  2. Fusionner temporairement les deux clusters avec 'pvecm add' pour permettre la migration standard, puis séparer le nœud du cluster-dr avec 'pvecm delnode' une fois les VMs transférées
  3. Effectuer un vzdump des VMs sur le cluster source, transférer les fichiers de sauvegarde via SCP ou un stockage partagé NFS, puis les restaurer avec 'qmrestore' sur le cluster de destination
  4. Configurer une réplication ZFS cross-cluster avec 'pvesr create' en spécifiant l'adresse IP du nœud distant, puis basculer les VMs sur le cluster-dr une fois la synchronisation terminée
Question 5
Un administrateur doit configurer le HA pour une VM de base de données (VMID 200) qui utilise du passthrough PCI pour une carte RAID matérielle. La VM ne peut donc pas être migrée à chaud. Le groupe HA 'grp-db' contient node1 (priority 2) et node2 (priority 1). Quelle politique de récupération HA est la plus adaptée et pourquoi ?
  1. Configurer la ressource HA avec 'max_relocate: 1' et 'max_restart: 1', car la politique relocate effectue un arrêt propre puis redémarrage sur un autre nœud, compatible avec le passthrough PCI qui interdit la live migration
  2. Configurer la politique 'migrate' avec l'option '--online 0' pour forcer une migration à froid, ce qui suspend la VM, transfère l'état mémoire sans le périphérique PCI, puis reprend sur le nœud cible
  3. Désactiver le HA pour cette VM car le passthrough PCI est fondamentalement incompatible avec toute forme de haute disponibilité dans Proxmox VE, et utiliser un script de monitoring externe à la place
  4. Configurer la politique 'restart' uniquement avec 'max_restart: 5' pour garantir que la VM redémarre toujours sur le même nœud, car c'est la seule option qui préserve l'assignation PCI passthrough
Question 6
Une entreprise déploie un cluster Proxmox VE avec seulement 2 nœuds physiques pour des raisons budgétaires. L'architecte souhaite garantir la haute disponibilité même en cas de perte d'un nœud. Quelle est la solution recommandée pour résoudre le problème de quorum inhérent à un cluster de 2 nœuds ?
  1. Configurer un QDevice (corosync-qdevice) connecté à un serveur tiers externe léger sous Debian/Ubuntu qui agit comme un votant supplémentaire, permettant d'atteindre le quorum même avec un seul nœud actif
  2. Définir 'pvecm expected 1' de manière permanente dans la configuration corosync pour que chaque nœud puisse fonctionner indépendamment avec un seul vote suffisant pour le quorum
  3. Ajouter une interface réseau dédiée en ring1 dans corosync.conf avec le paramètre 'two_node: 1' qui active automatiquement un mécanisme de quorum adaptatif pour les clusters pairs
  4. Créer un troisième nœud virtuel Proxmox dans une VM sur un des deux nœuds physiques et le joindre au cluster pour fournir le troisième vote de quorum nécessaire
Question 7
Un administrateur souhaite tester le comportement du HA avant de déployer en production. Il dispose d'un cluster de test avec 4 nœuds. Quelle approche lui permet de simuler des scénarios de failover sans impacter les VM réelles ?
  1. Utiliser le HA Simulator intégré (pve-ha-simulator) qui simule le comportement du CRM et du LRM avec des ressources virtuelles, permettant de tester les politiques de failover, les groupes et les priorités sans cluster réel
  2. Créer des VM vides (sans disque) et les configurer en HA avec ha-manager set vm:<id> --state started, puis arrêter manuellement les nœuds un par un pour observer les migrations
  3. Utiliser la commande pvesh create /cluster/ha/simulate --scenario failover qui lance une simulation intégrée au cluster existant sans affecter les VM en production
  4. Activer le mode dry-run du HA Manager via ha-manager config --dry-run 1 qui enregistre dans les logs toutes les actions que le HA prendrait sans réellement exécuter les migrations
Question 8
Suite à une panne réseau isolant un nœud dans un cluster Proxmox VE de 3 nœuds, le mécanisme de fencing doit intervenir. L'administrateur constate que le watchdog logiciel (softdog) est utilisé par défaut. Quelle est la conséquence directe de ce mécanisme sur le nœud isolé et pourquoi est-il essentiel au fonctionnement du HA ?
  1. Le module softdog provoque un redémarrage forcé (hard reboot) du nœud isolé si le service ha-manager ne peut plus rafraîchir le watchdog, garantissant ainsi que le nœud ne conserve pas de locks sur les ressources HA
  2. Le watchdog softdog envoie un signal STONITH aux autres nœuds du cluster via corosync pour les informer de l'isolation, permettant ainsi une migration live des VM vers les nœuds restants
  3. Le softdog déclenche un arrêt gracieux (clean shutdown) du nœud isolé avec migration préalable des VM vers d'autres nœuds, assurant zéro temps d'indisponibilité pour les services HA
  4. Le watchdog softdog gèle les processus QEMU sur le nœud isolé en attendant le rétablissement de la connexion réseau, évitant ainsi toute corruption de données sur les disques partagés

Accédez aux 96 questions complètes gratuitement

Aucune carte bancaire requise. Examen chronométré, corrections détaillées, score final.

Lancer l'examen blanc PVE9-L2 →

Pourquoi s'entraîner avec Certifexpress ?