NaoShift en octobre 2026 : incidents, ITSM, Hyper-V et migrations

Équipe NaoShift · 02/11/2026

Alertes d'incident accompagnées d'une première analyse de cause, tickets dans ServiceNow et Matrix42, Microsoft Hyper-V, migration de VMware par vagues et NaoShift Portal sur XCP-ng : les nouveautés d'octobre 2026.

En octobre, NaoShift a appris à prévenir. Une panne de nœud, de cluster, de baie ou de job de sauvegarde déclenche désormais une alerte qui nomme l'objet, donne les vrais horaires et arrive avec une première analyse de cause. Ces incidents peuvent ouvrir des tickets dans l'outil de gestion des services de votre société. Microsoft Hyper-V rejoint la console, la sortie de VMware s'organise par vagues, et NaoShift Portal arrive sur XCP-ng.

Cette note couvre ce qui a été mis en production du 10 au 31 octobre 2026. Les temps forts viennent d'abord, puis la liste détaillée.

Des alertes d'incident qui arrivent avec leur cause

Une équipe d'exploitation n'attend plus la collecte suivante pour savoir qu'un nœud est tombé. NaoShift ouvre un incident quand un nœud, un cluster, un contrôleur ou un pool de baie devient indisponible, quand une source ne répond plus, ou quand un job de sauvegarde échoue après avoir réussi. L'état d'un nœud est jugé en direct, à partir de ce que remonte l'agent, avec une courte stabilisation qui écarte les micro-coupures. L'incident se clôt seul au retour de l'objet.

L'e-mail nomme l'objet et donne les vrais horaires, dans le fuseau du destinataire. Quand l'heure exacte n'est pas connue, il écrit « entre 14 h 02 et 14 h 07 » plutôt qu'une heure fausse.

Pour un nœud ou un cluster critique, l'analyse de cause racine démarre d'elle-même. Une analyse préalable accompagne l'alerte, l'analyse complète suit au retour du nœud, et un rapport d'étape part au bout de quatre heures s'il ne revient pas. Elle lit les journaux de l'hyperviseur et dit qui a fait quoi dans les 24 heures précédentes : événements et tâches vCenter, tâches Proxmox, arrêts Windows, journaux des nœuds Hyper-V.

Chaque compte choisit ce qu'il reçoit : des domaines (infrastructure, santé, connecteurs, sauvegarde, stockage, VM, analyses de cause), un seuil de sévérité et un périmètre (sources, datacenters, clusters). Chaque domaine se désactive en un clic depuis l'e-mail. Autour de l'alerte :

• une page Incidents avec sa frise, une cloche dans l'en-tête, et les incidents dans le journal des événements ;
• des fenêtres de maintenance sur un nœud, un cluster ou une VM : l'incident est enregistré, mais il n'est ni annoncé ni compté ;
• les problèmes, c'est-à-dire les incidents récurrents : le même objet plusieurs fois en quelques jours, ou plusieurs nœuds d'un même cluster en quelques heures ;
• des VM mises en surveillance, sur des plages horaires d'astreinte. Une VM tombée avec son nœud est rattachée à l'incident du nœud : une seule alerte, qui dit aussi où la VM a redémarré ;
• un rappel quotidien pour un job de sauvegarde qui reste en échec.

Les alertes portent sur les données vivantes, collectées par l'agent ou par un connecteur cloud : l'import d'un fichier ne déclenche jamais d'incident.

Vos incidents dans votre ITSM

Les équipes qui pilotent leur production depuis un outil de gestion des services y retrouvent désormais les incidents de NaoShift. NaoShift écrit dans ServiceNow et dans Matrix42 ESM : les incidents et les problèmes ouvrent des tickets, NaoShift y ajoute ses notes et le rapport d'analyse de cause, puis relit l'état des tickets toutes les cinq minutes.

