Search results

Das zeigt dir aber nur wie voll dein Root-Dateisystem ist. VMs/LXCs liegen üblicherweise auf einem LVM-Thin oder ZFS Pool und die können trotzdem voll sein. Da musst du regelmäßig mit lvs oder zfs list -o space überprüfen, dass das NIE voll wird. Oder besser noch ein Monitoring mit Notifications...

Boot disks don't need performance (even a HDD would do the job). And writes aren't that bad (too bad for pen drives/SD cards but a bigger consumer SSD would do the job) as long as you use a single disk and not ZFS for a mirror. But when using ZFS to mirror your boot disks I would still get...

Yes, not being able to administrate (simple via webUI created) ZFS pools via webUI is quite bad. All those people who wiped their pools accidentally because not understanding what they are doing using CLI. You can't even replace a failed disk of a mirror via webUI and thats even more...

Ein Cluster braucht auch immer Quorum (also MEHR als 50% der Nodes müssen sich sehen) was natürlich nicht gegeben ist, wenn du nur 2 hast und einer warum auch immer nicht mehr erreichbar ist. Dann geht der verbleibende Read-Only und kaum noch etwas geht, weil Quorum fehlt und PVE versucht...

In short: If you need good sync write performance (like running a DB or using something like ZFS that does lots of those) or you are writing much (either big amounts of data like DVR/torrenting) or you got a high write amplification (doing lots of small random writes, nested filesystems, CoW...

Für ZFS solltest du auch nur Enterprise SSDs mit einer Power-loss Protection nehmen. Wenn man da eine M.2 will, dann gibt es da nur eine Hand voll von Modellen von Samsung, Solidigm, Micron und Kingston. Und wenn man 4TB will, dann sogar nur noch 3 Modelle von 550-700€. Und alles über 1TB...

You won't find such things in the webUI. All advanced disk management has to be done manually via CLI and you should know what you are doing. Then your best bet is wiping and reinstalling those nodes.

If the node is using LVM you can't turn it into a mirror. If it is using ZFS you could do that manually via CLI (basically following paragraph "Changing a failed bootable device" but instead of using "zpool replace" a "zpool attach" is used...

Du könntest den Pool manuell per CLI mit "zpool destroy ..." zerstören und den Storage aus der /etc/pve/storage.cfg herauseditieren. Im Normalfall würdest du aber die defekte Disk durch eine neue ersetzen mit einem "zpool replace ..." oder das Raid1 auflösen und mit "zpool detach ..." ein...

Did you try to install the recent PVE 8.2 version in case that problem got already fixed? There are lots of major bugs and vulnerabilities when running that old unpatched PVE 8.0.2. Like corrupting partition tables on guests using SATA and similar.

You could also use ZFS with proper Enterprise SSDs and SMR CMR HDDs. That way you could create your own kind of hybrid storage by using the HDD for bigger data and an partition of your NVMe SSD for storing all metadata and smaller files. Have a look at the ZFS "special" vdevs.

See: https://pve.proxmox.com/wiki/Unprivileged_LXC_containers All users that need to access bind-mounted folders.

Officially recomended is running Docker in a VM. From time to time a PVE upgrade will break docker LXCs. Already happended multiple times in the past. So if you want your docker services to be reliable, use a VM even if that got more overhead. Highest to lowest isolation: VM > unprivileged LXC...

Ja, läuft solange beide IMMER laufen. Dann hast du ja noch 2 von 2 Votes und damit ÜBER 50% der Votes und Quorum. Ist einer von beiden warum auch immer nicht erreichbar, dann hat der verbleibende nur noch 1 von 2 Votes, damit nur 50% der Votes, Quorum fehlt und der verbleibende Node macht dicht...

Cluster braucht immer 3 Nodes, nicht nur bei HA. Hast du nur 2 Nodes darfst du keinen von beiden ausschalten/neustarten weil der andere dann auch nicht mehr funktioniert (PMXCFS geht read-only und lässt keine Änderungen mehr zu und Dinge wie VMs starten wird fehlschlagen), da dir dann Quorum...

LXCs do use datasets, so there is a lot to optimize and the stuff mentioned in the link will be valid too:

So only LXCs with datasets in use and not VMs with zvols. So see the link above on how to optimize datasets for MySQL.

Bad RAM means you maybe now got corrupted data on disk. Wouldn't be the first time reading here that the /etc/passwd or /etc/shadow corrupted preventing logging in.

You can't share a disk between two OSs. If you do that you will corrupt the data on it unless you use some cluster-aware filesystem (which ZFS isn't). So don't try to mount a disk on the PVE host that you already passthroughed into a VM.

Should be 16K volblocksize + 16K recordsize for MariaDB. Old PVE installations defaulted to a 8K volblocksize + 129K recordsize and new instalations to 16K volblocksize + 128K recordsize. So you might want to check that the zvol containing your DB via zfs get volblocksize,recordsize. You might...