Search results

You are right, that's a typo. I've meant CMR HDDs. SMR should be avoided when using ZFS (and in general...no matter what you are planning to do with them...aren't even suitable as a drive for backups because of the terrible write performance once you try to write more than several dozens of GBs...

Maybe you edited stuff back then when adding that third drive but never rebooted and then a power outage "rebooted" your node? Also not uncommon that a power outage will corrupt your filesystems and PVE then won't boot any longer (thats why you should run your server behind an UPS...even if it...

No, you passthrough the whole HBA with all disks attached to it. Once you passthrough that HBA it is completely managed by the guestOS and the PVE host can't make use of it any longer.

You will have to script something to your needs if you want to backup the system disks to PBS. See my example here: https://forum.proxmox.com/threads/pbs-client-grub-and-just-backing-up-partitions.105990/#post-568579

Looks like you also got a typo when mounting your disks via fstab. "sefaults" should probably mean "defaults" for the mounting options of that ext4 partition. In case you edited your fstab to add a third disk, PVE won'T boot with that 3rd disk missing. So add that third disk or comment out its...

Output of df -h would be helpful too.

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...