One box, two philosophies: should storage or virtualisation be the foundation?

Someone with one server and several jobs to do eventually meets this fork. On one side are systems built around an array, where running virtual machines is a feature. On the other are systems built around a hypervisor, where storage is a subsystem. Both work. People are happy on both.

The useful question is not which is better. It is which layer you want underneath the other, because that decides what you can replace later without rebuilding the machine.

What "foundation" actually means here

The foundation is the layer that keeps running when the other one is being worked on. That is the whole difference and it is easy to miss while comparing feature lists.

If storage is the foundation, the array survives your experiments with services. You can break a container at two in the morning and your files are untouched, because the thing holding them was never involved.

If the hypervisor is the foundation, the machines survive your experiments with storage. You can add a pool, move a disk, or replace a storage backend, and the machines carry on as long as their own disks are reachable.

Neither ordering protects both. You are choosing what you want to be the boring, stable thing.

The question that actually decides it

Not "what do I want to run", because both answers run everything. Ask instead: what is this machine for on its worst day?

If the honest answer is "it holds things I cannot lose, and it also runs a few services", storage wants to be the foundation. The service side will be adequate rather than deep, and that is the correct trade because the array is the point.

If the honest answer is "it runs things people depend on, and it also stores their data", the hypervisor wants to be the foundation. Storage will need assembling instead of arriving finished, and that is the correct trade because uptime of the services is the point.

Most disappointment comes from picking the second answer and expecting the first system's storage experience, or the reverse.

Where each side actually costs you

Array first. The virtualisation side is real but shallower. Snapshot integration with the guest, live migration, granular per-machine backup scheduling and hardware passthrough all exist to varying degrees, and all of them are easier on the hypervisor-first side. If your virtual machines are two utility boxes, you will never notice. If they are eight production services, you will.

Hypervisor first. Storage arrives as parts, not as a finished product. You pick a layout, you decide on redundancy, you set up scrubs and monitoring, and nothing offers you a friendly wizard for "just make me a share". The flexibility is genuine and so is the assembly time.

⚠️ Both sides make a reboot expensive, and this surprises people who assumed the array-first choice protects them. A kernel update takes down the machine either way, and everything on it. Foundation is about what survives your *changes*, not about what survives a restart.

The hybrid, and the failure mode it adds

A very common arrangement: run the hypervisor as the foundation, then run a storage-focused system as a virtual machine on top, passing the disks through to it.

This works, it is popular, and it genuinely gives you both experiences. It also introduces a dependency that did not exist before: your files now require a virtual machine to boot. If that machine fails to start, the storage is not merely slow, it is absent, and everything that mounts a share from it fails at once.

That is an acceptable trade if you know you are making it. It becomes an unpleasant surprise if you discover the dependency during an outage. Two habits make it safe: keep the hypervisor's own boot disk entirely separate from the passed-through disks, and make sure at least one recovery path does not go through that machine.

What does not decide it

Raw performance numbers. On one box, both approaches sit on the same hardware and the difference in practice is usually smaller than the difference between two storage layouts on the same system.

Which one is easier to install. Installation happens once. The thing you live with is the second year, when you need to change something.

What is more popular for your specific use. A well understood setup you can repair beats a better setup you cannot.

What Atlas does

Atlas does not turn Proxmox into a storage appliance and it does not pretend the assembly step disappears. What it does is make the assembled result readable, which is where the hypervisor-first side is usually hardest.

The resource chain is drawn from each machine down to the physical disk, so the arrangement you assembled is visible as a picture rather than remembered as a decision. On the storage-first side that picture is implicit because the array is the product; here it has to be shown, and showing it is the point.

Storage work goes through a guided flow with an operation preview and a way back, across ZFS, LVM and Btrfs. That does not make the choice for you, and it is not meant to: it makes the choice you made inspectable afterwards, which is the part that decides how the second year goes.