From: "Yanni M." <gianni.milo22@gmail.com>
To: Proxmox VE user list <pve-user@lists.proxmox.com>
Subject: Re: [PVE-User] Guest LVM2 overhead/usefulness for thin storages (Ceph, ZFS)
Date: Wed, 30 Jun 2021 14:40:06 +0100 [thread overview]
Message-ID: <CACzVk9XJ33dw1_hWeP52625yQvpUyzJ7urT=F-TM_cpZL=pGzg@mail.gmail.com> (raw)
In-Reply-To: <20210630092847.GG3262@sv.lnf.it>
Personally I favor the flexibility that LVM offers when it comes to
creating/resizing volumes (growing/shrinking), most of times without even
needing to reboot the vm. Even if it's possible to do the same with disk
partitioning, it's not as trivial as with lvm (hence why it was invented in
the first place). Having to create a new vdisk on the host for each
individual volume that you might need for the guest in the future - even
though possible - it does not look as clean solution as doing all these,
with lvm, within the guest. The overhead of the lvm is minimal and the
discard/trim should be already enabled by default. Special care should be
taken when using ThinLVM to avoid situations where the pools get full etc
(same apply when used at the host level). Apart from that, it does not
require any special administration skills, apart from familiarity with lvm
tools obviously. To be clear, I'm not defending lvm in here. Both your and
this method are ok. It's all about with what each person is familiar with
and how each organise their work.
On Wed, 30 Jun 2021 at 10:29, Marco Gaiarin <gaio@sv.lnf.it> wrote:
>
> A collegue here came from the old school of 'LVM everything', that
> surely make sense for 'phisical servers'.
>
> Also, point me that make sense also for some 'virtual servers' (or
> better, 'virtual storage') setup.
> EG, considering a SAN, splitting virtual volumes in predefined chunks
> (1/2TB) and 'recombine' them via LVM in the guest, permit to move
> around smaller volumes, transparently for the guest.
>
>
> But if we came to 'modern', thin storage, like ZFS or Ceph, this still
> make sense?
> Seems 'no' to me, seems to me only useful to add another layer of
> abstraction... and the same functionality can be achived splitting data
> in virtual disks as if was volumes, format with a single partition per
> disk, and eventually extend the disk...
>
> And, this layer, how does it 'cost'? Not only in the term of
> performance, but also functionality... eg, 'trim' can traverse correctly
> all the layers?
>
>
> I hope i was clear. Thanks.
>
>
> PS: i've tried to look at the wiki but found nothing; if i've missed
> something, point me to the doc!
>
> --
> dott. Marco Gaiarin GNUPG Key ID:
> 240A3D66
> Associazione ``La Nostra Famiglia''
> http://www.lanostrafamiglia.it/
> Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento
> (PN)
> marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f
> +39-0434-842797
>
> Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
> http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
> (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
>
> _______________________________________________
> pve-user mailing list
> pve-user@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user
>
>
prev parent reply other threads:[~2021-06-30 13:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 9:28 Marco Gaiarin
[not found] ` <mailman.131.1625054872.464.pve-user@lists.proxmox.com>
2021-06-30 13:07 ` Marco Gaiarin
2021-06-30 13:40 ` Yanni M. [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACzVk9XJ33dw1_hWeP52625yQvpUyzJ7urT=F-TM_cpZL=pGzg@mail.gmail.com' \
--to=gianni.milo22@gmail.com \
--cc=pve-user@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox