La partie 13 a rendu le cluster utilisable, avec des noms qui résolvent et des certificats valides. Avant de reprendre le fil logiciel, une pause côté matériel : un nouvel occupant vient de s’installer dans la baie du homelab, le GL.iNet Comet X (GL-RM4PE), un KVM sur IP à quatre ports, alimenté en PoE.
Petit changement de programme au passage : la fin de la partie 13 annonçait le rack 10 pouces imprimé en 3D pour la suite. Il arrive finalement juste après et il se peut que quelques photos de cet article le spoilent un peu. Promis, il aura droit à son article dès la prochaine partie. Pour l’instant, place au KVM.
Transparence avant tout : cet article est le fruit d’un partenariat avec GL.iNet, le deuxième après celui avec Teltonika Networks en partie 4. Concrètement, j’ai reçu le Comet X présenté ici gratuitement. Je ne suis pas rémunéré par la marque et je n’ai aucune obligation de résultat. Je reste donc totalement libre de mon discours : je vais vous parler aussi bien des bons côtés que des points qui, selon moi, méritent d’être améliorés. Merci à GL.iNet pour l’envoi et pour la confiance, mais la règle ne change pas : je dis ce que je pense.
Au programme : le déballage, le premier démarrage, la mise à jour du firmware, un tour des réglages, la configuration de base, le montage dans le rack et le branchement des quatre machines. Puis un vrai test de terrain : réveiller un nœud par Wake-on-LAN. Ça n’a pas marché du premier coup et c’est tant mieux, parce que c’est ce qui a permis de montrer à quoi sert vraiment ce boîtier.
Le fil rouge de cette partie : reprendre la main sur une machine sans écran ni clavier. Quand le réseau ou l’OS ne répondent plus, le SSH ne sert plus à rien. Le KVM, lui, reste là : c’est le filet de sécurité du homelab.
Un KVM sur IP, c’est quoi ?#
Si vous arrivez directement ici, un peu de contexte. KVM veut dire Keyboard, Video, Mouse : clavier, écran, souris. Un KVM sur IP, c’est un boîtier qui capture la sortie vidéo d’une machine (ici en HDMI), se fait passer auprès d’elle pour un clavier et une souris USB et transporte tout ça sur le réseau. Depuis un simple navigateur, on voit l’écran de la machine et on la pilote comme si on était assis devant.
La grosse différence avec le SSH, c’est que le KVM ne dépend pas du système de la machine pilotée. Il voit le BIOS, le menu de démarrage, l’installeur, un kernel panic ou une interface réseau mal configurée. Bref, tout ce qui se passe avant que l’OS soit en état de vous répondre, ou après qu’il a cessé de le faire. J’avais déjà présenté le principe en partie 7, avec mon premier KVM.
Pourquoi changer de KVM#
Ce premier KVM, c’est le JetKVM. Il apparaissait dès la partie 5 et la partie 7 lui consacrait un aparté complet : c’est lui qui m’a permis de monter les ISO de Proxmox à distance, de piloter le BIOS des OptiPlex et d’y garder un accès console pendant la bataille du boot UEFI.
Seulement, le JetKVM, c’est un seul port : une machine à la fois. Pour passer d’un nœud à l’autre, il fallait le débrancher et le rebrancher sur le suivant. Tant que les OptiPlex étaient empilés sur un bureau, ça restait jouable. Dans un rack, aller à l’arrière déplacer un dongle, c’est précisément le genre de geste qu’un KVM est censé vous éviter.
Le Comet X change la donne : quatre machines branchées en permanence et on passe de l’une à l’autre depuis le navigateur. Comme son prédécesseur, il prend ses entrées vidéo en HDMI. Or, comme je le racontais en partie 7, pbs01 (l’OptiPlex 9020) ne sort qu’en DisplayPort et VGA. Rien de dramatique : prévoir aussi du DisplayPort sur chaque port serait franchement excessif et le boîtier deviendrait énorme. Un adaptateur fera très bien l’affaire pour cette seule machine, j’y reviens plus bas.
Le JetKVM, lui, part sur le banc de touche pour l’instant. Il trouvera peut-être une nouvelle place dans la baie principale, sur le Raspberry Pi qui fait tourner Home Assistant. Je verrai.
La fiche technique#
Pour toutes les infos, je vous renvoie vers la page produit de GL.iNet.
| Élément | Valeur |
|---|---|
| Modèle | Comet X (GL-RM4PE) |
| CPU | ARM Cortex-A53 quatre cœurs |
| Mémoire / stockage | 1 Go DDR3L / 64 Go eMMC (dépôt d’images ISO intégré) |
| Vidéo | 4 entrées HDMI, 1 sortie HDMI (passthrough), jusqu’à 4K à 30 i/s |
| Latence annoncée | 30 à 60 ms, sur le réseau local (P2P) |
| USB | 4 ports USB-C “device” (vers les machines), 3 USB-A en façade (clavier, souris locaux), 4 USB-A à l’arrière (accessoires) |
| Réseau | 1 port Ethernet 1 Gb/s, PoE 802.3af/at |
| Alimentation | PoE, ou USB-C 5 V / 3 A (PD) en secours, bascule automatique si le PoE disparaît |
| Écran | tactile TFT 3,69 pouces (état, IP, aperçu de l’écran) |
| Dimensions / poids | 170 x 90 x 40 mm, 560 g |
| Montage rack | compatible 10 et 19 pouces, équerres des deux tailles fournies |
| Contrôle d’alimentation | Wake-on-LAN intégré, jusqu’à 4 cartes ATX ou Fingerbots |
| Accès distant | navigateur, app GL KVM, Tailscale, ZeroTier, Netbird |
Trois lignes ont retenu mon attention en pensant à la série. Le montage 10 pouces avec équerres fournies, pour le rack imprimé que je vous présente dans la prochaine partie. Le PoE (Power over Ethernet, l’alimentation électrique transmise par le câble réseau), que le switch UniFi de la baie sait fournir. Et Netbird dans la liste des accès distants : c’est justement le VPN prévu pour accéder au homelab de l’extérieur.
Étape 1 : le déballage#
Dans la boîte on retrouve :
- le Comet X
- deux équerres pour rack 10 pouces (les courtes) et deux pour rack 19 pouces (les longues), avec leur visserie
- 4 câbles HDMI de 1 m
- 4 câbles USB-C vers USB-A de 1 m, USB-C côté Comet X, USB-A côté machine
- 1 câble Ethernet
C’est franchement très appréciable : de quoi brancher les quatre machines et monter le boîtier dans une baie, quelle que soit sa largeur, sans rien racheter.
À l’arrière, le boîtier s’organise en quatre groupes identiques, un par machine : un port USB 2.0 pour les accessoires, un USB-C pour le clavier et la souris émulés et une entrée HDMI. À droite, la sortie HDMI, l’USB-C d’alimentation de secours (5 V / 3 A) et le port RJ45 PoE.
Étape 2 : premier démarrage et code PIN#
Pour l’alimentation, un seul câble suffit : le Comet X est branché sur le port 4 du switch de la baie, configuré dans le VLAN du lab. Le PoE fait le reste, pas de bloc secteur supplémentaire à caser.
Au démarrage : l’horloge de l’écran affiche fièrement 00:00, le 1er janvier 1970. C’est l’origine des temps pour un système Unix, l’heure qu’on obtient tant que la synchronisation NTP n’a pas eu lieu. Elle se recale toute seule dès que le boîtier joint le réseau.
L’écran tactile demande ensuite de définir un code PIN d’administration à quatre chiffres, saisi directement sur la façade.
Sur le côté, un bouton physique a deux usages : un appui change de source, un appui de 8 secondes réinitialise le boîtier. Bon à savoir, parce qu’en cas de besoin de réinitialisation, ce n’est indiqué nulle part ailleurs.
L’écran affiche l’adresse obtenue en DHCP : 192.168.3.16. Direction le navigateur : on définit le mot de passe de l’interface web et on arrive sur GLKVM, l’application web du boîtier.
L’interface s’organise autour de quelques menus (Settings, Toolbox, Accessories, Virtual Media, Apps Center, Help), d’un sélecteur de port et d’une vue plein écran. Sans machine branchée, la vidéo affiche “No HDMI signal detected”, avec un flux WebRTC H.264 en 1920x1080 et une connexion en P2P. En haut à droite, le firmware d’origine, V1.8.1 release2, porte déjà une pastille “new version available”.
Étape 3 : la mise à jour du firmware#
La fenêtre de mise à jour propose la V1.10.1 release4, marquée “Latest Version Release”. L’option “Save current configuration” est cochée par défaut et un lien “Local Upgrade” permet d’installer un fichier téléchargé à la main.
Les nouveautés annoncées sont copieuses :
- la vidéo bidirectionnelle ;
- un mode WebRTC (Native), basé sur la bibliothèque WebRTC de Google ;
- un tableau de bord de latence, de gigue et d’autres métriques temps réel ;
- un gestionnaire des périphériques USB émulés ;
- un centre de réglages étendu.
Côté améliorations : un démarrage plus rapide, une politique de mot de passe renforcée (10 caractères minimum, au moins deux types de caractères), le clavier et la souris transportés en WebRTC pour réduire la latence en P2P et un indicateur de verrouillage des majuscules. Plus une correction des grésillements et blocages du micro.
Un clic sur “Upgrade Now” et tout s’enchaîne sans intervention : le téléchargement du paquet avec son pourcentage, puis l’écran “Upgrading…” qui prévient sobrement “Update takes about 2 minutes. Don’t press buttons or unplug anything.”, puis le redémarrage automatique et le retour sur la page de connexion. Quelques minutes en tout.
Au retour, le boîtier affiche V1.10.1 release4, marquée “Latest”. Le serveur web est passé en nginx/1.31.2, l’interface a changé (menus en icônes seules, nouvelles icônes pour les réglages et le tableau de bord en haut à droite) et le flux s’appelle désormais “WebRTC(FEC) H.264”. Mon mot de passe, déjà robuste et rangé dans Bitwarden, a été conservé : aucun changement demandé malgré la nouvelle politique.
Et une nouveauté m’a fait plaisir : l’app Netbird est apparue dans l’Apps Center. Elle n’existait pas en V1.8.1. Le produit évolue vite et dans le sens de mon homelab.
Mettre à jour avant de configurer. Sur un équipement neuf, le firmware d’usine a souvent quelques versions de retard. Ici, la mise à jour a apporté le tableau de bord de latence et l’app Netbird, deux choses dont je me sers dans la suite. Autant la faire tant qu’il n’y a encore rien à perdre.
Étape 4 : le tour des réglages et la configuration de base#
Avant de toucher à quoi que ce soit, j’ai fait le tour de l’état par défaut. En résumé :
- Session Settings (menu de gauche, réglages propres à la session) : la vidéo (transfert WebRTC(FEC), mode Smart ou Normal, latence “Smooth Display”, qualité Medium, 20 % de paquets FEC, EDID
1920x1080/ASUS/60Hz), l’audio et la caméra (désactivés), le clavier (dont une inversion Cmd/Ctrl pour macOS, pratique depuis mon poste) et la souris (dont un “Mouse Jiggle” qui empêche la mise en veille). - Settings, le centre de réglages, en six onglets. USB Devices gère les périphériques émulés avec un budget de “ressources” (3 sur 10 utilisées par la souris et le clavier ; micro, caméra, clé USB et CD-ROM virtuels inactifs). Preferences règle l’affichage, la langue, le fuseau horaire (Etc/UTC par défaut) et l’écran tactile. Network montre le hostname
glkvmet l’Ethernet en DHCP. Security regroupe le mot de passe, la 2FA (désactivée) et le certificat TLS (Default ou Custom, donc import possible). Cloud propose de lier le boîtier à un compte GL.iNet. System gère le redémarrage, la réinitialisation, le canal bêta et l’export des journaux. - Toolbox : presse-papiers (“Paste To Remote Device”), OCR, raccourcis clavier (Ctrl+Alt+Suppr et compagnie), Wake-on-LAN et même un terminal sur le KVM lui-même.
- Accessories : aucun accessoire externe détecté, ni carte ATX ni Fingerbot.
- Virtual Media : désactivé par défaut.
- Apps Center : Tailscale, ZeroTier et Netbird, tous désactivés.
La configuration de base, elle, tient en deux réglages :
- Hostname :
glkvmdevientkvm01, cohérent avec pve01, pbs01 ou dns01. Le champ s’enregistre sans bouton de validation etkvm01.localrésout immédiatement en mDNS. - Fuseau horaire : Etc/UTC devient Europe/Paris.
Les deux ont survécu à un rechargement de l’interface. Côté réseau, la suite est prévue mais pas encore faite : une réservation DHCP dans UniFi plutôt qu’une IP statique dans le KVM (l’adressage reste ainsi géré à un seul endroit), qui placera kvm01 en .30, l’adresse que le plan d’adressage de la partie 5 réservait déjà au KVM. Puis un enregistrement kvm01.ktw.ovh dans le Technitium de la partie 13.
Et ce que j’ai volontairement laissé de côté pour l’instant :
- La 2FA : elle viendra plus tard.
- Le cloud GL.iNet : non lié. L’accès distant passera par Netbird, dans une prochaine partie.
Étape 5 : montage dans le rack et branchement des machines#
Les équerres 10 pouces se vissent sur les flancs du boîtier et le Comet X prend place dans le rack imprimé, en U6, l’emplacement que je destinais au JetKVM.
Le câblage est simple : un HDMI et un USB par nœud, avec les câbles fournis (USB-C côté Comet X, USB-A côté OptiPlex).
| Port | Machine |
|---|---|
| Port1 | pve01 |
| Port2 | pve02 |
| Port3 | pve03 |
| Port4 | pbs01 (via un adaptateur) |
Reste pbs01, l’OptiPlex 9020, dont la sortie DisplayPort ne rentre pas dans une entrée HDMI. Un adaptateur DisplayPort vers HDMI de chez UGREEN branché sur le 9020, un des câbles HDMI fournis, l’USB sur le port 4 et c’est réglé. Le port passe en HDMI-IN et K&M, la console du Proxmox Backup Server s’affiche en 1080p à 60 i/s et le clavier répond. Le port est renommé pbs01 et les quatre machines de la baie sont désormais pilotables depuis le navigateur.
Dans l’interface, le sélecteur “Switch Port” indique pour chaque port s’il détecte une entrée vidéo (HDMI-IN) et un clavier et une souris (K&M). La mention USB suit le port actif : les médias virtuels sont rattachés au port sélectionné. La bascule d’un port à l’autre prend quelques secondes, le temps d’un écran “Switching signal in progress” puis d’une notification “Switch Successfully”.
Pour le clavier, un détail : il faut d’abord cliquer dans la vidéo pour qu’il soit capturé. Tant que ce n’est pas fait, les icônes clavier et souris restent orange en bas à droite. Ensuite, la saisie passe sans souci : un Entrée sur l’invite login: de pve03 réaffiche bien l’invite.
Dernière touche, un crayon apparaît au survol de chaque carte du sélecteur (“Edit Port Name”). Les quatre ports s’appellent désormais pve01, pve02, pve03 et pbs01 et le nom remplace “Port1” dans la barre d’outils. Un détail, mais c’est le genre de détail qui évite de redémarrer le mauvais nœud.
Étape 6 : le tableau de bord et la latence#
La V1.10.1 a apporté un Data Dashboard, qui affiche l’état du périphérique (HDMI connecté, clavier et souris capturés ou libres, micro, caméra) et des métriques temps réel. Sur le LAN, en P2P, avec une console texte à l’écran, voici ce que j’ai relevé :
| Métrique | Relevés |
|---|---|
| Latence réseau | le plus souvent autour de 6 ms, avec des pics jusqu’à 75 ms |
| Gigue | 2 à 9 ms |
| Perte de paquets | 0 % |
| Débit | 130 à 145 kbps |
| Images par seconde | 58 à 62 i/s |
| Délai de lecture | moins de 0,5 ms |
Sur le papier, c’est très correct. Mais soyons honnêtes sur ce que ces chiffres valent : une console texte, c’est presque une image fixe, d’où le débit minuscule. GL.iNet annonce 30 à 60 ms de latence, un chiffre qui s’entend sur le réseau local (LAN, en P2P). Pour une comparaison loyale, il faudra refaire la mesure avec un affichage graphique (un BIOS, un installeur), toujours sur le LAN. À distance, via Netbird ou tout autre VPN ou tunnel, la latence ressentie est celle du boîtier plus l’aller-retour réseau : c’est une autre mesure, que je traiterai dans une prochaine partie.
Étape 7 : Wake-on-LAN et BIOS à distance#
Le Wake-on-LAN, c’est la possibilité d’allumer une machine éteinte en lui envoyant sur le réseau un paquet magique, une trame qui contient son adresse MAC. Pour le homelab, l’intérêt est clair : pouvoir éteindre le rack quand il ne sert pas, pour réduire la consommation et le rallumer à distance. Les OptiPlex ont le Wake-on-LAN activé dans le BIOS depuis la partie 7 : c’était dans le tableau des réglages de référence.
Dans la Toolbox, la section Wake-on-Lan permet de déclarer les machines. La fenêtre “Add Device” scanne le VLAN et liste tout ce qui répond, avec nom, IP et adresse MAC. Pratique, mais j’ai préféré l’ajout manuel : un nom et une adresse MAC et pve01 est déclaré. (Vous ne verrez pas ces écrans ici : ils affichent les adresses MAC du lab.)
Pour le test, pve01 est éteint proprement. Le HA déplace le runner CI sur un autre nœud, comme prévu depuis la partie 11. Le KVM affiche “No HDMI signal detected” et le ping ne répond plus.
Accroc : le paquet part, le nœud dort#
Un clic sur “Wake” et l’interface est formelle :
Wake up command sent successfully.Sauf que pve01 ne bouge pas. Pas de signal vidéo, pas de ping, toujours rien au bout de plus d’une minute. Le paquet est parti, mais personne ne l’a entendu.
Puisque le Wake-on-LAN est bien activé dans le BIOS, deux suspects :
- côté Linux, la carte réseau peut être laissée en
Wake-on: d(désactivé) au moment de l’extinction, auquel cas elle n’écoute plus rien - côté BIOS, un réglage d’économie d’énergie, Deep Sleep Control, qui coupe la carte réseau à l’arrêt. Il ne figurait pas dans mes réglages de référence de la partie 7, je ne l’avais donc jamais regardé
Le second se vérifie dans le BIOS. Et c’est là que le KVM montre ce qu’il a dans le ventre.
Le BIOS dans le navigateur#
Il faut bien rallumer pve01 une fois, au bouton, puisque le Wake-on-LAN ne fonctionne pas. Mais c’est le seul geste physique de toute l’opération. Au démarrage, le menu GRUB de Proxmox s’affiche dans le navigateur et il propose une entrée bien pratique : “UEFI Firmware Settings”, qui redémarre directement dans le BIOS. Plutôt que de guetter le logo Dell pour presser la bonne touche au bon moment, on la sélectionne tranquillement au clavier, à travers le KVM.
Le BIOS du Dell OptiPlex 7050 s’affiche alors dans un onglet de mon navigateur. Sans écran ni clavier branchés sur la machine et la navigation au clavier se fait sans aucun souci.
Direction Power Management. Le Wake on LAN/WLAN est bien sur LAN Only, conforme à la partie 7. Mais juste au-dessus, Deep Sleep Control est réglé sur “Enabled in S4 and S5”, autrement dit en hibernation (S4) et à l’arrêt (S5). Le texte d’aide du BIOS ne laisse aucun doute :
Note: With this option enabled, the Remote Wakeup and Remote Manageability
Features will be disabled when the system is Shutdown or in Hibernate Mode.
Voilà la cause. Pour économiser un peu d’énergie à l’arrêt, le BIOS coupe la carte réseau. Or le Wake-on-LAN repose justement sur une carte réseau qui reste éveillée, machine éteinte, pour guetter le paquet magique. Les deux réglages s’annulent : activer l’un sans désactiver l’autre ne sert à rien.
Le correctif s’applique dans la foulée, toujours à distance : Deep Sleep Control sur Disabled, puis Apply, puis Exit. pve01 redémarre et répond au ping en moins d’une minute.
La contrepartie : la carte réseau reste alimentée à l’arrêt, donc la consommation de la machine éteinte est légèrement plus élevée.
Le retour du test#
pve01 éteint proprement une seconde fois, “Wake” depuis la Toolbox et cette fois ça marche : le signal vidéo revient en 8 secondes et pve01 répond au ping environ 38 secondes après le clic. Aucune modification côté Linux n’a été nécessaire : le premier suspect était innocent, c’est bien Deep Sleep Control qui annulait le Wake-on-LAN.
C’est exactement pour ça qu’on installe un KVM. Diagnostiquer un réglage BIOS, le corriger, puis vérifier le résultat, le tout depuis mon poste, sans brancher d’écran ni de clavier sur la machine. Sans KVM, cette séance aurait commencé par sortir un écran et un clavier et par aller les brancher à l’arrière d’un rack.
Mon avis#
Points forts#
- Une boîte complète : équerres 10 et 19 pouces, quatre câbles HDMI, quatre câbles USB, un câble Ethernet. Rien à racheter pour brancher quatre machines.
- Le PoE : un seul câble à l’arrière, pas de bloc secteur supplémentaire et un USB-C en secours. Le tout pour 5,16 W relevés dans UniFi, moins que les 7,5 W de ma borne Wi-Fi.
- Quatre machines branchées en permanence, avec une bascule de quelques secondes et des ports qu’on peut renommer.
- Une mise à jour du firmware sans histoire : quelques minutes, aucune intervention, configuration et mot de passe conservés.
- Un produit qui évolue : la V1.10.1 a apporté le tableau de bord et l’app Netbird.
- De bons chiffres sur le LAN : 60 i/s, 0 % de perte et une navigation au clavier dans le BIOS sans souci.
- Le Wake-on-LAN intégré, qui a fonctionné dès que le BIOS a cessé de couper la carte réseau.
- Les options de sécurité sont là : 2FA disponible, import d’un certificat TLS personnalisé possible.
Point faible#
- Le prix : 295,95 € affichés, ce n’est pas un achat anodin pour un homelab. Mais il faut le mettre en regard de ce qu’il remplace : quatre KVM à un port, avec autant de boîtiers, de câbles, d’alimentations et de place dans la baie. Et les KVM sur IP à quatre ports restent rares. Pour piloter un cluster de trois ou quatre nœuds, l’équation se tient.
Une petite suggestion#
- Le fuseau horaire est en Etc/UTC par défaut et se règle à la main. Rien de grave, mais proposer de reprendre celui du navigateur à la première connexion serait un joli confort.
Les points encore ouverts#
- Deep Sleep Control sur pve02, pve03 et pbs01 (et la déclaration de ces trois machines dans le Wake-on-LAN) : à traiter lors des prochaines maintenances planifiées.
- La réservation DHCP en
.30et l’enregistrementkvm01.ktw.ovhdans Technitium. - Un peu de câble management à l’arrière du rack : huit câbles de 1 m pour quatre machines, c’est largement suffisant, mais ça déborde vite.
- Une mesure de latence sur le LAN avec un affichage graphique, comparable à l’annonce de GL.iNet.
- L’accès distant via Netbird, et avec lui une mesure de la latence à distance (latence du boîtier plus aller-retour réseau).
- La 2FA.
- Le montage d’une ISO depuis l’eMMC, par exemple pour réinstaller un nœud Proxmox.
- L’inversion Cmd/Ctrl pour macOS, à tester depuis mon poste.
Et maintenant ?#
Le KVM est en place et le homelab a son filet de sécurité. La prochaine partie reste côté matériel, avec la baie qui l’accueille : le rack 10 pouces imprimé en 3D, que vous avez aperçu sur les photos. Ensuite, retour au fil logiciel là où la partie 13 l’avait laissé, avec l’identité et l’accès. Et le Comet X y retrouvera Netbird.
Si le Comet X vous intéresse, vous le trouverez sur la boutique officielle GL.iNet ou sur Amazon (liens fournis par GL.iNet).
À bientôt !
