What is Huawei FusionCompute?
Huawei FusionCompute is Huawei's enterprise virtualization platform for data center servers. It turns physical servers into elastic pools of compute, storage, and network resources, and delivers those resources to virtual machines (VMs) on demand. Rather than relying on a third-party hypervisor, FusionCompute uses Huawei's own UVP (Unified Virtualization Platform), a KVM-based hypervisor that runs on a bare-metal architecture, similar in spirit to VMware ESXi.
FusionCompute is not a standalone product. It sits at the heart of Huawei's FusionSphere cloud operating system and typically ships alongside FusionStorage, eBackup, and UltraVR to form a complete cloud infrastructure stack. This positioning matters for backup planning, because the native components — especially eBackup for backup and UltraVR for disaster recovery — were designed to work with FusionCompute's specific APIs and changed-block tracking mechanisms.
Two numbers frame the scale FusionCompute is built for: a single logical cluster supports up to 128 hosts and 8,000 VMs. When managed via FusionSphere, multiple clusters can be pooled to manage up to 4,096 hosts and 80,000 VMs in total. For enterprises running dense, mission-critical environments, that scale makes a reliable, agentless backup strategy essential rather than optional.
The Core Architecture: VRM and CNA Explained
FusionCompute is built from two cooperating components. Understanding them is the key to understanding how backup works, because every third-party backup tool ultimately talks to one of these two layers.
CNA (Computing Node Agent) runs on every physical host. It is the component that actually executes virtualization: it abstracts CPU, memory, storage, and network hardware, and it manages the local lifecycle of the VMs placed on that host. CNA contains the UVP hypervisor (which virtualizes the hardware) and a management agent that reports back up to the control plane. From a backup perspective, CNA is where the changed-block tracking (CBT) actually happens at the disk level.
VRM (Virtual Resource Manager) is the central brain of the cluster. It provides the web-based management portal, schedules resources across hosts, allocates IP and VLAN resources, and manages the distribution and migration of VMs. The VRM typically runs in an active/standby pair for high availability, with automatic failover if the active node fails — a design that means running VMs keep operating during management‑plane outages, though VM provisioning and scheduling operations will be temporarily unavailable during failover.
The relationship between the two is a clean separation of concerns: CNA does the local work, VRM does the global coordination. When you protect a FusionCompute environment with an external tool, that tool registers with the VRM to enumerate VMs and hosts, then uses the CNA's CBT interface to read only the changed blocks during incremental backups.
Key Features and Capabilities
FusionCompute ships with a broad set of enterprise features that shape how you should think about data protection:
Live migration (VM Motion): VMs can move between hosts without downtime, which means backup schedules must be tolerant of VMs changing location.
HA and FT: High availability restarts failed VMs automatically, and fault tolerance keeps a mirrored standby running. Both reduce the "acceptable downtime" pressure on restore, but neither replaces backup — HA is not a copy of your data.
DRS and DPM: Dynamic resource scheduling balances load automatically, and distributed power management consolidates idle VMs onto fewer hosts. These constant relocations are another reason changed-block tracking, rather than full copies, is essential for efficient backup.
Thin provisioning and linked clones: Storage is allocated on demand, which saves space but can complicate capacity planning for backup storage.
NUMA, memory ballooning, and memory reuse: FusionCompute overcommits memory through ballooning, sharing, and swapping. This means the "configured" size of a VM is not always a reliable proxy for its actual backup footprint.
QoS controls: CPU, memory, and network limits protect tenant performance and should be mirrored when sizing backup windows.
The practical takeaway: FusionCompute is designed for dense, highly automated environments. A backup tool that relies on naive full-image copies will struggle; a tool that understands CBT and the VRM/CNA split will scale.
Storage and Network Virtualization in FusionCompute
FusionCompute virtualizes storage and network in ways that directly affect backup architecture.
Storage virtualization lets FusionCompute present SAN, NAS, and local disks as unified storage resources. Virtual disks are managed through the VIMS (Virtual Image Management System) file system. FusionCompute supports thin provisioning, incremental snapshots, and storage live migration — the ability to move a VM's disk between datastores without downtime. This is important for backup because a running VM may have its disk moved mid-window; the backup tool must track the VM logically through the VRM rather than assuming a fixed physical location.
Network virtualization is handled by a Distributed Virtual Switch (DVS). Each CNA participates in a cluster-wide logical switch that spans hosts, so a VM's network identity (IP, VLAN, port group) follows it as it migrates. FusionCompute also supports SR-IOV passthrough on certified NICs such as the Intel X710 and XXV710 for near-native throughput on performance-critical VMs.
Why does this matter for backup? Because backup data flows across these same virtual networks. When you add a backup node, its "transfer IP" must be able to reach the CNA hosts over the management or storage plane. Planning that connectivity up front — and keeping it on the storage network where possible — is what separates fast, non-disruptive backups from slow ones that saturate production VLANs.
Huawei FusionCompute vs. VMware vSphere
Organizations commonly evaluate FusionCompute against VMware vSphere, and the differences shape the backup approach.
| Dimension | Huawei FusionCompute | VMware vSphere |
|---|
| Hypervisor | UVP (KVM‑based), bare‑metal | ESXi, proprietary |
| Management | VRM, active/standby pair | vCenter Server |
| Architecture support | x86 and ARM (Kunpeng) | Primarily x86 |
| Cluster scale | Up to 128 hosts / 8,000 VMs per cluster | Up to 96 hosts per cluster |
| Licensing | Per‑physical‑CPU licensing; VRM nodes consume CPU licenses, no separate management‑only license. | Per CPU core, vCenter sold separately |
| Native backup/DR | eBackup + UltraVR | Third‑party ecosystem |
The most consequential difference for backup is architectural: FusionCompute's native ARM (Kunpeng) support and its VRM-based CBT interface mean a backup tool must be built for FusionCompute's APIs, not simply for "KVM." A generic KVM backup agent that expects libvirt will not cleanly map to FusionCompute's management plane.
FusionCompute also bundles eBackup and UltraVR for native backup and disaster recovery. These are competent for homogeneous Huawei environments, but they typically do not cover heterogeneous estates — for example, an environment that mixes FusionCompute with VMware, Hyper-V, or Proxmox. In those cases, a single third-party platform like Vinchin that understands FusionCompute natively removes the need to run two separate backup stacks.
System Requirements and Deployment Guide
Deploying FusionCompute — and a backup strategy for it — starts with planning the hardware and network correctly.
Hardware compatibility: FusionCompute must run on hardware listed in Huawei's official compatibility/interoperability matrix. Certified server families include Huawei's 2288H V6, 5885H V5, and Kunpeng-based servers, plus common Dell PowerEdge, Lenovo ThinkSystem, and xFusion models across Intel Xeon, AMD EPYC, and Hygon CPUs. Using an uncertified RAID controller or NIC is a common cause of storage anomalies after CNA installation, so verifying the HCL before install is mandatory.
CPU and memory: Hosts require CPUs with hardware virtualization enabled (Intel VT-x/EPT or AMD-V/RVI). A single node commonly starts at 128 GB of RAM, with additional headroom reserved when the host also runs the VRM.
Network planes: A production deployment typically separates four logical networks: management (CNA/VRM communication), storage (iSCSI/NFS traffic), business (VM workloads), and BMC (out-of-band management). Storage and business planes usually need 10 Gbps or higher. The management and storage planes use large-layer-2 connectivity, with a round-trip latency of no more than 1 ms between nodes.
Deployment flow: FusionCompute is installed via a web-based tool. The workflow is: install the first CNA host from an ISO, launch the FusionCompute Web installation tool, use it to install the remaining hosts, and finally install the VRM in an active/standby pair. After installation, a default cluster is created automatically, and hosts are then added to resource pools.
For backup, the deployment-time decisions that matter most are: reserving a dedicated backup node, ensuring its transfer IP can reach every CNA host, and sizing the storage network so backup traffic does not compete with production I/O.
Best Practices for Performance Optimization
These practices keep both FusionCompute and its backup jobs running efficiently:
Enable CBT via the Service Management Port. FusionCompute supports changed-block tracking, but for external tools, you must add a Service Management Port on the CNA host and enable CBT Traffic Management in its connection settings. Without this dedicated service port configured, every backup degenerates into a full read of every disk, which is slow and I/O-heavy.
Use incremental-forever with periodic fulls. A "full + incremental" schedule, with fulls at a low frequency and incrementals daily (or multiple times per day), keeps both RPO and storage costs low.
Schedule outside peak windows. Because DRS and DPM already move VMs during the day, schedule backup windows for off-peak hours and use throttling to cap network and I/O if jobs overlap with production.
Keep backup traffic on the storage plane. Route the backup node's transfer IP over the storage network so backup streams never saturate business VLANs.
Leverage deduplication and compression. Enable both to reduce backup storage and bandwidth; deduplication ensures only unique blocks are transferred and stored.
Apply the 3-2-1 rule. Keep at least three copies of data, on two different media, with one offsite — implemented through offsite backup copy and cloud archive.
How Vinchin Protects FusionCompute VMs
Vinchin Backup & Recovery provides Huawei FusionCompute virtual machine protection through an agentless architecture built on the platform's native APIs. It supports FusionCompute 6.5.1, 8.1, 8.5, 8.6, 8.7, and 8.8.
Agentless by design. Vinchin adds the FusionCompute host (not individual VMs) via the VRM, so no in-guest agent is installed. This agentless FusionCompute backup approach keeps the guest OS untouched and avoids the maintenance overhead of per-VM agents.
CBT-based efficiency. After CBT is enabled on the CNA node, Vinchin's FusionCompute CBT backup copies only the blocks changed since the last run, dramatically shrinking backup windows and storage growth. Combined with deduplication, compression keeps backup footprints small.
Application-consistent options. For VMs running SQL Server or Oracle, Vinchin adds application-aware processing so database workloads are protected consistently, not just crash-consistently.
Scale-out and ransomware protection. Additional backup nodes can be added to scale with large FusionCompute clusters. The backup repository applies real-time I/O monitoring to deny unauthorized modification, shielding FusionCompute backups from ransomware.
Cross-platform recovery and V2V. Vinchin connects 15+ virtualization platforms, so a FusionCompute backup can be restored to another platform — or a VM migrated into FusionCompute — through simple V2V conversion. Full VM restore and instant restore are both supported.
The workflow is straightforward: add the FusionCompute host under Resources, then create a backup job in four steps — select source VMs, choose the backup destination, configure strategy (schedule, deduplication, compression, retention), and submit. Restores follow the same guided flow, from selecting a restore point to choosing the target host.
FAQ
Q1: What is the best way to back up Huawei FusionCompute VMs?
A1: The most efficient method is agentless backup through the FusionCompute VRM, using a tool that supports the platform's changed-block tracking (CBT). A proper FusionCompute VM backup avoids per-VM agents and lets incremental jobs copy only changed blocks. Vinchin Backup & Recovery supports this model natively for FusionCompute 6.5.1, 8.1, 8.5, 8.6, 8.7, and 8.8.
Q2: Does FusionCompute support changed-block tracking (CBT)?
A2: Yes. FusionCompute supports changed‑block tracking. Starting from FusionCompute 8.7.0, you create a Service Management Port on each CNA host and enable CBT Traffic Management within that port’s connection settings. For earlier releases, CBT works natively without this dedicated port, with CBT traffic transmitted over the management plane.
Q3: How does Vinchin back up FusionCompute VMs without an agent?
A3: Vinchin registers the FusionCompute host through the VRM (under Resources > Virtual Infrastructure > Virtual Platform), rather than installing agents inside each VM. Backups then run at the hypervisor level, and application-aware processing is added for SQL Server and Oracle workloads.
Q4: Can I restore a FusionCompute VM to another virtualization platform?
A4: Yes. Vinchin supports V2V migration across 15+ platforms, so a FusionCompute backup can be restored to VMware, Hyper-V, Proxmox, and others — and VMs from other platforms can be migrated into FusionCompute. Both full and instant restore are available in cross-platform mode.
Q5: How should I schedule FusionCompute backups for best performance?
A5: Use a full-plus-incremental schedule with incrementals daily (or several times per day) and fulls at a lower frequency. Enable CBT, deduplication, and compression; schedule jobs off-peak; and route the backup node's transfer IP over the storage network to avoid saturating business VLANs.
Conclusion
Huawei FusionCompute is a powerful, scalable virtualization platform whose VRM/CNA architecture and native ARM support make it a serious option for enterprises. But its dense, highly automated nature also makes data protection a discipline, not an afterthought.
The most reliable protection comes from a backup tool that speaks FusionCompute's language: agentless integration through the VRM, changed-block tracking through the CNA, and support for the platform's scale and heterogeneity. Vinchin Backup & Recovery delivers exactly this, combining agentless FusionCompute backup, CBT-driven efficiency, application-aware processing, and cross-platform V2V recovery in a single console.
