Re: [linux-lvm] LVM performance vs direct dm-thin

From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	Demi Marie Obenour <demi@invisiblethingslab.com>
Subject: Re: [linux-lvm] LVM performance vs direct dm-thin
Date: Thu, 3 Feb 2022 13:28:37 +0100	[thread overview]
Message-ID: <a2786ae3-5339-782f-ae31-5411a7b84bcd@gmail.com> (raw)
In-Reply-To: <YftesLAiW8xoFxqq@itl-email>

Dne 03. 02. 22 v 5:48 Demi Marie Obenour napsal(a):
> On Mon, Jan 31, 2022 at 10:29:04PM +0100, Marian Csontos wrote:
>> On Sun, Jan 30, 2022 at 11:17 PM Demi Marie Obenour <
>> demi@invisiblethingslab.com> 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?
> 
> The goal is 100ms from user action until PID 1 starts in the guest.
> After that, it’s the job of whatever distro the guest is running.
> Storage management is one area that needs to be optimized to achieve
> this, though it is not the only one.

I'm wondering from where those 100ms came from?

Users often mistakenly target for wrong technologies for their tasks.

If they need to use containerized software they should use containers like 
i.e. Docker - if they need full virtual secure machine - it certainly has it's 
price (mainly way higher memory consumption)
I've some doubts there is some real good reason to have quickly created VMs as 
they surely are supposed to be a long time living entities  (hours/days...)

So unless you want to create something for marketing purposes aka - my table 
is bigger then yours - I don't see the point.

For quick instancies of software apps I'd always recommend containers - which 
are vastly more efficient and scalable.

VMs and containers have its strength and weaknesses..
Not sure why some many people try to pretend VMs can be as efficient as 
containers or containers as secure as VMs. Just always pick the right tool...

>> 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.
> 
> Why does a trade-off need to be made here?  More specifically, why is it
> not possible to be reasonably fast (a few ms) AND safe?

Security, safety and determinism always takes away efficiency.

The higher amount of randomness you can live with, the faster processing you 
can achieve - you just need to cross you fingers :)
(i.e. drop transaction synchornisation :))

Quite frankly - if you are orchestrating mostly same VMs, it would be more 
efficient, to just snapshot them with already running memory environment -
so instead of booting VM always from 'scratch', you restore/resume those VMs 
at some already running point - from which it could start deviate.
Why wasting CPU&time on processing over and over same boot....
There you should hunt your miliseconds...

Regards

Zdenek

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