Configurer Proxmox

Dans la section précédente, vous avez installé Proxmox VE et accédé pour la première fois à son interface Web, à savoir l'écran de connexion qui s'affiche après un avertissement concernant un certificat auto-signé. Cette section transforme cette installation de base en une plateforme réellement prête pour les machines virtuelles : véritables mises à jour des paquets, pont réseau, stockage et optimisation de la mémoire, qui commence à jouer un rôle important dès lors que plusieurs machines virtuelles fonctionnent en parallèle.

Corriger les dépôts de paquets

Lors de la première connexion au nœud, un avertissement s'affiche avant toute autre chose : le référentiel d'entreprise est activé, mais aucun abonnement actif ne lui est associé ; par conséquent, toute opération portant sur les paquets de ce référentiel échoue.

Parce que c'est le choix par défaut le plus sûr. Le référentiel « enterprise » est celui qui a fait l'objet des tests les plus poussés parmi ceux fournis par Proxmox, et comme le programme d'installation n'a aucun moyen de savoir à l'avance si un serveur donné dispose ou non d'un abonnement, il active le même référentiel dans les deux cas et laisse à la personne chargée de la configuration du serveur le soin d'apporter la correction nécessaire.

La solution comporte en réalité deux étapes : la désactivation du référentiel d'entreprise seule ne fait qu'empirer les choses, car elle laisse le nœud sans aucun référentiel Proxmox activé.

Le bouton « Ajouter » sur ce même écran apporte la solution qui manquait : le référentiel sans abonnement, conçu précisément pour ce genre de situation.

Une fois le dépôt sans abonnement ajouté, l'état du nœud passe d'un simple avertissement à une combinaison qu'il est utile d'apprendre à reconnaître : les mises à jour fonctionnent désormais, mais un rappel indique que ce dépôt n'est pas celui recommandé par Proxmox pour un cluster de production.

Mettre à jour le système

Une fois le dépôt opérationnel mis en place, le panneau « Mises à jour » peut effectivement actualiser la liste des paquets au lieu d'afficher directement un échec. Il est utile de consulter au moins une fois le journal des tâches correspondant à cette actualisation, car il indique précisément quels dépôts ont répondu et lesquels n'ont pas répondu.

À partir de là, le bouton « Mise à jour » situé sur le même écran lance la mise à jour effective du paquet, soit la même opération que apt full-upgrade en ligne de commande. En l'exécutant juste après une nouvelle installation, avant la création de toute machine virtuelle, cela signifie qu'un redémarrage suite à une mise à jour du noyau lui-même n'interrompra encore rien de concret.

Présentation du pont réseau

Le programme d'installation a déjà créé une configuration d'interface réseau en plus de la carte physique : vmbr0, un pont Linux superposé à la carte physique nic0 et contenant l'adresse IP de gestion définie lors de l'installation.

En effet, une carte réseau physique ne peut être connectée qu'à un seul endroit à la fois. Un pont fonctionne plutôt comme un petit commutateur virtuel : la carte réseau physique s'y connecte d'un côté, tandis que les interfaces réseau virtuelles de chaque machine virtuelle s'y connectent de l'autre côté, chacune disposant de sa propre adresse MAC et pouvant envoyer et recevoir du trafic sur la même liaison physique de manière indépendante.

Il s'agit également du pont auquel la section IPv4 configurée plus loin dans ce guide attribuera une deuxième adresse ; il n'y a donc pour l'instant rien d'autre à modifier ici, il suffira de le reconnaître lorsqu'il réapparaîtra.

Examen du stockage

Juste après l'installation, deux entrées de stockage existent ; toutes deux se trouvent sur le même disque choisi lors de la configuration, mais ont des fonctions différentes.

Optimisation de la mémoire et du processeur en fonction de la densité des machines virtuelles

Deux paramètres déterminent le nombre de machines virtuelles pouvant réellement tenir dans la mémoire vive (RAM) de ce serveur, et aucun des deux n’est configuré par le programme d’installation spécifiquement pour une charge de travail d’hébergement, car celui-ci n’a aucun moyen de savoir à quoi sert la machine.

Activer la déduplication de la mémoire avec KSM

La fonctionnalité « Kernel Samepage Merging » (KSM) permet à plusieurs machines virtuelles exécutant le même système d'exploitation invité de partager des pages mémoire, au lieu que chacune conserve sa propre copie d'un contenu en grande partie identique. Proxmox gère cette fonctionnalité via un démon d'optimisation, ksmtuned, qui surveille la charge mémoire et n'active la fusion effective que lorsque cela s'avère utile.

Sur un nœud fraîchement installé sur lequel aucune machine virtuelle n'est encore en cours d'exécution, ce démon est actif mais inactif ; il vaut mieux s'en assurer directement plutôt que de partir d'une hypothèse.

Ces zéros ne signifient pas qu’il y a une erreur de configuration ; il s’agit de l’état normal sur un hôte qui n’est soumis à aucune pression mémoire. Dès qu'il existe plusieurs machines virtuelles exécutant le même système d'exploitation, ksmtuned bascule automatiquement sur la valeur 1 et le paramètre pages_shared commence à augmenter, le tout sans aucune intervention manuelle ; les seuils de réglage eux-mêmes se trouvent dans /etc/ksmtuned.conf même s'il faudra peut-être les ajuster par la suite, les paramètres par défaut constituent un bon point de départ pour une première plateforme.

Réduire le Swappiness et vérifier le microcode du processeur

Le paramètre « swappiness » détermine la propension du noyau à transférer de la mémoire vers l’espace d’échange plutôt que de la conserver en RAM. La valeur par défaut de Debian, fixée à 60, a été choisie pour un ordinateur de bureau polyvalent, bien avant l’apparition de plusieurs machines virtuelles nécessitant chacune leur propre mémoire vive. Il suffit d’une seule commande pour vérifier cette valeur directement, ainsi que le microcode du processeur actuellement chargé.

Une valeur plus faible empêche le noyau de déporter la mémoire d'une machine virtuelle au simple motif qu'elle n'a pas été sollicitée au cours des dernières secondes, ce qui revêt une importance particulière dans le contexte d'un hyperviseur : une machine virtuelle déportée donne l'impression d'être bloquée à l'utilisateur. Pour enregistrer ce paramètre dans un fichier situé sous /etc/sysctl.d/ ce qui lui permet de perdurer après un redémarrage, plutôt que d'être une valeur ponctuelle qui se réinitialise d'elle-même.

Il vaut mieux comprendre ces deux extrêmes plutôt que de choisir un chiffre au hasard. Avec un paramètre « swappiness » de 60, le noyau commence à recourir au swap de manière proactive bien avant que la mémoire vive ne soit réellement épuisée, sacrifiant un peu de performances du cache de fichiers au profit d’une marge de manœuvre dont un ordinateur de bureau a rarement besoin ; sur un hôte exécutant des machines virtuelles, ce même swap proactif peut discrètement déporter en swap une machine virtuelle qui est simplement restée inactive un instant, et le système d'exploitation invité de cette machine virtuelle n'a aucune idée de ce qui s'est passé ; il a simplement l'impression d'être lent. Avec un paramètre swappiness à 0, le noyau évite presque totalement l’utilisation de l’espace d’échange et s’appuie plutôt sur le « out-of-memory killer » lorsque la mémoire vive est véritablement épuisée, ce qui constitue une défaillance plus grave qu’un peu d’échange ne l’aurait été. Une valeur faible mais non nulle, 10 dans le cas présent, permet de conserver l’espace d’échange comme filet de sécurité en cas d’épuisement réel de la mémoire, sans pour autant y recourir en premier lieu.

Sur ce serveur, la vérification du paquet de microcode Intel a confirmé qu'il s'agissait déjà de la dernière version disponible, puisque l'installation de base de Debian l'inclut déjà : rien à installer, ce qui constitue en soi une information utile plutôt qu'une étape superflue. Le microcode est en soi un firmware destiné au processeur, qui corrige les bogues matériels réels détectés par Intel ou AMD après la commercialisation d’une puce donnée ; certains concernent uniquement l’exactitude du fonctionnement, d’autres ont un impact sur la sécurité ; un serveur acheté d’occasion, conformément aux conseils de la première partie, peut être resté dans un entrepôt ou avoir fonctionné sans être touché pendant des années entre deux propriétaires, suffisamment longtemps pour que plusieurs de ces correctifs s’accumulent sans avoir été appliqués. L’exécution de cette commande ne coûte rien, quelle que soit la situation, et c’est le seul moyen d’en avoir la certitude plutôt que de supposer qu’une machine d’occasion est à jour.

