Opnsense (Virtualized) - very high CPU utilization (System Interrupt)

Started by superczar, April 16, 2024, 10:02:51 PM

Previous topic - Next topic
Environment: Running opnsense 24.1.5_3 virtualised on a proxmox 8.1.4 server (i5 9th gen)
NIC: 3X Intel Pro in VirtIO mode (2 WAN, 1 LAN) 1X I219-KM and 2X 82571EB
WAN: 2X WAN in LB/Failover mode - Both PPPoE over fiber (ISP ONU in bridged mode), 1000/500 and 200/100

Issue: System works fine for several hours. After some time though (could be several hours or more), the host (Promox) will start showing high CPU utilisation on opnsense even when idle (20-25%)

Top shows 16-17% utilized by System Interrupts (this is almost exactly equal to 1 of the 6 cores) , user /system utilisation is normal (see screenshot)

Opnsense System> Diagnostics > Activities shows 1 CPU core (core 4) 99-100% utilised by [intr{swi4: clock (0)}]

Any other info: Not sure if relevant but dmesg shows multiple message similar to :
"cannot forward from fe80::ce4:35d8:2fcc:872c to ff02::fb nxt 44 received on vtnet0"

A reboot of the opnsense VM fixes the issue till it recurs again after a seemingly random period of time.

I understand this may not be adequate information to help resolve the problem.
However what I was hoping for is to understand what the probable causes for this could be and what should be the next set of logical tests to run so as to arrive at the potential root cause .
TIA :)

What's your conf file for the VM in Proxmox?


I've been running OPNsense under PVE v8 since last August and apart from a memory issue, which was resolved, it runs without issues. My box is an Intel(R) Core(TM) i3-N305

@Taomyn

Here is the conf file.

i did have opnsense running for 2 years without glitches on proxmox on my primary home server .
I later shifted it to a separate baremetal installation on a different spare machine but found managing / maintaining difficult so reverted it back to a virtualised install on the same spare machine

root@pve:/etc/pve/qemu-server# cat 100.conf
agent: 1
boot: order=virtio0;ide2;net0
cores: 6
cpu: host
ide2: local:iso/OPNsense-24.1-dvd-amd64.iso,media=cdrom,size=1936730K
memory: 8000
meta: creation-qemu=8.1.5,ctime=1712431571
name: opnsense
net0: virtio=BC:24:11:F5:75:A7,bridge=vmbr0,firewall=1
net1: virtio=BC:24:11:B5:8C:CF,bridge=vmbr1,firewall=1
net2: virtio=BC:24:11:C9:2A:EF,bridge=vmbr2,firewall=1
numa: 0
onboot: 1
ostype: other
scsihw: virtio-scsi-single
smbios1: uuid=2976059b-de19-4aa8-bac4-0405ac2b8bc2
sockets: 1
startup: order=1
vga: qxl
virtio0: local-lvm:vm-100-disk-0,iothread=1,size=120G

I don't have access to my system right now, but after a quick look I have one question: how much RAM is the OPNsense GUI reporting? When I first implemented OPNsense in Proxmox, was running it bare-metal on another box before, I had to use the legacy non-UEFI BIOS, I think it's something like SeaBIOS, with ballooning disabled - without this it never saw anything above 2Gb even though I set it to 8Gb for the VM. Now this was with v23 at the time and since upgraded to v24, so perhaps that issue is now resolved.

So here is my conf file, as you can see the BIOS is "seabios" and I have also disabled ballooning - without these the VM would never get more that 2GB RAM and was a known issue at the time I created the machine.


agent: 1
args: -vnc 0.0.0.0:10
balloon: 0
bios: seabios
boot: order=scsi0
cores: 4
cpu: host
hostpci0: 0000:01:00,pcie=1
hostpci1: 0000:03:00,pcie=1
hostpci2: 0000:04:00,pcie=1
hotplug: disk,network,usb,cpu
machine: q35
memory: 8192
meta: creation-qemu=8.1.2,ctime=1701086589
name: BART
net0: virtio=BC:**:**:**:**:**,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
scsi0: local-zfs:vm-100-disk-1,discard=on,iothread=1,size=64G
scsihw: virtio-scsi-single
smbios1: uuid=eea6ccd6-1219-4c51-9197-1ba191093aa5
sockets: 1
startup: order=2
tags: linux;vm
usb0: host=051d:0003
vmgenid: 80e66679-5bdc-4270-93ed-fa9338dbb336



Also of note, the local LAN connection is the only one using a bridge to allow the correct accesses to the main network and other VMs, the other 3 ports are directly passed through to OPNsense so they remain fully under its control.