Project source: PureStorage-OpenConnect/pure-hypervisor-integration-framework on GitHub
For most of the last two decades, enterprise virtualization had a fairly predictable center of gravity: VMware.
Storage vendors built deep integrations with vSphere. Backup platforms built around VMware APIs. Migration products commonly approached VMware as a source by reading its virtual disks and moving those blocks somewhere else.
That world is becoming much more heterogeneous.
Organizations are evaluating or deploying VMware vSphere alongside platforms such as Red Hat OpenShift Virtualization, Proxmox VE, XCP-ng, HPE VM Essentials, and OpenStack. At the same time, some of the assumptions behind traditional VMware migration tooling are changing.
In August 2026, Red Hat documented that VMware Virtual Disk Development Kit, or VDDK, images were no longer available to end users through the previous standard public download mechanism. Red Hat said customers needing VDDK must request access from VMware/Broadcom and that it was investigating longer-term alternatives. Significantly, one workaround Red Hat identified was storage offload/XCOPY when the backend storage supports it.
Microsoft’s current Azure Migrate documentation provides another useful example. Its agentless VMware migration appliance requires VDDK, and Microsoft now warns that Broadcom may restrict VDDK download access. Microsoft says organizations unable to obtain a supported VDDK package should use agent-based migration instead.
That situation reinforces an architectural question I had already begun exploring:
What if moving a VM did not depend on extracting its data through the source hypervisor’s virtual-disk SDK in the first place?
That question eventually became one of the most interesting aspects of PHIF — the Pure Hypervisor Integration Framework.
PHIF began with a simpler objective: make it easier to integrate a FlashArray with several different virtualization platforms. But the project evolved into an experiment around three related ideas:
Can hypervisor storage integrations be modular and useful completely independently of the management framework?
Can one capability-driven control plane automate those integrations without becoming a required dependency?
And once those hypervisors share a storage architecture, can the storage hardware itself become part of the migration path?
The answer, at least from what I have built so far, appears to be yes.
Every hypervisor wants storage differently
At first glance, integrating storage with multiple hypervisors sounds primarily like an API problem.
The APIs turned out to be the easier part.
The harder issue is that each platform has its own model of what storage should look like.
VMware has VMFS, vVols, NFS, and RDMs.
OpenStack expects storage through Cinder.
OpenShift and Kubernetes expect CSI.
Proxmox has its own storage-plugin model.
XCP-ng has Storage Repositories and SMAPI.
HPE VM Essentials is built around Morpheus and KVM and exposes another plugin model.
Trying to hide all of those differences behind one lowest-common-denominator implementation would throw away many of the things that make the individual platforms useful.
So PHIF takes a different approach.
It standardizes the orchestration contract, while allowing each platform to retain its native integration model.
The current framework includes integrations for vSphere, OpenShift, OpenStack, Proxmox, XCP-ng, and HPE VM Essentials. It can connect a FlashArray, deploy or configure the appropriate integration for each platform, manage credentials, perform day-2 operations, and coordinate VM migrations.
The goal is consistency for the operator without pretending that the underlying platforms are identical.
A capability-driven architecture
Every hypervisor integration in PHIF is represented by a connector.
The connector tells the framework what the platform supports.
Conceptually, those capabilities include operations such as:
CONNECTDEPLOY_PLUGINCONFIGUREHOST_REGISTERCONNECTIVITYPROVISION_DATASTOREPROVISION_VOLUMESNAPSHOTCLONERESIZEQOSREPLICATIONHEALTHREMOVEVM_INVENTORYVM_LIFECYCLEMIGRATE
The frontend does not need to contain a giant collection of platform-specific conditions.
It does not need to say:
if platform == "vSphere": show these actionsif platform == "Proxmox": show these other actionsif platform == "OpenShift": show something else
Instead, each connector declares what it actually implements, and the interface exposes the appropriate operations.
That sounds like a small distinction, but it changes how the application can grow.
Adding another hypervisor is primarily a matter of implementing another connector rather than changing every layer of the application. The connector registry auto-discovers the available integrations, while common services provide FlashArray access, job execution, secret storage, and log streaming.
Hypervisor integrations
This is one of my favorite screens in the application because it demonstrates the idea visually.
vSphere, Proxmox, OpenShift, OpenStack, XCP-ng, and HPE VM Essentials appear as peers.
Underneath that interface, they are anything but identical.
That is intentional.
PHIF is optional
This may be the most important architectural point in the entire project:
The hypervisor integrations are not dependent on PHIF.
PHIF can install them.
PHIF can configure them.
PHIF can automate their lifecycle.
PHIF can expose their capabilities through a common UI.
PHIF can use them as part of a migration workflow.
But several of the integrations can be installed manually and used directly by the hypervisor without PHIF running at all.
That was deliberate.
I did not want the architecture to become:
Hypervisor | v PHIF | vFlashArray
Instead, PHIF sits above the actual storage integration:
PHIF
|
deploy / configure / manage
|
v
Hypervisor
|
native plugin
|
v
FlashArray
PHIF is an orchestration plane.
It is not intended to be in the VM’s I/O path, and it is not required for the installed storage integration to continue operating.
This means someone can use the pieces independently.
If all you want is better FlashArray integration with Proxmox, you can use the Proxmox plugin.
If all you want is a native per-VDI FlashArray model in XCP-ng, you can use that plugin.
If you want a native FlashArray storage provider in HPE VM Essentials, you can install that independently.
You do not have to adopt the PHIF web application.
You do not have to automate the lifecycle.
And you certainly do not have to use the migration functionality.
That modularity is one of the core design principles of the project.
Proxmox as a standalone integration
Proxmox is a good example.
I built a custom purefa storage type as a real PVE::Storage::Plugin.
It runs inside Proxmox’s own storage framework.
The model is:
one FlashArray volume per VM disk.
Instead of creating one large shared LUN, placing LVM on top of it, and carving multiple guest disks out of that host-side storage layer, each guest disk receives its own FlashArray volume.
Conceptually:
VM 101 |-- disk-0 -------- FlashArray volume A |-- disk-1 -------- FlashArray volume BVM 102 |-- disk-0 -------- FlashArray volume C
Those volumes are presented to the VM as raw multipathed block devices.
Snapshots occur on the array.
Clones occur on the array.
The individual VM disk retains an individual identity on the FlashArray. The current repository describes this same per-disk model for the Proxmox plugin and notes that snapshots and clones are performed on the array.
And none of that requires PHIF after installation.
An administrator can manually install the plugin onto the Proxmox nodes, configure the storage definition, configure multipathing and connectivity, register the hosts with the FlashArray, and operate it directly through Proxmox.
PHIF simply automates those steps.
The distinction looks like this:
With PHIFPHIF | | installs and configures vProxmox | vpurefa storage plugin | vFlashArrayWithout PHIFAdministrator | | installs and configures manually vProxmox | vpurefa storage plugin | vFlashArray
Once installation is finished, the storage architecture is the same.
XCP-ng follows the same principle
XCP-ng required a completely different implementation.
The integration uses XCP-ng’s SMAPIv3 framework and consists of cooperating volume, datapath, and host components.
The volume plugin handles the FlashArray-backed VDI lifecycle.
The datapath exposes the raw multipathed block device to the VM.
The host component handles host-side operations such as cleaning up multipath mappings.
But the storage philosophy is similar to the Proxmox implementation:
one VDI, one FlashArray volume.
That means:
XCP-ng VM | +-- VDI -------- FlashArray volume | +-- VDI -------- FlashArray volume
Snapshots can become FlashArray snapshots.
Clones can become FlashArray volume copies.
The array retains visibility and control at the individual virtual-disk level.
The repository identifies the XCP-ng implementation as a custom SMAPIv3 driver using this one-volume-per-VDI model, with array snapshots and clones, and notes that it has been validated on a live two-host XCP-ng pool.
PHIF knows how to deploy and configure all of those components across an XCP-ng pool.
But again, PHIF is optional.
The plugins can be installed directly on the hosts and used as an XCP-ng storage integration on their own.
HPE VM Essentials follows the same pattern
HPE VM Essentials presented another completely different API surface.
VME uses Morpheus and KVM, so the integration is implemented as a native Morpheus/VME storage plugin.
The plugin registers FlashArray storage inside VME and allows VME itself to drive per-disk operations.
The same core model appears again:
HPE VM Essentials VM | vNative VME storage plugin | vDedicated FlashArray volume
The repository describes the native VME integration as providing per-VM-disk FlashArray volumes, array-offloaded snapshot, clone, and resize operations, and VME-native attachment through its Morpheus plugin interfaces. It has also been validated on a live VME appliance.
PHIF can upload and configure the plugin automatically.
But the plugin can also be built and installed manually.
Afterward, VME talks to its storage plugin directly.
PHIF does not need to remain in the environment.
Existing vendor integrations remain modular too
The same philosophy applies slightly differently to vSphere, OpenShift, and OpenStack.
For those platforms, I did not need to invent an entirely new storage architecture.
OpenStack already has a FlashArray Cinder driver.
OpenShift has a CSI-based model using Portworx.
vSphere has its plugin, VASA, VMFS, vVol, and other native integration mechanisms.
PHIF’s job is to automate and normalize the deployment and configuration of those components.
Once configured, however, OpenStack continues to use Cinder.
OpenShift continues to use CSI.
vSphere continues to use VMware’s storage model.
Again:
the orchestration framework is optional after the integration exists.
That is an important distinction.
I do not want PHIF to solve one infrastructure lock-in problem by introducing another mandatory infrastructure dependency.
The plugins are the foundation; PHIF is the multiplier
I now think about the project as a set of layers.
Layer 1Native storage integration +Layer 2Deployment and configuration automation +Layer 3Lifecycle and day-2 operations +Layer 4Cross-hypervisor orchestration and migration
Layer 1 is useful by itself.
You can stop there.
An organization might install only the Proxmox integration and never deploy PHIF.
Another might run XCP-ng with the custom SMAPIv3 integration.
Another might only want the HPE VM Essentials plugin.
If they later want centralized deployment and lifecycle automation, PHIF can manage those integrations.
If they later want a common operational interface across several hypervisors, the capability model provides that.
And if they eventually want to move workloads between those platforms, the storage architecture underneath those integrations becomes extremely useful.
That progression matters.
Migration is an additional capability built on top of independently useful storage integrations.
The plugins do not exist merely to enable migration.
The PHIF management layer
PHIF itself is intentionally built from fairly conventional components.
The interface is a React SPA.
The backend uses FastAPI.
The application includes an auto-discovered connector registry, a shared FlashArray REST client, an asynchronous job engine, and encrypted credential storage.
Operations can be executed through HTTP APIs, SSH, Ansible, or Kubernetes tooling, while progress is streamed back to the interface.
Conceptually:
+--------------------+
| React UI |
| capability-driven |
+----------+---------+
|
v
+--------------------+
| FastAPI backend |
| |
| Connector registry |
| Job engine |
| Secrets vault |
| FlashArray client |
+----------+---------+
|
+-----------+-----------+
| |
v v
FlashArray Hypervisors
REST / SSH / Ansible /
Kubernetes APIs
PHIF can run with Docker Compose or through Kubernetes/Helm. The repository also includes a mock mode that replaces array and hypervisor I/O so the workflows can be exercised without real infrastructure.
But the application architecture is not the part I find most interesting.
The storage model underneath it is.
Day-2 operations instead of deployment-only automation
Getting an integration installed is useful.
Keeping it useful is more interesting.
PHIF exposes the capabilities each connector implements as day-2 operations.
Operations
Depending on the target platform, those operations can include things such as host registration, connectivity configuration, storage provisioning, snapshots, clones, resize operations, QoS, replication, health checks, plugin deployment, and lifecycle actions.
The repository organizes the UI around six primary workflows: FlashArrays, API keys, hypervisors, operations, migrations, and jobs/log history.
The common interface makes very different systems feel operationally consistent.
But PHIF still does not become part of the storage data path.
It is automating the lifecycle around the integration.
The deployment wizard
Deployment Wizard
A large part of the value of PHIF is simply replacing a collection of platform-specific installation runbooks with a repeatable workflow.
Discover the environment.
Identify nodes and interfaces.
Install the integration.
Configure storage networking.
Register hosts.
Configure the FlashArray relationship.
Validate it.
For someone managing several virtualization environments, that consistency is useful.
For someone managing only one environment, the wizard may be unnecessary.
They can simply perform the same installation manually.
That is exactly the point of making the integrations modular.
Then the storage layer became the migration layer
The migration functionality emerged from the storage architecture.
Once multiple hypervisors can represent their VM disks as independently managed FlashArray volumes, a cross-hypervisor migration starts looking very different.
Traditionally, we tend to visualize migration like this:
Source hypervisor | vVirtual disk | vMigration software | read blocks | transfer blocks | vDestination storage | vDestination hypervisor
The migration system is acting as the data mover.
But consider what happens when both virtualization platforms are attached to the same FlashArray.
The source disk may already reside on the same underlying hardware that will serve the destination.
At that point, copying data through the migration server becomes unnecessary in many cases.
PHIF can instead use the FlashArray as the data-movement layer.
The current migration implementation captures the source VM’s logical configuration, creates a corresponding VM and managed disks on the destination, and then populates those destination volumes using a FlashArray copy-with-overwrite operation. The source volumes remain the source of the data; the large block copy occurs within the storage system rather than traversing the migration host.
That produces a model closer to this:
PHIF orchestration
Source VM Destination VM
| |
v v
Source FA volume -- array copy --> Destination FA volume
|
v
FlashArray
The migration engine coordinates the transition.
The array moves the data.
Copy versus move
PHIF currently supports both copy and move semantics.
In copy mode, the source VM remains intact while PHIF constructs the destination and copies each source volume to a destination-managed volume.
In move mode, the source is shut down first and is removed only after the destination is successfully created and running.
If the migration fails, PHIF can clean up the partially created destination while leaving the source intact in copy mode. The current repository describes that behavior and reports live, boot-confirmed migration testing in both directions across the supported migration platforms sharing one FlashArray.
This distinction is important because “storage-native migration” does not have to mean that the exact same LUN is simply handed from one hypervisor to another.
In the current implementation, a destination storage plugin generally creates a destination-managed volume, and FlashArray performs the volume copy.
That preserves each platform’s ownership and naming model while keeping the heavy data movement inside the storage system.
Migration groups and scheduling
Migration Groups
Once individual VM migration worked, I added orchestration around groups of workloads.
That makes it possible to coordinate multiple migrations using common source and destination context, network mapping, scheduling, and concurrency controls.
At that point, PHIF begins to resemble something larger than an installation utility.
It becomes a heterogeneous virtualization orchestration layer.
But again, that capability sits above the storage plugins.
The plugins can exist without the migration engine.
The migration engine is useful because those integrations already exist.
Why VDDK suddenly matters to this architecture
This is where the recent change around VMware VDDK caught my attention.
VDDK has traditionally provided third-party products with APIs and libraries for accessing VMware virtual disks.
That is useful, but it also creates a dependency.
Consider the architecture:
VMware VMDK | v VDDK | vMigration software | vDestination
If your migration system requires VDDK to read the source disk, then VDDK is part of your migration path.
Its version compatibility matters.
Its licensing matters.
And its availability matters.
That is why the recent VDDK download changes have attracted attention.
Red Hat currently says previous public VDDK download links are no longer active and that end users must contact VMware/Broadcom to request access. Red Hat is investigating alternatives, including storage offload/XCOPY for suitable storage backends.
Microsoft likewise continues to require VDDK for agentless Azure Migrate replication from VMware, while warning customers that Broadcom may restrict package access.
PHIF’s VMware migration implementation does not depend on VDDK.
That was not originally designed as a reaction to the VDDK change.
It is a consequence of using the underlying storage and VMware’s native host tooling differently.
PHIF operates beneath the VDDK abstraction
For PHIF, the interesting object is ultimately the data on the storage system.
A simplified comparison is:
VDDK-centric pathVMDK | vVDDK | vMigration process | vDestination storage
versus:
PHIF storage-assisted pathVMware | vFlashArray-backed storage | | array / host storage operations vDestination hypervisor
The hypervisor APIs are still important.
PHIF still needs to understand the VM.
It needs CPU and memory configuration.
It needs firmware information.
It needs the disks.
It needs NICs and MAC addresses.
It needs destination network mappings.
It needs to create and power on the destination VM.
But the large persistent data set does not have to be extracted using VDDK and streamed through PHIF.
That is the key architectural distinction.
VMware RDMs are straightforward
VMware is an interesting migration source because not every VMware disk has the same relationship with the underlying array.
An RDM already has a direct identity as a storage device.
PHIF can resolve the RDM’s device identity against the FlashArray and determine which volume contains the disk.
Once that association is known, the storage can participate directly in the array-based migration workflow.
Conceptually:
VMware VM | vvirtual-mode RDM | vFlashArray volume
That is already close to the per-volume architecture used natively by the Proxmox, XCP-ng, and VME integrations.
VMFS is the more interesting problem
VMFS is different.
A VMDK inside VMFS is a file.
The FlashArray may contain the VMFS datastore, but there is not a dedicated FlashArray volume corresponding to every individual VMDK.
PHIF therefore needs to transform the storage representation.
For a VMFS-backed source, the current implementation provisions a new FlashArray volume, presents that volume to ESXi as an RDM, and uses vmkfstools to clone the VMDK’s data onto it.
Where the VMware storage path supports it, the operation is VAAI/XCOPY accelerated by the array.
So:
BeforeVM | vVMDK file | vVMFS | vFlashArray datastore volumeMigration preparationVMDK file | | vmkfstools / VAAI-XCOPY vDedicated FlashArray volumeAfterDedicated FA volume | | FlashArray copy vDestination-managed FA volume | vDestination VM
No VDDK is required.
That becomes especially interesting in light of Red Hat independently identifying storage offload/XCOPY as a possible way around its own VDDK dependency.
VMware as a destination
vSphere can also be the destination.
By default, PHIF can create the destination disk relationship using virtual-mode RDMs backed by the dedicated FlashArray volumes.
That retains the direct volume-per-disk model.
If the administrator wants native VMFS VMDKs afterward, PHIF also provides an optional conversion.
That final conversion is different because moving from a raw device into a VMDK inside VMFS requires host-side data movement. The current implementation performs that conversion using VMware storage operations and verifies it before freeing the temporary volumes.
That distinction is important to me.
An abstraction should simplify complexity.
It should not hide where the bytes are actually moving.
Let the hardware do what it is good at
Enterprise storage systems already have extremely capable data-management primitives:
SnapshotsVolume copiesClonesHost mappingsMultipathingReplicationQoSData reduction
We normally describe those as storage features.
But many of them can also become mobility primitives.
A volume copy can be a VM disk-copy mechanism.
A snapshot can be a consistency or rollback mechanism.
Host presentation becomes part of workload attachment.
Storage replication can potentially become part of a future cross-array mobility design.
Once you start thinking about those primitives this way, it raises a useful question:
Why move all of the data through a software migration appliance when the hardware that already owns the data can perform the operation itself?
That is one of the ideas PHIF is exploring.
The source hypervisor no longer owns the entire exit path
I think the VDDK situation highlights a broader issue.
If the process for leaving virtualization platform A fundamentally requires a proprietary disk-access SDK supplied by platform A, then that SDK is effectively part of your portability strategy.
PHIF takes a different approach.
Use the hypervisor control plane for what the hypervisor understands:
VM inventoryCPU and memoryFirmwarePower stateNICsNetworksVM creation
Use the storage system for what the storage system understands:
VolumesSnapshotsCopiesMappingsPersistent data
Then orchestrate the two.
The resulting dependency model looks more like:
Orchestration
/ \
v v
Source hypervisor FlashArray
|
v
Destination storage
|
v
Destination hypervisor
That does not eliminate the source hypervisor.
But it reduces how much the data migration itself depends on a source-specific disk extraction library.
This changes how I think about VM ownership
One of the most interesting outcomes of this project has been conceptual.
We usually draw a virtual machine like this:
VMware VM | VMDK | VMFS | Array
The hypervisor feels like the top-level owner of everything.
But another way to think about the problem is:
VM configuration
|
v
Compute platform
Persistent data
|
v
FlashArray
|
+-----------+-----------+
| | |
v v v
vSphere Proxmox OpenShift
| |
XCP-ng HPE VME
The hypervisor owns the execution environment.
The storage system owns the durable state.
Those responsibilities overlap, and real VM migrations have plenty of complications—boot modes, virtual hardware, disk formats, drivers, networking, firmware, and platform-specific semantics all matter.
But the persistent data does not inherently have to belong to a particular hypervisor.
That idea becomes especially powerful when several hypervisors can consume that data through compatible storage integrations.
Modularity prevents PHIF from becoming another lock-in
There is another reason the standalone integrations matter so much.
A project about reducing infrastructure dependencies should not solve that problem by creating a new mandatory dependency.
I want this to work:
PHIF installed PHIF | +----------+----------+ | | | v v v Proxmox XCP-ng HPE VME | | | plugin plugin plugin | | | +----------+----------+ | v FlashArray
And I also want this to work:
PHIF removed Proxmox XCP-ng HPE VME | | | plugin plugin plugin | | | +----------+----------+ | v FlashArray
The automation disappears.
The storage integration remains.
That gives operators a spectrum of adoption:
Native integration | vAutomated deployment | vAutomated lifecycle | vUnified day-2 operations | vCross-hypervisor migration
Use as much or as little as you need.
What PHIF is — and what it isn’t
PHIF is an independent experimental project.
It is not a supported Pure Storage product, and it is not covered by a support agreement, warranty, or SLA.
That distinction is important because the application performs real infrastructure operations. It can create and destroy array volumes, modify storage connectivity and multipathing, apply Kubernetes components, and create, power off, or delete VMs. The repository explicitly recommends evaluating it in a lab and beginning with mock mode against data you can afford to lose.
The custom Proxmox, XCP-ng, and HPE VM Essentials plugins should be viewed in the same experimental context.
The goal of the project is to explore the architecture and make the code available for others to inspect, test, modify, and hopefully improve.
Where the project is today
At the time of writing, PHIF includes connectors for six virtualization environments: vSphere, OpenShift, OpenStack, Proxmox, XCP-ng, and HPE VM Essentials. The repository reports hardware validation for each integration, and the migration engine has been tested on live hardware between the migration-capable platforms sharing the same FlashArray.
That is already enough to demonstrate the architecture I wanted to explore.
But I think the more interesting part is where the design could go next.
Additional hypervisors can be added through the connector model.
The independent storage plugins can evolve without requiring the PHIF management interface.
Storage-native copy and replication mechanisms could potentially enable broader mobility models.
And because the integrations are modular, someone does not have to agree with the entire PHIF design to reuse one useful part of it.
That is exactly what I wanted.
The larger takeaway
The most important part of PHIF is not the web UI.
It is not the migration wizard.
It is not even the fact that it can coordinate several different hypervisors.
The part I find most interesting is the separation of responsibilities underneath it.
The integrations provide the foundation.
PHIF provides the orchestration.
The storage hardware provides the data plane.
The Proxmox plugin can remain useful without PHIF.
The XCP-ng integration can remain useful without PHIF.
The HPE VM Essentials plugin can remain useful without PHIF.
vSphere, OpenShift, and OpenStack continue to use their respective platform-native storage mechanisms after PHIF configures them.
And when PHIF is added above those systems, it can take advantage of the fact that they share something important underneath:
the data already lives on the same storage platform.
That changes the migration problem.
Instead of assuming that every VM move begins by extracting virtual disks through a source-specific SDK and transferring their blocks through a migration appliance, the orchestration layer can ask a different question:
What can the storage hardware do for us?
The recent VDDK access changes make that question more timely, but they are not the reason I built PHIF this way.
They simply demonstrate why dependency boundaries matter.
A hypervisor should be able to own its execution environment without necessarily owning the only practical path to the workload’s data.
A management framework should be able to automate an integration without becoming required for that integration to function.
And storage hardware should be able to do more than passively serve blocks when it already has the primitives to copy, snapshot, map, and protect the data itself.
That is the architecture PHIF is exploring.
Sometimes a hypervisor migration really does require moving a lot of data.
But when the source and destination share capable storage, the migration server does not always need to be the data mover.
And that opens up a very different way of thinking about virtualization mobility.
Source code, documentation, deployment instructions, connector guides, and the standalone integrations are available here: PureStorage-OpenConnect/pure-hypervisor-integration-framework
PHIF is an independent experimental project. It is not a supported Pure Storage product, is not covered by a support agreement, warranty, or SLA, and can perform destructive infrastructure operations. Test it only in environments and against data you can afford to lose.
vSkeeBall 