Une règle décide de ce qui part : natures d'incident, sévérité, connecteurs, clusters, groupes d'actifs. Elle commence en observation, sans rien envoyer, le temps de vérifier ce qu'elle produirait. La fermeture d'un ticket ne clôt jamais un incident dans NaoShift.

La CMDB de l'ITSM peut aussi être tenue à jour depuis l'inventaire consolidé : ServiceNow au travers de son moteur d'identification et de réconciliation, Matrix42 au travers de ses fiches d'ordinateur. Un élément n'est retiré qu'après sept jours d'absence de tout l'inventaire.

Pour une société dont les noms de machines sont pseudonymisés, l'envoi des vrais noms vers l'ITSM est un choix explicite et tracé. L'intégration ITSM fait partie de l'offre Premium. Elle est en accès anticipé.

Microsoft Hyper-V rejoint la console

Les hôtes Hyper-V autonomes et les clusters de basculement se branchent comme les autres plateformes : par l'agent sortant, en WinRM sur HTTPS, sans rien installer sur les hôtes. La collecte passe par un script PowerShell en lecture seule, embarqué dans l'agent. Un nœud injoignable est signalé comme tel, sans faire échouer la collecte du cluster.

Côté actions, Hyper-V reçoit une trentaine de gestes : alimentation, checkpoints, taille et nom d'une VM, disques, cartes réseau et médias, clone, suppression, migration entre nœuds, maintenance d'un nœud et haute disponibilité par rôle de cluster. Le principe est le même que pour les autres plateformes : lecture seule par défaut, écriture activée par cible avec un compte dédié, tracée avant exécution.

Les journaux d'événements Hyper-V, du cluster et du système de chaque nœud alimentent l'analyse de cause racine.

Sortir de VMware par vagues, vers Proxmox VE ou XCP-ng

Le menu Opérations accueille Migrations, en bêta. Une équipe y prépare la sortie de VMware machine par machine. Elle glisse une VM vers sa destination. L'assistant contrôle chaque machine (niveau de CPU, firmware, Secure Boot, vTPM, chiffrement, place libre, réseau) et lui donne un score d'effort. Les machines se regroupent ensuite en vagues, avec leur fenêtre et leur concurrence.

Les disques ne transitent jamais par NaoShift : c'est la destination qui importe la machine, avec son import natif depuis ESXi, chez Proxmox VE comme chez Xen Orchestra. La machine source n'est jamais détruite, et chaque vague garde son retour arrière.

