AECP Compute Edition runs the AVE hypervisor on the Fibre Channel or iSCSI array you already own. VCFS, a self-developed clustered filesystem built for virtualization, is what makes that array behave like a datastore.

Most VMware replacement plans hide a second project inside the first. Swap the hypervisor, and the new platform often wants its own storage too: a hyperconverged pool, a new array, or a storage model your team has never run. The SAN that is paid for, zoned and well understood becomes a stranded asset, and the storage team becomes the reason the migration stalls.

AECP Compute Edition separates the two decisions. You replace the hypervisor and keep the array, the fabric and the runbooks. This post explains how VCFS, the core component underlying AECP Compute Edition, makes that work, how it differs from the alternatives, and what it does to the cost of leaving VMware.

How VCFS works

VCFS (Virtualization Cluster File System) is Arcfra’s independently-developed clustered filesystem designed for one job: holding virtual machines on shared block storage. Its design deliberately follows VMFS, so the operating model your vSphere team knows carries over.

1. Your array presents a LUN over Fibre Channel or iSCSI, exactly as it would to ESXi.
2. VCFS formats it as a datastore. One LUN per datastore, from 128 GiB to 128 TiB, and the LUN can be grown online.
3. Every host in the cluster mounts it and reads and writes concurrently, each over its own storage path.
4. VM disks are files on the datastore, one directory per VM, much as VMDKs are files on VMFS.

AECP Compute Edition connects to your existing array over iSCSI or Fibre Channel, with redundant switches and multiple paths to both storage controllers. AOC manages the platform layer, and VCFS turns each LUN into a datastore every host can share.

Key Features

Coordination lives on the disk, not on the network

Hosts coordinate through on-disk locks and heartbeats updated with the SCSI compare-and-write (ATS) primitive, the same atomic operation VMFS relies on. VCFS needs no extra Ethernet network between hosts to keep the datastore consistent, and no controller VM.

No I/O detours

Each host sends its VMs’ I/O straight to the array over its own FC or iSCSI path, through a local vhost connection. There is no path where host A forwards I/O to host B. Write access is granted per virtual disk and moves with the VM when it migrates, so data access stays local to wherever the VM runs.

Self-describing datastores

Everything a VM needs to run, including its configuration and disk layout, is stored on the datastore itself. A datastore can be detached from one cluster and mounted by another, and its VMs come with it.

Built to survive failure

Filesystem metadata is kept in multiple copies with checksums and protected by a write-ahead log, so a crash cannot leave the datastore inconsistent. If a host loses its storage path, it fences itself: it resets its outstanding I/O so late writes cannot corrupt data another host has taken over. Lost-path handling follows the all-paths-down and permanent-device-loss model vSphere administrators already know.

Upgrades without I/O stalls

VCFS runs as a user-space service with a hot-standby monitor. If the main service restarts, for a rolling upgrade or after a fault, the monitor takes over VM I/O directly. Running in user space also decouples VCFS from the host kernel version.

Key Advantages: Two teams, one migration

The people who stall a VMware migration are often the storage team, and with good reason: most alternatives take their platform away. With Arcfra Compute Edition, nothing about the array’s operating model changes.

Snapshots on external storage are crash-consistent and file-system-consistent. Arrays keep doing what they already do well, from deduplication and compression to array-based replication.

Why the storage abstraction matters

Every VMware alternative that supports external storage has to answer the same question: how do many hosts share one array safely? There are three different answers, with three different consequences.

A general-purpose cluster filesystem can be made to hold VM disks. It was not designed to, and the failure modes show up in production, not in a proof of concept.

VCFS also keeps the array out of the integration business. It sits on a thin, standard layer between hypervisor and array, so the array needs to know nothing about Arcfra: it presents a compliant block device, and the platform does the rest. That loose coupling, rather than deep proprietary integration, is why a wide range of third-party FC and iSCSI arrays is supported.

Compared with Nutanix compute-only clusters on external storage

Nutanix answers the external-storage question with compute-only AHV clusters backed by an external array. In its Pure Storage FlashArray integration, the constraints land exactly where a SAN estate needs flexibility:

The one-to-one cluster-to-array mapping matters most. With no live migration between storage containers or clusters, an array refresh, a tiering change or a lease expiry becomes a migration project rather than an online operation. Limitations as documented for the Nutanix and Pure Storage FlashArray integration (December 2025); other Nutanix external-storage options have their own requirements.

