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@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?
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@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
