Recent content by datdenkikniet

There's a tip [0] on the wiki, could it be that? [0]: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Upgrade_wants_to_remove_package_.27proxmox-ve.27

Thanks everyone for the pointers :) It works now! I hadn't realized my install was so out of date. Luckily the upgrade went smoothly apart from some hiccups with a DKMS module, but just removing that allowed the kernel upgrade to complete.

The PVE docs indicate that there should be a GET endpoint at /nodes/{node}/lxc/{vm_id}/interfaces [0], but it doesn't seem to be available. I'm currently running pve-manager/7.4-17/513c62be. Is there a reason for this mismatch? Does the endpoint actually exist (I hope so!)? [0]...

What @Neobin said, plus from proxmox to some external (i.e. over the internet) site! There's also a CLI for speedtest.net, if you're feeling adventurous. That way you may be able to figure out "where" the problem exists in the line of PfSense <-> Proxmox Bridge <-> The Interwebz

Have you tried this test from within proxmox by running speedtest over that interface from the proxmox installation itself? It may be interesting to see if that makes a difference, or not. Not sure if it will yield any useful results, but who knows?

OVH: no, I tested on two dedicated computers (but I am doubtful that this is what's causing the problem) Proxmox 7 upgraded from 6.4.13: yes I'm unsure what the issue could be, but it seems like it's related to your specific setup. I noticed this line in the first startup log you posted (which...

You can find the configuration in /etc/pve/lxc/<container number>.cfg. Perhaps the name, a checksum, and/or a link to the container template that you are using would help too, since the one available from Proxmox worked for me, and for Fabian, which could also indicate that you're using a...

I think it would help greatly if you could post the configuration of your container. Perhaps you're using some extra settings/configurations that are (indirectly?) causing this problem. It seems as if systemd is pulling some shenanigans that are fixed by restarting the ssh service.

Aug 03 10:56:02 test login[117]: pam_systemd(login:session): Failed to create session: Seat has no VTs b Could this be a part of the issue? Sounds like pam_systemd can't log you in because no VTs are available. May be related to this, somehow. I've tried creating a new Debian 10.7 container...

In the current configuration your container has no IP configured (since it's set to static but no actual IP and gateway are specified). If you normally assign IP addresses to your VMs with DHCP, switching the configuration to that should solve the issue.

Disabling hardware offloading in PfSense (in "Avanced > Networking"), sometimes helps (also described in this thread). While it seemed to only really help when the virtio driver is used, it might still do the trick

Wouldn't it make much more sense to do benchmarks with workload similar to the one you plan to run on it (e.g. wrk, a HTTP benchmarking tool which seems to be quite well tailored for benchmarking how quickly it can fetch static files), possibly for a longer duration, to test the performance for...

You could try updating your bios for good measure. There seems to be a new version available if the motherboard model is correct. Perhaps it helps (though I'm guessing it's not particularly likely that it will)? Have you verified that your RAM is working OK, too? Also rather unlikely since the...

Oh, I hadn't realized that! Thank you for correcting me there. I guess it may be the kernel buffering the writes then? I was trying to theorize about the 50% memory usage, and subsequent tanking of performance, but I guess I was a bit overzealous lol

Though a little late to the party: The problem is likely to also be solved by disabling "Hardware checksum offloading" (in "Avanced > Networking") in pfSense, since that seems to produce exactly this issue when VirtIO network devices are used. When using E1000 emulation the hardware checksum...