Search results

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

SSDs would, unfortunately, most likely help you greatly here. AFAIK, ZFS buffers writes in RAM up untill it fills up it's ARC (which is set to 50% of total system RAM by default), after which it has to start flushing/writing to the drives. Depending on how you're doing the writes (e.g. if other...

Aha! That does sound like it's more of a pfSense issue than a Proxmox issue, though, especially if the VMs can reach the pfSense machine. How do you connect the physical machines to the virtual bridge? By plugging them/the switch they are connected to into eno1?

I think a more detailed description (in terms of networks and segments) of what you are trying to accomplish would help a lot here. It seems like both your gateways are in the same network (192.168.0.1 and 192.168.0.2 are both in 192.168.0.0/24), but for some reason they are on separate L2...

How do you obtain the IP address? Are you 100% certain that your subnet and gateway are correct? Asking because the VM you are pinging from right now does appear to be able to reach the machine with IP address 192.168.0.253.

Can you clarify "can't get out to public IP 2"? Does L2 traffic propagate to the pfSense VM and is it an L3 issue (you might be able to verify this by checking the ARP tables of either machine), or can traffic from a VM on vmbr2 not reach the pfSense VM at all?