Proxmox over Debian installation
- Thread starter Reuven
- Start date
hi,
check with
if you find one, probably you'll need to wipe the disk and its partition table. afterwards it should show up on the GUI.
for wiping the disk just use:
)
hope this helps!
check with
fdisk -l or lsblk -f if you really have any disks you can use.if you find one, probably you'll need to wipe the disk and its partition table. afterwards it should show up on the GUI.
for wiping the disk just use:
sgdisk --zap-all /dev/yourdisk (be careful not to delete the wrong one! )hope this helps!
that one is already used for the root filesystem and is created by default.
could you check the output of the commands i've sent? (you can execute them on the node shell via SSH or GUI). feel free to post them here as well (tip: use
[code][/code] tags when posting the outputs)here it is:
1) lsblk: i: not a block device
2) root@debian2000:~# fdisk -l
Disk /dev/mmcblk0: 115.25 GiB, 123748745216 bytes, 241696768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C098B599-5B64-4A28-9D04-D63039A7115D
Device Start End Sectors Size Type
/dev/mmcblk0p1 2048 1050623 1048576 512M EFI System
/dev/mmcblk0p2 1050624 239695871 238645248 113.8G Linux filesystem
/dev/mmcblk0p3 239695872 241694719 1998848 976M Linux swap
1) lsblk: i: not a block device
2) root@debian2000:~# fdisk -l
Disk /dev/mmcblk0: 115.25 GiB, 123748745216 bytes, 241696768 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: C098B599-5B64-4A28-9D04-D63039A7115D
Device Start End Sectors Size Type
/dev/mmcblk0p1 2048 1050623 1048576 512M EFI System
/dev/mmcblk0p2 1050624 239695871 238645248 113.8G Linux filesystem
/dev/mmcblk0p3 239695872 241694719 1998848 976M Linux swap
Hi Oguz...I posted my reply with the results...what should i do next? also altough we bbought a subscription the server keeps telling me we dont have one
This SD Card is the latest generation...it is very very fast (250mb/sec) and in this project only one VM will be used per server and since the hardware involved (IOT application with a mini Stick PC running proxmox) we have no other disk option and we had to install Debian and on top of it Proxmox unless you allow the Proxmox installation to install on this card.
Like fabian already said, PVE will write every minute to the SD card. Could for example be 30GB per day and normal SD cards got no wear leveling so they might die within weeks or months. So performance isn't the problem, they just can't handle all the writes. Industial SLC SD cards might work, but these aren't cheaper than buying a way faster USB-SSD that would work too.
Last edited:
30GB per day without any VM running. It writes logs, metrics, configs files are written every minute again and again because of clustering and so on.
You can search the forum on how to disable specific PVE services, move metrics and logs to RAM disk and similar hacks to increase the live expectation if you really don't want to use a proper drive.
I think the 30GB was reported with ZFS, which amplifies the problem. we don't do anything special - but PVE has an sqlite DB with writes every few seconds, plus the usual Linux logging, plus some scheduled tasks that cause churn. it's mostly small writes, but if your system suffers from write amplification (like most cheap SSDs), you can easily end up with lots of physical writes even if the actual amount of data that changes is not that much.
I don't have an estimate, since it's very much settings, load and hardware dependent. the 'logical' amount of data written/day on an idle PVE system should be way below 30G.
the usual things people do (if those parts are not needed/used!):
- disable HA services (HA writes at least a timestamp every few seconds to /etc/pve, which is backed by the sqlite DB)
- move logs of the disk (e.g., by mounting a tmpfs on /var/log, setting up networked syslog, ...)
- tune storage layer to improve write aggregation (so that multiple small writes become one big write - that might come with a performance penalty though)
- disable scheduled things you don't use (although that is probably the least concern compared to the other ones)
the usual things people do (if those parts are not needed/used!):
- disable HA services (HA writes at least a timestamp every few seconds to /etc/pve, which is backed by the sqlite DB)
- move logs of the disk (e.g., by mounting a tmpfs on /var/log, setting up networked syslog, ...)
- tune storage layer to improve write aggregation (so that multiple small writes become one big write - that might come with a performance penalty though)
- disable scheduled things you don't use (although that is probably the least concern compared to the other ones
)