What sets AECP Compute Edition apart

• Proprietary R&D, full control. VCFS is fully developed in-house rather than built on the OCFS2 code other vendors commonly use, so Arcfra controls its design, its fixes and its roadmap end to end.
• Familiar where it counts. vSphere teams get the constructs and numbers they already plan around: 64 hosts per datastore, file-per-disk VMs and on-disk locking. Datastore layouts and runbooks translate directly.
• Arrays are not a one-way door. One cluster can use LUNs from several arrays, and one array can serve several clusters. A running VM’s disks can move live from one array to another, so an array refresh or lease expiry becomes an online operation instead of a migration project.
• No controller-VM tax. There is no storage appliance on every host. CPU and memory stay with your workloads.
• Any conformant array, no integration module. Compatibility is protocol-driven: any array that presents standard FC or iSCSI LUNs works, with a published support matrix and a self-validation tool. Mixed vendors and generations in one estate are normal, and you are not waiting for your array vendor to build a plug-in.
• The full platform, not a reduced edition. HA with five failure triggers, including storage-link failure, and HA for SR-IOV and vGPU VMs; DRS adapted to external storage; memory overcommit, VM Secure Boot and vTPM; and distributed firewall and micro-segmentation through Arcfra Network Service. All of it runs on AECP Compute Edition, managed from the same AOC console as converged clusters.
• Protection beyond the array. Array snapshots and replication keep working. ABDR 2.5 will add native VM backup and replication for AECP Compute Edition, including synchronous replication with zero data loss. NetBackup, Veeam and Commvault integration is coming soon.

Compared with open-source-based platforms

Open-source KVM platforms are a common first stop after VMware, and they run well on local or hyperconverged storage. Shared FC and iSCSI arrays are where the gap shows, because those platforms lack a VM-native clustered filesystem:

For teams leaving VMware, that gap is the difference between keeping the vSphere operating model and rebuilding it by hand. Proxmox VE snapshot status per the Proxmox VE 9 storage notes and Proxmox staff guidance, October 2026.

Scale and configuration maximums

VCFS matches or exceeds VMFS on the limits that shape datastore design.

Hardware requirements are deliberately light. AECP Compute Edition runs on mainstream x86 servers from any vendor, mixed generations included. It needs no local SSDs because it builds no storage pool, and the node minimum is 12 cores (24 threads), 32 GB of RAM and a 200 GB boot disk. Clusters start at three nodes in 7.0, with single-node and two-node clusters coming in the next release. Any array that presents conformant FC or iSCSI LUNs can be used, with a published support matrix and a self-validation tool for qualifying your own hardware.

What it does to TCO

Keeping the array removes the largest line item in most VMware exits: new storage. There is no storage pool to build, no capacity licence to buy and no storage refresh to schedule alongside the hypervisor change.

The hypervisor software costs less too. In our comparison for a three-node cluster with two 32-core CPUs per node (192 cores), keeping the same external array:

The savings compound beyond licences: no controller VM consumes host CPU and memory, the storage team’s tooling and skills carry over, and arrays are refreshed on their own schedule rather than the hypervisor’s.

Keep the array, change the platform

The hypervisor and the array are two separate decisions. AECP Compute Edition lets you make the first without forcing the second: VCFS turns the SAN you already own into a familiar, VM-native datastore, and the same AOC console manages AECP Compute Edition and converged clusters side by side as your estate evolves.

VCFS 1.0 is the foundation, not the finish line. The roadmap keeps closing the gap to what large SAN estates expect:

• Next release: local disks alongside external storage, shared volumes for clustered databases such as Oracle RAC, cross-cluster migration that moves storage as well as compute, and single-node and two-node clusters.
• Later releases: NVMe over Fabrics for lower-latency array access; array offload equivalent to VMware VAAI, bringing fast and linked clones; NAS datastores over NFS and SMB; raw device mapping; and storage-layer I/O QoS.
• See AECP Compute Edition live at the AECP 7 launch webinar on 9 December, with a demo from the Arcfra Singapore Demo Center.
• Talk to an Arcfra expert about a proof of concept on your own array at arcfra.com.

Replace VMware. Run Private AI. One Platform.