New Technical Bulletin: How KVM and QCOW2 Work Under the Hood in Private Cloud Director

Press Release

We just published a new technical bulletin that breaks down the architecture behind Private Cloud Director - specifically how KVM, QCOW2, and the storage layer work together (and independently) compared to the tightly coupled vSphere stack most VMware teams know.

If you're evaluating VMware alternatives right now, this is the kind of detail that matters when you get past the feature checklists and start asking how things actually work underneath.

What the Bulletin Covers

The core idea is straightforward: in a vSphere environment, ESXi, VMDK, and VMFS are deeply interdependent. Each layer requires the others. Private Cloud Director takes a different approach - KVM, QCOW2, and the underlying storage are independent components that don't depend on each other to function.

The bulletin walks through what that actually means in practice: how QCOW2 differs from VMDK as a disk format (single file, self-describing, no filesystem dependency), how Private Cloud Director handles storage coordination without a proprietary clustered filesystem, how enterprise arrays from NetApp, Pure Storage, Dell EMC, HPE, and others integrate through open Cinder drivers maintained by the storage vendors themselves, and how vJailbreak handles the one-time VMDK-to-QCOW2 conversion automatically during migration.

It's a practitioner-level read. If your team is the one who'll be validating a platform before signing off, this is written for you.

Read the full bulletin here.

Integration Questions Worth Asking

Whether you're looking at Platform9 or any other alternative, the architecture underneath matters - especially when it comes to how the platform integrates with the storage, backup, and operational tooling you already have. Here are a few questions worth bringing to your next vendor conversation:

1. Does the platform require a proprietary filesystem between the hypervisor and your storage? If so, what does that mean for capacity expansion, array compatibility, and your ability to access VM data independently?
2. What disk format does the platform use, and can you read it with standard tools? You should be able to inspect and manipulate VM disk images without vendor-specific utilities.
3. Who maintains the storage drivers - the platform vendor or the storage vendor? There's a meaningful difference in feature depth and update speed.
4. Can you access VM disks independently of the management plane? If the management server goes down, can you still get to your data?
5. What happens to your workloads if you need to leave? Ask whether your data is stored in portable, non-proprietary formats - or whether you're signing up for a new kind of lock-in.
6. How does the migration path actually work? Is conversion automated? Does it support warm migration? What happens to the source environment?
7. Where does encryption at rest live in the stack? Is it tied to the disk format, the filesystem, or the storage layer - and does it introduce new dependencies?

These aren't gotcha questions. They're the kind of thing that separates platforms you can live with for five years from platforms you'll be migrating off of in two.

Resources

Questions about how this maps to your environment? Reach out - we're happy to talk through it.