Re: LVM performance vs direct dm-thin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Sun, Jan 30, 2022 at 11:17 PM Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, Jan 30, 2022 at 04:39:30PM -0500, Stuart D. Gathman wrote:
> Your VM usage is different from ours - you seem to need to clone and
> activate a VM quickly (like a vps provider might need to do).  We
> generally have to buy more RAM to add a new VM :-), so performance of
> creating a new LV is the least of our worries.

To put it mildly, yes :).  Ideally we could get VM boot time down to
100ms or lower.

Out of curiosity, is snapshot creation the main culprit to boot a VM in under 100ms? Does Qubes OS use tweaked linux distributions, to achieve the desired boot time?

Back to business. Perhaps I missed an answer to this question: Are the Qubes OS VMs throw away?  Throw away in the sense like many containers are - it's just a runtime which can be "easily" reconstructed. If so, you can ignore the safety belts and try to squeeze more performance by sacrificing (meta)data integrity.

And the answer to that question seems to be both Yes and No. Classical pets vs cattle.

As I understand it, except of the system VMs, there are at least two kinds of user domains and these have different requirements:

1. few permanent pet VMs (Work, Personal, Banking, ...), in Qubes OS called AppVMs,
2. and many transient cattle VMs (e.g. for opening an attachment from email, or browsing web, or batch processing of received files) called Disposable VMs.

For AppVMs, there are only "few" of those and these are running most of the time so start time may be less important than data safety. Certainly creation time is only once in a while operation so I would say use LVM for these. And where snapshots are not required, use plain linear LVs, one less thing which could go wrong. However, AppVMs are created from Template VMs, so snapshots seem to be part of the system. But data may be on linear LVs anyway as these are not shared and these are the most important part of the system. And you can still use old style snapshots for backing up the data (and by backup I mean snapshot, copy, delete snapshot. Not a long term snapshot. And definitely not multiple snapshots).

Now I realized there is the third kind of user domains - Template VMs. Similarly to App VM, there are only few of those, and creating them requires downloading an image, upgrading system on an existing template, or even installation of the system, so any LVM overhead is insignificant for these. Use thin volumes.

For the Disposable VMs it is the creation + startup time which matters. Use whatever is the fastest method. These are created from template VMs too. What LVM/DM has to offer here is external origin. So the templates themselves could be managed by LVM, and Qubes OS could use them as external origin for Disposable VMs using device mapper directly. These could be held in a disposable thin pool which can be reinitialized from scratch on host reboot, after a crash, or on a problem with the pool. As a bonus this would also address the absence of thin pool shrinking.

I wonder if a pool of ready to be used VMs could solve some of the startup time issues - keep $POOL_SIZE VMs (all using LVM) ready and just inject the data to one of the VMs when needed and prepare a new one asynchronously. So you could have to some extent both the quick start and data safety as a solution for the hypothetical third kind of domains requiring them - e.g. a Disposable VM spawn to edit a file from a third party - you want to keep the state on a reboot or a system crash.

_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux