- Can someone explain the difference and the purpose of local vs local-lvm? As far as I can tell local is designed for housing isos, backups, etc while local-lvm is designed for the actual vm images.
- How come they are specific to those purposes? Could you not house isos on local-lvm?
I had a similar question regarding a default ZFS-setup, which might contain additional context for your setup as well:
https://forum.proxmox.com/threads/how-to-properly-configure-encrypted-zfs-storage-only.91573
The important thing to understand is that Proxmox needs to store different types of contents at all and depending on that content, how that content is stored and where it is stored, Proxmox needs to implement support for some features differently or can't provide them at all. Plain ISO images to install OSes from e.g. don't need to support concepts like thin provisioning to grow at runtime, don't need snapshots etc. Those are only files which can easily be stored in any supported file system. And because some file system is always available anyway, that is used as fallback to store anything with less requirements. That's your "local", which is of storage type "dir" and most likely simply maps to the directory "/var/lib/vz" in the end.
Things become more interesting for other types of content, like VM images, containers etc. Especially the former need to support dynamic growth most likely, people want to create snapshots etc. So those requirements make a good different storage type like "images" and "rootdir" in case of containers. You can read about those in the docs:
https://pve.proxmox.com/wiki/Storage
So while content types define some common aspects of functionality, the important part is how to implement that actually. One example is snapshots: LVM and e.g. ZFS support those natively, while a storage of type "dir" used with ext4 doesn't. So what Proxmox does is looking at various possible setups and simply decides which content type is best stored where for which reasons. Afterwards they are trying to make best use of the provided functions of some known storage. Take ZFS for example, which natively supports snapshots instead of ext4. So with content type "zfspool" Proxmox can rely on those snapshots being available and implements VM-snapshots using those instead of requiring one to use the QCOW2 image format and managing snapshots on app level only. While I didn't tested it, it's pretty likely the same with LVM in your case, because LVM supports snapshots on it's own as well.
As always, those decisions come with some restrictions: While LVM is simply not able to store plain files like ISO images and that's why you need an additional storage to do so, in theory ZFS can easily handle block level and files at the same time, because of supporting ZVOLs and multiple different datasets. Though, Proxmox simply decided currently to not allow to store some contents on type "zfspool" and to still require additional storage of type "dir" for those. You can either follow that or simply create a storage of type "dir" placed into some other storage, e.g. a ZFS pool, some file system placed on LVM etc., on your own. Though, in those cases e.g. snapshots are created differently by Proxmox, with respect to NOT know about the type of underlying storage.
In the end, thinking about which types of content one needs to store at all, which features one wants to use with different contents and how one gets those features for some contents makes totally sense. Your setup reflects exactly that, with some decisions making more sense than others, like always.
