Announcement

New LTS for FreeBSD is now available in an initial release  Learn More

Klara
Use case · Virtualization & VM Storage

Storage that keeps up with your virtual machines

Klara tunes OpenZFS and FreeBSD for hypervisor workloads: bhyve, KVM and beyond. From pool layout and block size to caching and drive choice.

Built on
Who it's for
A grid of glowing, glass-like blocks stacked side by side, each one a separate unit
Common ZFS VM Storage Problems

VM storage punishes early decisions

Most VM storage performance is decided before the first guest boots: the pool layout, the drives, and how guest disks are stored.

Latency spikes under mixed VM load

When dozens of guests share one pool, their small synchronous writes queue up behind each other. Without the right pool layout or a proper SLOG device, one busy VM can slow down every other guest on the host.

Pool and disk choices that are hard to undo

ZVOLs or datasets, volblocksize, mirrors or RAID-Z: these are set when the pool is built. Changing them later usually means migrating every guest off the host first.

Hardware that holds ZFS back


Consumer SSDs without power-loss protection, too little RAM for the ARC cache, or a RAID controller instead of an HBA can quietly cap performance, however well the software is tuned.

How Klara helps

The services behind this solution

Each links to the full service page.

ZFS

ZFS pool layout, drive selection and redundancy for VM hosts. We size mirrors or RAID-Z, SLOG and L2ARC around how many guests you plan to run.

ZFS

A ZFS performance audit for VM hosts already in production. We trace where storage latency comes from, from the ARC to the disks, and give you a ranked list of fixes.

FreeBSD

Performance tuning for bhyve hosts on FreeBSD: kernel settings, storage controllers (VirtIO vs NVMe) and ZVOL vs file-backed guest disks.

Support

Ongoing ZFS support from the engineers who work on OpenZFS, for when a VM host misbehaves at 2am.

How a ZFS VM storage engagement works

From audit to handover in three easy steps

1

Audit your current VM hosts

We start with your hosts as they are today: hypervisor (bhyve, KVM or Proxmox), guest count, ZFS pool layout, drives and RAM. We find where the latency actually comes from and agree on what “fixed” means before we touch anything.

2

Deisgn or tune your ZFS storage

On a new build, we size the pools, choose between mirrors and RAID-Z, pick the drives and set recordsize or volblocksize for your guests. On hosts already in production, we tune what’s there and flag which changes need a maintenance window.

3

Benchmark and handover

We benchmark against your real VM workloads, not synthetic numbers, and walk your team through the results. You keep the documentation, including why each setting was chosen.

Get started

Get your VM storage reviewed by ZFS engineers

Tell us what you run and where it hurts. Our teams have a 72h response time, so someone will reach out shortly.

Production down right now?