Search results

Looks like your host now boots into plain Debian — pveproxy and spiceproxy are missing, which means proxmox-ve and pve-manager were removed during the upgrade. Re-enable the proper PVE repo in /etc/apt/sources.list.d/pve-enterprise.list (or no-subscription repo) and reinstall with apt install...

Hi, it seems to be a Hetzner dedicated server networking issue — very common when users try to add multiple public IPv4 and IPv6 addresses. Some things to note : Looks like you’re assigning the same public IP to both enp4s0 and vmbr1, which confuses routing — only the bridge should hold it...

It seems like the upgrade flipped your host to Debian 13 without a valid PVE repo/key, so APT removed proxmox-ve and friends; then a GRUB 2.12 update + update-grub finished the brick. You might want to try this - Boot the PVE installer in “Rescue Shell”, mount your root, restore proper PVE...

OK, from your latest screenshots, now i see that your setup is already running in vGPU mode — the nvidia-vgpu-vfio messages confirm that the vGPU Manager is active. That means you shouldn’t bind those GPU addresses to vfio-pci; instead, create and assign mdev (vGPU) devices through Proxmox. In...

Hi — this is doable, but you’ll need to treat one interface as WAN and the other as LAN (or “direct”) and have OPNsense route between them (i.e. don’t bridge both blindly). Give each interface its own bridge (vmbrX) on the Proxmox host, map them into the OPNsense VM, and ensure IP forwarding +...

Hi, you’re correct — MTU in Proxmox SDN is currently zone-wide, not per-VNET. This is a limitation of the SDN implementation and underlying OVS behavior. Creating a second zone with a different MTU is indeed the proper workaround for now. Per-VNET MTU support hasn’t been implemented yet but...

You should bind the GPU VFs to vfio-pci (don’t use pci-stub unless you really must). Example for 0000:8c:00.6 (ID 10de:25b6): To bind :- dev=0000:8c:00.6 echo $dev > /sys/bus/pci/devices/$dev/driver/unbind echo $dev > /sys/bus/pci/drivers/vfio-pci/bind lspci -nnk -s $dev # should show: Kernel...

You can also try shutting down all nodes, then start again from node 1 sequentially to node 4. It should work too.

This might be too technical here but... That “visible in LXC, missing on host” almost always means the file was written into the container’s rootfs (the bind wasn’t active at that moment or you wrote to a different path), not the shared host dir. Inside the LXC, run findmnt -T /path/to/shared...

Hi, without more details from you, this error often arises with unstable I/O or storage paths (e.g. USB, remote mounts) and sometimes resolves by switching backup mode or retrying.

Hi, this is likely a Realtek driver issue — RTL8531B uses the r8152 module which can be unstable on Proxmox. Check with ethtool -i enx00e04c680835; if wrong or failing, install r8152-dkms (or r8168-dkms) and test direct IP (no bridge) to confirm. Also try a different USB port or powered hub —...

Hi, -5 typically corresponds to -EIO (I/O error). That suggests the driver attempted to communicate with the device (e.g. via PCI config space, memory-mapped registers, etc.) but something failed at a low level (bus, hardware, MMIO access). In short: the NIC was discovered by PCI enumeration...

Hi, looks like your installer is stuck during USB device initialization — the usb 1-5: device descriptor read/64, error -32 messages usually mean the installer can’t properly read from the USB stick or the USB controller is having trouble. Try creating another USB installer...

This isn’t a Proxmox issue — it’s between Zabbix and the Meraki API. The problem usually comes from API authentication, Org ID, or network/DNS reachability from your VM to api.meraki.com. Start by testing API access directly from the VM with: curl -s -H "X-Cisco-Meraki-API-Key: <yourkey>"...

Hi @FSNaval , i've missed out that you are using NVMe. If you are, using CephFS pool on NVMe will work ok even with metadata heavy. But i will still separate those containers that needs fast disk to use RDB So... If you need shared files (many containers reading/writing the same folder), then...

CephFS works, but it’s metadata-heavy—great for shared POSIX files, not ideal for DB-like/container write-intensive workloads without careful MDS sizing/tuning. To save the trouble tuning and reduce risk, I'll use RBD volumes (fast, block-level).

Safest option: create a fresh empty pool for CephFS.

I normally use NVMe running onboard without RAID because it is already on HA cluster mode for PVE host install for performance purpose. Using SDCard sounds very risky to me.

ZFS “deadman” usually points to I/O stalls — the drives stop responding in time. Are all disks connected through the chipset SATA ports (no port multipliers)? Try checking for slow links with dmesg | grep ata or zpool status -v. Also, any desktop board power-saving (ASPM, C-states) or mixed...

Quick checks: was the bind mount active before file creation? And are your LXCs unprivileged so UID/GID mapping could be hiding the file?