Créer un compte administrateur sans droits de root

Jusqu'à présent, toutes les captures d'écran de ce guide ont utilisé le compte root, ce qui convient parfaitement pendant la première heure de configuration d'un serveur, mais ne doit pas devenir une habitude quotidienne une fois que la plateforme est opérationnelle.

Cela fonctionne, mais la fuite d'un seul mot de passe root suffit alors à donner un contrôle total sur l'ensemble de la plateforme, sans compte distinct à désactiver ni connexion distincte à vérifier dans le journal des tâches. Un compte administrateur dédié permet de remédier à ce problème sans perdre aucune des fonctionnalités offertes par le compte root.

Pour en ajouter un, il faut commencer par faire un choix qui n'est pas évident la première fois : à quel domaine appartient le compte ? Un compte PAM sous Linux nécessite qu’un véritable utilisateur Unix existe déjà sur le serveur ; un compte du serveur d’authentification Proxmox VE, appelé « pve » en abrégé, n’existe qu’au sein même de Proxmox, avec son propre mot de passe, et ne nécessite aucune configuration sur le système d’exploitation sous-jacent.

Pour un compte administrateur qui n'utilise que l'interface web, le realm « pve » est le choix le plus simple, et c'est celui qui apparaît dans la liste des utilisateurs juste après sa création. Il convient toutefois de préciser clairement l'inconvénient plutôt que de le passer sous silence : un compte PAM, puisqu’il correspond à un véritable utilisateur Unix, peut également se connecter au serveur via SSH et obtenir un véritable shell, tout comme l’utilisateur root, tandis qu’un compte du domaine pve existe uniquement au sein du système d’authentification propre à Proxmox et ne dispose d’aucun accès au shell, quel que soit le rôle qui lui est attribué dans l’interface web. Pour un compte destiné à gérer des machines virtuelles et le stockage via le navigateur, et rien d’autre, ce n’est pas une limitation, mais exactement la restriction qu’il convient d’imposer : la perte du mot de passe de ce compte ne donne jamais accès à un shell de connexion sur le système d’exploitation sous-jacent, contrairement à ce qui se passerait si un compte PAM était compromis.

Attribuez-lui un rôle

Un utilisateur nouvellement créé dans Proxmox ne dispose au départ d'aucun accès ; le simple fait d'exister ne signifie pas pour autant qu'il soit autorisé à effectuer des actions, et c'est précisément ce que permet de gérer la section « Autorisations » du centre de données. Une autorisation associe un chemin d'accès dans l'arborescence des ressources à un utilisateur et à un rôle.

Chemin d'accès / désigne l'arborescence complète des ressources, c'est-à-dire l'ensemble des machines virtuelles et des espaces de stockage ; l'option « Propager », cochée par défaut, étend ce même rôle à tous les éléments situés sous ce chemin, qu'ils existent déjà ou qu'ils soient créés ultérieurement. Il en résulte un compte disposant de la même portée que « root », connecté sous son propre nom.

Le rôle « Administrateur » est le plus général qui soit ; c'est le choix idéal pour le compte personnel d'un utilisateur travaillant seul, mais ce n'est pas la seule forme que peuvent prendre les autorisations dès lors que cette plateforme cesse d'être un projet mené par une seule personne. Proxmox propose également des rôles intégrés plus restreints : PVEVMAdmin pour une personne chargée uniquement de gérer les machines virtuelles sans intervenir sur le stockage ni les utilisateurs, et PVEAuditor pour un accès en lecture seule sans aucune possibilité de modification ; la même boîte de dialogue « Ajouter : Autorisation utilisateur » accepte n'importe lequel d'entre eux à la place d'« Administrateur », et le chemin d'accès ne doit pas nécessairement être la racine. / ni l'un ni l'autre ; en limitant cette autorisation au chemin d'accès propre à une seule machine virtuelle, on restreint ainsi cette autorisation à cette machine virtuelle uniquement, et à rien d'autre. Tout cela n'est pas encore nécessaire lorsqu'il n'y a qu'un seul compte administrateur sur un seul nœud, mais le mécanisme est le même que celui qui, par la suite, distingue ce à quoi un opérateur en contact avec les clients a accès de ce qui est réservé exclusivement au propriétaire de la plateforme.