Chaque vague a son runbook. On y trouve des contrôles avant l'arrêt de la source, des étapes à cocher (accord du responsable de l'application, sauvegarde vérifiée, licences liées à l'UUID SMBIOS) et des étapes automatiques dans l'OS invité (pilotes VirtIO, profil réseau lié à l'adresse MAC, retrait des VMware Tools). Vers Proxmox VE, ces étapes peuvent aussi se faire hors ligne, sur la machine importée encore arrêtée, sans rien installer dans l'invité. Une étape bloquante ne se saute que par un administrateur, avec un motif.

Les migrations se pilotent aussi par l'API publique et par la CLI naoshift migrations. Les entrées « Déployer » et « Migrations » sont visibles de tous les comptes : sans les droits, une page dit ce qui manque et qui peut le lever. Pendant la bêta, les migrations s'ouvrent société par société.

NaoShift Portal arrive sur XCP-ng

NaoShift Portal, l'alternative à VMware Cloud Director, fonctionne désormais sur XCP-ng au travers de Xen Orchestra, en plus de Proxmox VE. Le client final y retrouve les mêmes usages : un datacenter virtuel isolé, le déploiement depuis le catalogue avec ses extraits cloud-init, et la console à son nom.

Le mois apporte aussi, côté hébergeur et côté client :

• un catalogue commun d'images ISO et d'extraits cloud-init, publié dans les datacenters virtuels ;
• des réseaux privés VXLAN par client, sur un site Proxmox VE 9 ;
• des politiques de placement, qui réservent un groupe de nœuds à un déploiement ;
• des classes de stockage, reportées dans la facturation ;
• des limites de datacenter virtuel modifiables en service ;
• des gestes rangés dans chaque onglet de la machine, grisés avec leur motif quand la plateforme les refuserait, avant tout envoi.

Le détail

Exploitation

• Analyse de cause racine sur un nœud ou un cluster, et plus seulement sur une VM.
• Alarmes vCenter actives des hôtes et des clusters dans les incidents de santé, visibles sans e-mail.
• Récapitulatifs hebdomadaire, le lundi, et mensuel, le 1er, en plus du quotidien : critiques ouverts par type et écart avec la période précédente, sans jamais un nom de machine. Un seul e-mail par matin.
• Récapitulatif quotidien pour toute société dont les données sont récentes, y compris pour les invitations en attente.
• Clic droit sur un nœud ou un cluster dans l'inventaire : opérations, diagnostic, consultation.
• « Déployer » et « Nouvelle migration » s'ouvrent avec l'objet choisi déjà sélectionné.
• La supervision des collecteurs indique le dernier redémarrage de l'agent.

Plateformes, sauvegarde et stockage

• Xen Orchestra reçoit les gestes de Proxmox VE : alimentation, snapshots, clone, haute disponibilité, maintenance, migration, disques, cartes réseau et médias.
• Baies DataCore SANsymphony et Huawei OceanStor en lecture (accès anticipé) : cinq constructeurs de baies au total.
• Les réseaux overlay sont reconnus comme tels : VXLAN et EVPN avec leur VNI, segments NSX et réseaux opaques N-VDS.
• vSphere : firmware, Secure Boot, vTPM et chiffrement des VM collectés.
• Sauvegarde : chaque objet porte sa plateforme, et le collecteur Veeam dit ce qu'il écarte.
• Le compte d'action d'une cible se renseigne en même temps que ses identifiants de collecte.

Sécurité et administration

• Rôles de capacités et groupes de connecteurs : les droits d'écriture se donnent par équipe et par groupe de cibles, et l'écran dit d'où vient chaque droit hérité.
• Tout cocher ou tout décocher en un clic dans les capacités d'écriture, sans recharger la page.
• L'agent Linux tourne sous un compte dédié, sans droits root.
• L'agent n'accepte que des mises à jour signées, vérifiées pour sa plateforme.
• Fin d'abonnement : rappels avant l'échéance, une semaine de grâce, puis lecture seule. Rien n'est supprimé.

Questions fréquentes

Comment NaoShift détecte-t-il la panne d'un nœud ?

L'agent installé chez vous remonte en direct l'état de connexion des nœuds. Un changement qui dure ouvre ou clôt l'incident, daté du moment du changement. La collecte périodique sert de second regard. Les imports de fichiers, comme un export RVTools, ne déclenchent jamais d'alerte.

Quels outils ITSM NaoShift alimente-t-il ?

ServiceNow et Matrix42 ESM, en accès anticipé, avec l'offre Premium : tickets d'incident et de problème, notes, rapport d'analyse de cause, et CMDB tenue à jour depuis l'inventaire. Le détail des offres est sur la page Tarifs.

Comment se passe une migration de VMware vers Proxmox VE ?

NaoShift prépare et orchestre, la destination importe : Proxmox VE lit la machine directement chez VMware, sans copie par NaoShift. L'assistant contrôle chaque machine avant la bascule, le runbook de la vague déroule les étapes, et la source reste intacte jusqu'à la fin, avec un retour arrière. Le détail est sur la page NaoShift Core.

Pour aller plus loin

Retrouvez NaoShift Core et NaoShift Portal sur le site. L'essai gratuit de 30 jours permet de brancher une première source. Pour l'intégration ITSM, une migration ou un besoin d'hébergeur, contactez-nous.