[ale] KVM Storage - Seeking advice

DJ-Pfulio DJPfulio at jdpfu.com
Fri Apr 12 11:04:03 EDT 2019


Background
----------
I'm setting up a new KVM VM system. It will run 10-30 VMs, but only 15
will be core.

I've been using KVM + libvirt for about a decade, so I'm fairly
comfortable with it, but have always managed the storage allocations
outside libvirt, as directory pools with raw img files.  A few times,
for non-data VMs, I've used QCOW2 files.  I don't suspend VMs or
snapshot for backups using libvirt. All backups are treated like
physical machines from the inside of the VM.  This has worked very well.

But layering LVM outside the VM and inside the LVM for backup snapshots
always felt .... inefficient.

I want to retain the inside-the-VM backup methods. They are very
efficient and have saved me a few times every year. Bringing up a new
system based on those backups takes 30-45 minutes, which is reasonable.

Seeking Guidance
----------------
I've been looking at using a separate LV for each VM, but don't see what
that buys me besides a little more complexity and block access to
storage from inside the VM, for slightly more performance because a file
system isn't in the middle.  The new storage for the VMs is SATA SSD.
They have been on a RAID1 spinning disk about a decade. I'm comfortable
without the redundancy on the EVO SSD, with backups.

My research this week hasn't shown much greatness in dealing with the
extra LVs. Read about 30 KVM+LVM articles and watched a few conference
presentations about VM storage management.

I must be missing something.  Are there other, single-node, options
worth considering?


Other options
--------------
The last few years, I had been looking at sheepdog as a KVM storage
backend. It is fairly high performance and does N+1 replication across
the nodes, based on the config.  I've decided NOT to replicate storage
in the new setup. Backups have been sufficient for a long time. Only 1-2
of the VMs are important enough that I keep a spare VM on a different
machine ready to boot if they fail.  They've never failed in all these
years.



More information about the Ale mailing list