Activer l'authentification à deux facteurs

Proxmox prend en charge quatre méthodes d'authentification à deux facteurs : les codes TOTP générés par une application d'authentification, les clés matérielles WebAuthn, les clés de récupération à usage unique et Yubico OTP ; la méthode TOTP ne nécessitant aucun achat supplémentaire, c'est donc naturellement celle qu'il convient de configurer en premier.

C'est en scannant ce code dans une application d'authentification et en saisissant les six chiffres qu'elle génère que la configuration est effectivement validée ; Proxmox n'activera pas l'authentification à deux facteurs (TFA) sur un compte tant qu'un code valide n'aura pas confirmé que le mot de passe secret fonctionne.

Une question à laquelle il vaut mieux réfléchir avant que cela ne devienne urgent : que se passe-t-il si le téléphone sur lequel est installée cette application d’authentification est perdu, réinitialisé ou simplement à court de batterie au mauvais moment ? C’est précisément à cela que servent les clés de récupération, l’un des trois autres types d’authentification multifactorielle : il s’agit d’un ensemble de codes à usage unique générés à l’avance et stockés ailleurs que sur le téléphone lui-même, chacun pouvant être utilisé une seule fois pour se connecter sans avoir besoin de l’application TOTP. Sans méthode de récupération configurée à l’avance, la perte du seul appareil TOTP bloque complètement l’accès à ce compte jusqu’à ce qu’un autre compte administrateur, ou le compte root lui-même, supprime l’entrée TFA depuis l’écran « Authentification à deux facteurs » présenté précédemment.

Activer le pare-feu

Proxmox intègre un pare-feu complet, désactivé par défaut à tous les niveaux, aussi bien au niveau des nœuds que des machines virtuelles. Avant de l'activer, il est utile de prendre le temps de lire ses règles par défaut, car celles-ci déterminent ce qui se passe dès qu'il est activé.

Deux autres paramètres de ce même écran prennent davantage d’importance dès lors que des machines virtuelles entrent en jeu qu’à l’heure actuelle. ebtables, activé par défaut, effectue le filtrage au niveau du pont réseau lui-même plutôt que simplement au niveau de la pile réseau de l’hôte, ce qui permet par la suite de filtrer le trafic propre à une machine virtuelle même si, techniquement, celui-ci n’atteint jamais la chaîne d’entrée de l’hôte ; c’est également la raison pour laquelle la « Forward Policy » (politique de transfert) existe en tant que paramètre distinct de la « Input Policy » (politique d’entrée) : le trafic transitant par l’hôte à destination ou en provenance d’une machine virtuelle est considéré comme « transféré » plutôt que comme « entrant », et les deux sont évalués selon des ensembles de règles totalement différents. Une règle écrite pour le port de gestion doit être placée sous « Input » ; une règle destinée à filtrer ce qu’une VM peut elle-même envoyer ou recevoir doit être placée ailleurs, un détail qui ne prendra toute son importance qu’une fois que la première VM de la partie 3 existera réellement.

Pour ajouter une règle dans l'interface Web, il faut indiquer à la fois un protocole et un port ; si l'on laisse le champ « Protocole » vide tout en définissant un port de destination, l'opération échoue immédiatement. Il s'agit là d'une véritable erreur qu'il vaut mieux connaître à l'avance plutôt que de devoir la dépanner à froid.

