what is minimum hard drive for OS installation?

[incognitonoobr]

On a newly installed proxmox server i have the following

# df -h
Filesystem                           Size  Used Avail Use% Mounted on
udev                                  32G     0   32G   0% /dev
tmpfs                                6.3G  1.4M  6.3G   1% /run
/dev/mapper/pve-root                  94G  3.9G   86G   5% /
tmpfs                                 32G   46M   32G   1% /dev/shm
tmpfs                                5.0M     0  5.0M   0% /run/lock
/dev/fuse                            128M   20K  128M   1% /etc/pve
tmpfs                                6.3G     0  6.3G   0% /run/user/0

so wondering what the minimum hard drive is for new proxmox OS installations

I am considering installing proxmox on sd card on server and those things are usually like 16GB, so not sure if that is fine for proxmox

 

[leesteken]

I believe the installer refuses anything less than 8GiB, which makes 8GB drives too small. Proxmox itself only uses less than 3GiB in my experience,
However, because of a lot of small disk writes for logging and graphs and such, a USB stick or SD card will wear out and break very quickly.
You could just put Proxmox on a slow hard drive (because it does not really need fast storage) and use the rest of the drive for slow bulk storage. And then use a fast NVMe or SSD for running your VMs and containers.

 

[LnxBil]

What @avw said

However, because of a lot of small disk writes for logging and graphs and such

the "such" part is even more heavy: the sqlite database that is the /etc/pve filesystem.

Just install the OS on the disks you would also use and do not use dedicated disks if possible. The only advantage over same disk is if you plan to reinstall the OS without destroying the VM data.

 

[apoc]

I am running from an 8 GiB Enterprise grade SSD. Had a lot of issues with filling up root after upgrades as PVE does not clean up old kernels.
I have created a script for that purpose. You can find it here:
https://forum.proxmox.com/threads/lib-modules-filling-up-hard-drive.39199/
HTH
/edit: can't recommend USB or SDCards as well as previously stated

 

[incognitonoobr]

yeah issue was i only have 2 x 2.5 SSD for this server, and wanted to have those 2 available for VM storage and put OS on the sd card
they recommend installing hypervisor on these sd card even for enterprise customers, so why cant they make these sd cards to be longer lasting for write operations then?

as you can see in this video, they even do this for enterprise customers, so does not make sense to me
https://www.youtube.com/watch?v=EC-Xntg5mgw

 

[apoc]

ESXi does work fundamentally different to KVM and Standard Linux as well a Hyper-V.
For ESXi this is absolute legitimate option.

And that's why a lot of people (including myself ) just transfer this "knowledge" to other systems, which leads to problems and finally the wisdom you need to adopt.

 

[incognitonoobr]

ESXi does work fundamentally different to KVM and Standard Linux as well a Hyper-V.
For ESXi this is absolute legitimate option.

And that's why a lot of people (including myself ) just transfer this "knowledge" to other systems, which leads to problems and finally the wisdom you need to adopt.

ESXi does not have lots of write operations to the OS drive after install?
What about xenserver? is that a legitimate option to install on sd card also?

 

[Dunuin]

Like already said, don'T install PVE to a USB pen drive or SD card if you don'T want to loose your installation after some months because of a suddenly dying SD card/USB pendrive. PVE will work totally fine with 16 to 32GB of space. So if you share the same SSD (or mirror) with OS and storage for your guests you just loose a few GBs that guests wouldn ot be able to use.

 

[LnxBil]

Had a lot of issues with filling up root after upgrades as PVE does not clean up old kernels.

I does clean it up, but maybe not like you think. It was introduced in PVE 6.x.

 

[Dunuin]

I does clean it up, but maybe not like you think. It was introduced in PVE 6.x.

Jup, I usually run apt update && apt full-upgrade && apt autoremove && fstrim -a to update my PVE server. If you do a apt autoremove from time to time you shouldn't run out of space (except maybe because of logging if oyu don't manually lower the log retention).

 

[apoc]

ESXi does not have lots of write operations to the OS drive after install?

As I have said: ESXi works completely different.
It was developed to run basically from "in-memory".
So the installation media is used during install, when the OS is upgraded or to safe configuration changes. It does no logging at all. That is sent to a datastore (VMFS) or to a syslog-server. So none of that actually goes to the SD-Card.
Thats why a relatively dumb and inexpensive device is sufficient. And if it fails, you only will find out on the next boot.
PVE and all other systems I know work different. Xen also is based on Linux. So I guess it is the same "issue" there.

 

[apoc]

I does clean it up, but maybe not like you think. It was introduced in PVE 6.x.

Hm - I think I have not been precise enough.
/lib/modules was giving me trouble. Not sure if this is still the case.
Anyways

 

[LnxBil]

Xen also is based on Linux.

Even if VMware battled a lot of people in court over this and also won a few, it is lesser and lesser but still based on Linux's ABI, e.g. up to this day, you can compile binaries on your linux host, scp them over to your ESXi and run them. Why should that be possible if it's not the same ABI? The only other systems I know are FreeBSD with its Linuxulator and Windows with its Linux-Subsystem can run linux binaries. Every else will not work, why should it ?????

I can understand why people want to use SD cards ... they're used to it. I am not and I don't miss them. If you build a PVE box with local storage, just install PVE on it, if you run with a SAN, just use SAN LUNs to boot from. You could even just boot PVE via PXE and have the root on NFS... still no SD card involved.

 

[LnxBil]

Hm - I think I have not been precise enough.
/lib/modules was giving me trouble. Not sure if this is still the case.
Anyways

Yes, that's where the kernel modules are stored and they're part of the kernel package that is "rotated" as described above the link. So problem is not as big as it was before. The "older" releases kernels will still pile up, but not every kernel in a release.

On bigger release updates, I also often run orphaner/deborphan to get rid of older and (now) unused packages and kernels, so just do one step more after a new (sub-) release.