NaoShift in October 2026: incidents, ITSM, Hyper-V and migrations
Incident alerts that come with a first root-cause analysis, tickets in ServiceNow and Matrix42, Microsoft Hyper-V, VMware migration in waves and NaoShift Portal on XCP-ng: what's new in October 2026.
In October, NaoShift learned to warn you. A node, cluster, storage array or backup job failure now triggers an alert that names the object, gives the real times and comes with a first root-cause analysis. These incidents can open tickets in your company's service management tool. Microsoft Hyper-V joins the console, moving off VMware is organised in waves, and NaoShift Portal arrives on XCP-ng.
This note covers what went into production from October 10 to 31, 2026. The highlights come first, followed by the detailed list.
Incident alerts that come with their cause
An operations team no longer waits for the next collection to learn that a node is down. NaoShift opens an incident when a node, a cluster, or a storage array controller or pool becomes unavailable, when a source stops answering, or when a backup job fails after having succeeded. A node's state is judged live, from what the agent reports, with a short settling time that filters out micro-outages. The incident closes on its own when the object comes back.
The email names the object and gives the real times, in the recipient's time zone. When the exact time is not known, it says "between 2:02 pm and 2:07 pm" rather than a wrong time.
For a critical node or cluster, the root-cause analysis starts by itself. A preliminary analysis comes with the alert, the full analysis follows when the node is back, and a progress report goes out after four hours if it does not come back. It reads the hypervisor's logs and says who did what in the previous 24 hours: vCenter events and tasks, Proxmox tasks, Windows shutdowns, Hyper-V node logs.
Each account chooses what it receives: domains (infrastructure, health, connectors, backup, storage, VMs, root-cause analyses), a severity threshold and a scope (sources, datacenters, clusters). Each domain can be turned off in one click from the email. Around the alert:
- an Incidents page with its timeline, a bell in the header, and incidents in the event log;
- maintenance windows on a node, a cluster or a VM: the incident is recorded, but neither announced nor counted;
- problems, meaning recurring incidents: the same object several times within a few days, or several nodes of the same cluster within a few hours;
- VMs placed under watch, on on-call time ranges. A VM that went down with its node is attached to the node's incident: a single alert, which also says where the VM restarted;
- a daily reminder for a backup job that keeps failing.
Alerts are based on live data, collected by the agent or by a cloud connector: importing a file never triggers an incident.
Your incidents in your ITSM
Teams that run production from a service management tool now find NaoShift's incidents there. NaoShift writes to ServiceNow and to Matrix42 ESM: incidents and problems open tickets, NaoShift adds its notes and the root-cause analysis report, then reads the tickets' state back every five minutes.
A rule decides what is sent: incident types, severity, connectors, clusters, asset groups. It starts in observation mode, sending nothing, while you check what it would produce. Closing a ticket never closes an incident in NaoShift.
The ITSM's CMDB can also be kept up to date from the consolidated inventory: ServiceNow through its identification and reconciliation engine, Matrix42 through its computer records. An item is removed only after seven days of absence from the whole inventory.
For a company whose machine names are pseudonymised, sending the real names to the ITSM is an explicit, logged choice. The ITSM integration is part of the Premium plan. It is in early access.
Microsoft Hyper-V joins the console
Standalone Hyper-V hosts and failover clusters connect like the other platforms: through the outbound agent, over WinRM on HTTPS, with nothing installed on the hosts. Collection runs a read-only PowerShell script embedded in the agent. An unreachable node is reported as such, without failing the cluster's collection.
On the action side, Hyper-V gets around thirty operations: power, checkpoints, VM size and name, disks, network adapters and media, clone, deletion, migration between nodes, node maintenance and high availability by cluster role. The principle is the same as for the other platforms: read-only by default, write access enabled per target with a dedicated account, logged before execution.
The Hyper-V, cluster and system event logs of each node feed the root-cause analysis.
Moving off VMware in waves, to Proxmox VE or XCP-ng
The Operations menu now has Migrations, in beta. A team prepares its move off VMware machine by machine. It drags a VM to its destination. The wizard checks each machine (CPU level, firmware, Secure Boot, vTPM, encryption, free space, network) and gives it an effort score. Machines are then grouped into waves, each with its window and concurrency.
Disks never go through NaoShift: the destination imports the machine with its native import from ESXi, on Proxmox VE as on Xen Orchestra. The source machine is never destroyed, and each wave keeps its rollback.
Each wave has its runbook. It holds checks before the source is shut down, steps to tick (go-ahead from the application owner, backup verified, licences bound to the SMBIOS UUID) and automated steps in the guest OS (VirtIO drivers, network profile bound to the MAC address, removal of VMware Tools). Towards Proxmox VE, these steps can also run offline, on the imported machine while it is still stopped, with nothing installed in the guest. A blocking step can only be skipped by an administrator, with a reason.
Migrations can also be driven through the public API and the naoshift migrations CLI. The "Deploy" and "Migrations" entries are visible to every account: without the rights, a page says what is missing and who can grant it. During the beta, migrations are opened company by company.
NaoShift Portal arrives on XCP-ng
NaoShift Portal, the alternative to VMware Cloud Director, now runs on XCP-ng through Xen Orchestra, alongside Proxmox VE. End customers find the same features: an isolated virtual datacenter, deployment from the catalogue with its cloud-init snippets, and the console in their own name.
The month also brings, for hosting providers and their customers:
- a shared catalogue of ISO images and cloud-init snippets, published into virtual datacenters;
- private VXLAN networks per customer, on a Proxmox VE 9 site;
- placement policies, which reserve a group of nodes for a deployment;
- storage classes, carried into billing;
- virtual datacenter limits that can be changed while in service;
- operations placed in each tab of the machine, greyed out with their reason when the platform would refuse them, before anything is sent.
In detail
Operations
- Root-cause analysis on a node or a cluster, not just on a VM.
- Active vCenter alarms on hosts and clusters in health incidents, visible without an email.
- Weekly (on Mondays) and monthly (on the 1st) summaries by email, on top of the daily one: open critical items by type and change since the previous period, never a machine name. A single email per morning.
- Daily summary for every company with recent data, including pending invitations.
- Right-click on a node or a cluster in the inventory: operations, diagnostics, details.
- "Deploy" and "New migration" open with the chosen object already selected.
- Collector monitoring shows the agent's last restart.
Platforms, backup and storage
- Xen Orchestra gets the Proxmox VE operations: power, snapshots, clone, high availability, maintenance, migration, disks, network adapters and media.
- DataCore SANsymphony and Huawei OceanStor arrays, read-only (early access): five storage vendors in total.
- Overlay networks are recognised as such: VXLAN and EVPN with their VNI, NSX segments and N-VDS opaque networks.
- vSphere: VM firmware, Secure Boot, vTPM and encryption are collected.
- Backup: every object carries its platform, and the Veeam collector says what it leaves out.
- A target's action account is entered together with its collection credentials.
Security and administration
- Capability roles and connector groups: write rights are granted per team and per group of targets, and the screen says where each inherited right comes from.
- Select or clear all write capabilities in one click, without reloading the page.
- The Linux agent runs under a dedicated account, without root privileges.
- The agent only accepts signed updates, verified for its platform.
- End of subscription: reminders before the due date, a one-week grace period, then read-only. Nothing is deleted.
Frequently asked questions
How does NaoShift detect a node failure?
The agent installed on your premises reports the nodes' connection state live. A lasting change opens or closes the incident, dated from the moment of the change. The periodic collection acts as a second check. File imports, such as an RVTools export, never trigger an alert.
Which ITSM tools does NaoShift feed?
ServiceNow and Matrix42 ESM, in early access, with the Premium plan: incident and problem tickets, notes, root-cause analysis report, and a CMDB kept up to date from the inventory. Plan details are on the Pricing page.
How does a migration from VMware to Proxmox VE work?
NaoShift prepares and orchestrates, the destination imports: Proxmox VE reads the machine directly from VMware, with no copy through NaoShift. The wizard checks each machine before the cutover, the wave's runbook runs the steps, and the source stays intact until the end, with a rollback. Details are on the NaoShift Core page.
Going further
Find NaoShift Core and NaoShift Portal on the website. The 30-day free trial lets you connect a first source. For the ITSM integration, a migration or a hosting provider's needs, contact us.