Se tromper dans une règle une fois que le pare-feu est déjà activé n’est pas une erreur aussi irréversible qu’elle en a l’air, car la console physique ou virtuelle utilisée dans ce guide au chapitre consacré à l’installation ne passe jamais par le pare-feu réseau ; il s’agit d’une session de console directe qui contourne entièrement la pile réseau, de sorte qu’elle reste accessible même si la politique d’entrée bloque tous les ports. Une modification de règle ou une suppression pure et simple pve-firewall stop Comme indiqué plus haut, il existe toujours un moyen de se reconnecter, ce qu'il est bon de garder à l'esprit avant de considérer un blocage par le pare-feu comme un problème nécessitant une réinstallation complète.

Automatisation des certificats avec ACME

L'avertissement concernant le certificat auto-signé évoqué dans la section précédente n'est pas nécessairement définitif. Proxmox intègre la prise en charge du protocole ACME, le même que celui utilisé par Let's Encrypt, et peut demander et renouveler un véritable certificat de manière autonome dès lors qu'il est associé à un véritable domaine public.

Deux répertoires sont disponibles, et il est important de bien comprendre la différence entre les deux avant de faire son choix.

• Let's Encrypt V2 : émet des certificats réels et fiables, et comptabilise chaque tentative dans les limites de débit publiques de Let's Encrypt. À n'utiliser que lorsque l'on est certain que la configuration fonctionnera.
• Environnement de test Let's Encrypt V2 : émet des certificats auxquels les navigateurs ne font pas confiance, mais avec des limites bien plus élevées, spécialement conçus pour tester la configuration sans épuiser le quota réel.

Pour mener à bien cette étape dans la pratique, il faut disposer d’un domaine qui pointe effectivement vers ce serveur depuis l’Internet public, ce qui est rarement le cas dans un environnement de laboratoire ou un laboratoire personnel ; l’enregistrement du compte décrit ci-dessus constitue la limite de ce guide, le reste se mettant en place naturellement dès qu’un véritable domaine est pointé vers un véritable déploiement.

Il est utile de comprendre en quoi consiste exactement cette étape, même sans la détailler ici. Let's Encrypt doit vérifier que le serveur demandant un certificat contrôle bel et bien le domaine concerné, et il le fait à l'aide d'un test : pour la méthode courante HTTP-01, Proxmox met brièvement à disposition un fichier spécifique à une URL précise sous ce domaine sur le port 80, et les serveurs de Let's Encrypt le récupèrent pour confirmation ; ce n’est qu’alors que le certificat est délivré. Cela a une conséquence directe sur la section relative au pare-feu ci-dessus, car un hôte dont le pare-feu est activé et sur lequel seul le port 8006 est autorisé échouerait d’emblée à ce test de vérification ; le port 80 doit donc également être accessible, au moins pendant la durée de la requête. Une fois le certificat émis, Proxmox vérifie lui-même sa date d’expiration et le renouvelle automatiquement bien avant l’expiration de la validité de 90 jours des certificats Let’s Encrypt, en consignant tout échec dans le journal des tâches plutôt que de laisser silencieusement un certificat expiré en place en cas de problème.

Configurer des notifications réelles

L'adresse e-mail saisie lors de l'installation a déjà une utilité : Proxmox configure par défaut une destination de notification appelée « mail-to-root », ainsi qu'un filtre qui achemine toutes les notifications vers celle-ci, avant même que l'on ait eu à effectuer la moindre configuration manuelle.

Le fait que les cibles et les conditions de correspondance soient des éléments distincts, plutôt qu’un paramètre unique, est intentionnel : une cible définit uniquement où une notification peut être envoyée, tandis qu’une condition de correspondance détermine quelles notifications y sont effectivement envoyées. Le « default-matcher » présenté ci-dessus achemine tout vers « mail-to-root » car il ne comporte aucune condition de filtrage, mais un « matcher » peut tout aussi facilement se baser sur la gravité ou le type d’événement, en envoyant uniquement les sauvegardes ou les tâches de réplication ayant échoué vers un webhook qui alerte quelqu’un, tandis que les notifications de réussite courantes restent dans les e-mails, auxquelles personne n’a besoin de réagir en temps réel. C’est cette distinction qui empêche une plateforme en pleine croissance de noyer la boîte de réception sous un flot de notifications de routine ou, pire encore, d’étouffer la seule notification qui nécessitait réellement une réponse.

