Search results

Anything in the logs? (journalctl -e)

Your first VM has 'OVMF' configured but no efidisk. Please add one and try again. ("Hardware -> Add -> EFI Disk")

For best performance on Ryzen, I'd recommend aligning your core layout to the physical layout of the CPU cores - that is, your CCX and CCD configuration. Check that with 'lstopo'. For a 12 core chip that probably means either 2x6 or 4x3, meaning your layout should work in counts of 3. Setting...

This would indicate a failure in 'pvestatd'. This can have many reasons, often it is (network) storage related. Check the logs ('journalctl -e') on the affected node.

DHCP is not recommended for bridges on PVE. You can configure it via /etc/network/interfaces if needed (just like on regular Debian), but in general it is discouraged. You can configure a static IP on PVE and also reserve it in your router's DHCP server or assign a static IP outside the DHCP...

PVE 7 switched to cgroups v2, so the bad news is that 'cset' doesn't work anymore. But the good news is that systemd can do it natively now: sudo systemctl set-property --runtime -- user.slice AllowedCPUs=0-7 sudo systemctl set-property --runtime -- system.slice AllowedCPUs=0-7 sudo systemctl...

Could you try rebooting the machine and choosing a different kernel version on your bootloader prompt? It may be a regression in the new 5.11 kernel.

Right, JBD2 is attributed to ext4, and dm-7 seems to point to your root drive, so... bad root disk? nvme6n1?

Okay, then I'd recommend skipping the ISO step. The VM disk contains the data necessary to run the system, not install it. Just 'dd' the VM image to the target drive and boot from that in the physical environment. Bar any driver/compat issues, this should work fine.

What is your goal here? Do you want to transfer a VM to a physical server?

The question isn't "how can you get the load average lower", but rather "what problems do you see with a high load average". In general, provisioning a machine to the max should not cause any issues - VM processes are time-sliced, so every VM should get it's share of performance according to...

Because how would it know that the filesystem is busy? A block device can be accessed by multiple clients at once, this is intentional. The filesystem on it keeps track locally (that is, within the kernel) that it doesn't get mounted twice, but the two mounts don't happen locally - one's in a...

Both messages are normal. What exactly happens when the system becomes unreachable? Does only network connectivity go down? Does the entire box hang (i.e. can you still type commands physically)? pveversion -v? Note that GPU passthrough can lead to instability at times, maybe try running...

Host only, kernel drivers are shared. Keep in mind that using a GPU inside a container is rather tricky to get right, and can only be used for transcoding etc..., not a full display output.

I would check if your hardware is ok... This message usually indicates a failed disk. Can you also post lsblk and cat /etc/pve/storage.cfg output? What storage technology are you using?

Is the dataset still mounted? Check with zfs mount or just mount.

Try running a traceroute, or check iptables/routers on all involved machines. Running tcpdump -i any port 25 might also help, run it on all involved machines along the way and see where the packet stops. Aside from that, maybe stop using telnet? SSH does exist, is supported, and much more secure...

AFAIK thunderbolt passthrough is not supported. I believe this has to do with the out-of-band thunderbolt communication via it's own protocol, which is not passed through to the VM. Does the eGPU work on the host?

'amdgpu' is included in our kernel, no need to install anything. passthrough to container is a rather tricky business, but it does not require seperate drivers in the container.

Yes, you can either use containers or disable "KVM hardware virtualization" in the VM options after creating it via the GUI. This will allow you to run a VM without VTx/SVM, albeit *very* slowly.