Search results

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

What ST8000? Something like a ST8000DM004 uses SMR and shouldn't be used with ZFS or any raid or server workload. Write performance of SMR HDDs will drop to a horrible level once the caches got filled up. Especially terrible in case of a resilver where you need to rewrite the wholedisk continously.

You might want to have a look at: https://github.com/openzfs/zfs/pull/15022 https://www.tspi.at/2022/11/26/whynosmrforzfs.html

No, that feature is still not rolled out yet. You will have to wait for it or destroy and recreate your pool. By the way...those HDDs use shingled magnetc recording (SMR) and shouldn't be used with ZFS...or any other server workload... I would recommend you google for the difference between CMR...

For better DB performance you might also want to set the recordsize and volblocksize to the blocksize your DB is reading/writing records. If you want this to persist restores I would recommend to create another dataset and add that as a new storage of type ZFS. Then set the recordsize of that...

Falls du Grub mit dem proxmox-boot-tool nutzt kannst du mit proxmox-boot-tool kernel pin 6.5.13-5-pve den Kernel permanent anpinnen : https://pve.proxmox.com/wiki/Host_Bootloader#sysboot_kernel_pin

Yes, running a PBS VM with local block storage is working. Some years ago when, I was using that, you had to install PBS on top of a Debian VM because the PBS ISO installer wasn't working on TrueNAS Core.

There is a typo: "iface vmdr0 inet static" instead of "iface vmbr0 inet static"

Also bisher durfte man keine Sync Jobs bei den kostenlosen Test Datastores haben. Bei den bezahlten ging es und man musste sich glaube ich dafür an den Tuxis Support wenden. Und soweit ich weiß nur ein einziges kostenloses PBS.

I wrote a hook script as a workaround that will shutdown all VMs sharing a VM, then do the backup job and later start that VM again that got shutdown. That way the backup job won't fail and all VMs will be backed up. But you of cause got downtime as the running VM still needs to be shut down so...

Nicht empfehlenswert, aber ja...geht. Entweder beides Bare Metal parallel (siehe hier: https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-proxmox-ve) oder als VM. PBS als LXC sollte man eher meiden. Ist auch nur ein Klick, aber zu beachten ist, dass du mit PBS keine...

Any PCI passthrough in use for that VM? Because this requires allocating all RAM at start because of DMA.

ESXi is designed for this. PVE isn't.

Ja, dann halt entsprechend weniger VMs starten.

Außerdem mal memtest86+ booten und über Nacht laufen lassen. Systeminstabilitäten sind oft defekter RAM (gerade wenn du kein ECC hast, dass da Fehler gefixt werden könnten) oder defektes Netzteil mit Spannungsschwankungen was dann zum Brownout führt.