Pour tout ce qui va au-delà du courrier électronique, une cible de webhook prend en charge la plupart des piles d'alerte existantes : une URL, une méthode, des en-têtes personnalisés et un corps de message, les informations sensibles telles que les jetons d'authentification étant conservées dans un champ dédié plutôt que d'apparaître en clair dans le corps du message.

Passer en revue les options relatives au centre de données et aux nœuds

Quelques paramètres qui n'ont pas leur place ailleurs dans l'interface se trouvent sous « Datacenter », « Options » ; la plupart d'entre eux sont configurés une seule fois lors de l'installation et ne sont ensuite que rarement modifiés.

Une ligne mérite qu'on s'y attarde : le préfixe d’adresse MAC, BC:24:11 par défaut, est celui par lequel commence chaque interface réseau d’une machine virtuelle générée automatiquement ; c’est ce qui permet, lors d’une capture de paquets sur un réseau partagé, de distinguer le trafic d’une machine virtuelle Proxmox de tout autre trafic sur le réseau. Sur un réseau où plusieurs hyperviseurs de différents fournisseurs partagent le même commutateur, ce préfixe constitue souvent le moyen le plus rapide de déterminer « de quelle machine provient réellement ce trafic » sans avoir à recouper d'autres informations, car tous les principaux fournisseurs d'hyperviseurs enregistrent et utilisent leur propre préfixe distinct de la même manière.

Une deuxième optimisation de la mémoire vive intervient au niveau des nœuds, en complément de la valeur par défaut de 80 % définie pour le « ballooning » : il s’agit de la quantité cible de mémoire vive allouée à une machine virtuelle que le pilote « balloon » tente de garder effectivement réservée, en restituant le reste à l’hôte en cas de pression sur la mémoire, le même type de pression qui déclenche également le KSM.

Le « ballooning » ne fonctionne toutefois que si le système d'exploitation invité y coopère, ce qui est facile à supposer, mais erroné de le faire aveuglément. Ce mécanisme repose sur un pilote s'exécutant au sein même de la machine virtuelle, le pilote « balloon », généralement installé aux côtés de l'agent invité QEMU sur les systèmes invités Linux et Windows modernes. Ce pilote gonfle un « ballon » constitué de pages de mémoire que le système d'exploitation invité s'engage à ne pas utiliser, les libérant ainsi au profit de l'hôte. Une machine virtuelle dépourvue de ce pilote, en particulier si elle héberge un système d’exploitation invité ancien ou minimaliste, ne participe tout simplement pas : l’hôte peut en faire la demande, mais aucune mémoire ne lui est restituée. Sur une plateforme exécutant un mélange de systèmes d’exploitation invités, l’efficacité réelle du « ballooning » finit par être limitée par les machines virtuelles les moins coopératives, quel que soit l’objectif de 80 % fixé ici.

Créer un jeton API pour l'automatisation

Pour créer des scripts utilisant l'API de Proxmox sans avoir à saisir de mot de passe dans le script, il faut commencer par un jeton, lié à un utilisateur mais distinct de ses identifiants de connexion.

Le secret n'apparaît qu'une seule fois, juste après la création, et c'est justement là tout l'intérêt : rien dans cette conception ne permet de le récupérer par la suite ; il ne peut être que régénéré sous la forme d'une nouvelle valeur.

C'est précisément cette séparation par rapport au mot de passe de l'utilisateur qui fait des jetons un outil véritablement utile pour l'automatisation, plutôt qu'une simple formalité administrative. Si le secret de ce jeton se retrouve là où il ne devrait pas être, par exemple s'il est intégré par erreur dans un script puis poussé vers un dépôt, la solution consiste à supprimer ou à régénérer ce jeton spécifique dans la liste des jetons API ; le mot de passe de l’administrateur des opérations, ses propres sessions de connexion et sa configuration d’authentification à deux facteurs (TFA) ne sont absolument pas affectés par cet incident, puisque le jeton n’a jamais partagé d’identifiants avec le compte auquel il appartient. En revanche, la fuite d’un mot de passe utilisateur implique de réinitialiser ce mot de passe et, potentiellement, toutes les sessions qui y sont liées. La séparation des privilèges renforce encore davantage cette isolation : même un jeton dont le secret a été entièrement divulgué reste limité aux autorisations restreintes qui lui ont été explicitement accordées, ce qui représente un périmètre d’impact bien plus restreint que celui du compte complet d’opsadmin.

Vérifier le DNS, les fichiers hosts et l'état du disque

Quelques vérifications mineures viennent compléter cette nouvelle installation ; elles passent inaperçues et on a tendance à les ignorer sans se rendre compte de leur importance.

Un hôte à nœud unique, qui ne communique encore avec aucun autre serveur, peut donner l’impression que le DNS n’a guère d’importance, mais celui-ci effectue déjà un véritable travail chaque fois que ce nœud accède à quelque chose par son nom plutôt que par son adresse IP brute. Le référentiel sans abonnement récupéré par nom d’hôte lors de l’étape de mise à jour de la partie 2, un pool NTP utilisé pour maintenir la précision de l’horloge, un futur deuxième nœud rejoignant le cluster via son propre nom d’hôte plutôt que son adresse IP : tout cela dépend du bon fonctionnement du serveur DNS configuré ici. Un serveur DNS incorrect ou inaccessible à cet endroit est une cause fréquente et source de confusion d’une apt update rencontre un problème qui semble être d'ordre réseau, alors que le réseau fonctionne correctement et que seule la résolution des noms est défaillante.

Le fichier hosts propre au nœud peut être modifié directement depuis l'interface, et la ligne à vérifier est l'entrée correspondant au serveur lui-même : son adresse IP est associée au nom de domaine complet (FQDN) défini lors de l'installation, ce qui permet à ce nom d'hôte d'être résolu automatiquement sans dépendre du tout d'un DNS externe.

Cette entrée manuelle est plus importante qu'il n'y paraît, car les outils internes de Proxmox dépendent eux aussi d'une résolution correcte de ce nom d'hôte, au même titre que toute ressource externe. Si cette ligne venait à être modifiée ou supprimée par inadvertance, les symptômes ne ressembleraient pas forcément à ceux d’un problème lié au fichier hosts ; certains appels d’API internes ou, par la suite, la communication au sein du cluster entre les nœuds pourraient commencer à échouer d’une manière qui ressemblerait d’abord à un problème de réseau ou de certificat, alors que la cause réelle, bien plus simple, serait en réalité une entrée manquante ou erronée dans le fichier hosts.

La section « État des disques » se trouve sous « Disques » ; à côté de chaque périphérique répertorié figure un bouton « Afficher les valeurs S.M.A.R.T. ». Sur du matériel physique équipé de disques réels, elle permet de visualiser les secteurs réaffectés, le niveau d'usure et le nombre d'heures de fonctionnement bien avant qu'un disque ne tombe réellement en panne.

Sur ce disque virtuel, ce même bouton ne renvoie absolument rien, ce qui est normal et ne constitue pas un dysfonctionnement : un disque virtuel ne présente en effet aucune usure physique à signaler.

Sur du matériel réel, il vaut mieux bien comprendre ce tableau plutôt que de s’en contenter d’un simple coup d’œil, car quelques-uns de ses attributs seulement fournissent la quasi-totalité des informations utiles. Si le nombre de secteurs réaffectés dépasse zéro, cela signifie que le disque a déjà commencé à mettre discrètement hors service les secteurs défectueux et à les remapper vers des secteurs de réserve ; il s’agit là d’un signal d’alerte précoce, norme dans le secteur, qui apparaît bien avant que le disque ne tombe définitivement en panne ; le nombre d’heures de fonctionnement donne une indication claire de la durée de vie qu’un disque d’occasion a déjà parcourue avant même d’arriver sur ce serveur. Compte tenu du conseil donné dans la partie 1 d’acheter du matériel d’entreprise d’occasion, les disques hérités avec ce serveur peuvent déjà présenter un nombre d’heures réel et une usure réelle issue d’une utilisation antérieure, ce qui justifie de consulter ce tableau une fois, juste après l’installation, plutôt que de supposer qu’une mention « reconditionné » signifie que les disques ont également été remplacés.