@AyanHM The checkbox is to let Windows also use that network card. If it is a network card that is connected towards the Internet you probably do not want Windows to listen on/use it also. In other words Windows should have its own network card connected to the pfSense LAN and not be connected directly to the Internet.

@swansense You might have been able to just remove the e1000 nic from hardware and then add it back in as virtio without having to recreate the vm. I run pfS on proxmox and i dont bother with nic passthrough. I have a 1Gbps link and I can saturate it no problems. I give my vm 2 cpus and 2gb, all running on an AMD Ryzen 9 Pro 6950H with a few other LXCs (smokeping, pihole).

@SteveITS So I was curious, got a FreeBSD VM running on Proxmox VE, I disabled tablet pointer option, and idle CPU usage went "up". I then disabled it again and there was no change. So either the reported CPU usage goes up for the VM simply by being logged into Proxmox UI, or this option has some odd effect that isnt clear. on its impact. For reference spice is set to none, and I am not logged into the VM, its just sitting idle, and has no desktop package installed. [image: 1775426655395-9d61ef3a-10af-45b5-8255-e393f731fd0c-image.png] Confirmed CPU usage went back down after logging out of Proxmox UI. I now toggled it to disabled, logged out, and idle CPU usage is same as before. So enabled/disabled no change, but VM usage goes up if logged into Proxmox.

It took me 5 years since my original reply but I finally got around to inflating my thin disk and the SCSI errors have gone away! My original reply isn't showing the screenshot any more (it says 'Content not viewable in your region' because I guess Imgur blocked access to UK users apparently) - so here it is again for posterity on a different image host: [image: 153ec5c6-d945-4840-bf1a-ba8b9c14f203.png] For what it's worth to the guys at Netgate, you should write in your documentation that if you're using pfSense on VMware then you should NOT use thin disk provisioning when setting up the VM (use eager-zeroed-thick instead)! There is currently no mention of this on https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-esxi.html Here's the process that I followed to fix it (from my own notes): Preface Since inflating a thin disk requires the VM to be off, and since switching off the router's VM kills routing to vCenter (even via VMware Remote Console) where the Inflate would usually be performed; this solution can be used instead Prerequisites Power off the VM Delete all snapshots (consolidate) Check the size of the the VM's -flat.vmdk file You will need a minimum of this amount of space free, and preferably twice this amount of space free - so that you can do the optional backup step too - E.G. if the VMDK is 100GB, then you'll need at least 100GB free to inflate; plus another 100GB = 200GB free in total, if you do the optional backup step too! Method Read the Prerequisites first! SSH to the ESXi host: cd "/vmfs/volumes/<SOME_GUID_HERE>/RTR01/" ls -lah RTR01*.vmdk* cp RTR01.vmdk RTR01.vmdk.bak Optionally backup the disk: The cp command will backup the disk to a new file - you will need at least TWICE the amount of space free if you're doing this step! cp RTR01-flat.vmdk RTR01-flat.vmdk.bak Monitor progress at: ESXi host > Datastore browser > The volume > RTR01-flat.vmdk.bak > See the file size > Click Refresh on the dialog box's toolbar Continue: The vmkfstools -i command will inflate the disk to a new file - you will need a minimum of this amount of space free! ls -lah RTR01*.vmdk* vmkfstools -i RTR01.vmdk RTR01-thick.vmdk -d eagerzeroedthick ls -lah RTR01*.vmdk* mv RTR01.vmdk RTR01.vmdk.orig mv RTR01-flat.vmdk RTR01-flat.vmdk.orig mv RTR01-thick.vmdk RTR01.vmdk mv RTR01-thick-flat.vmdk RTR01-flat.vmdk ls -lah RTR01*.vmdk* Edit the path to the -flat.vmdk by removing -thick using Vim: vi RTR01.vmdk Go down to the line, optionally press 'i' to enter Insert mode, delete -thick, then save with 'Esc' > ':wq' Power on the VM Confirm routing works properly to VMs Clean up: rm -f RTR01.vmdk.bak RTR01-flat.vmdk.bak RTR01.vmdk.orig RTR01-flat.vmdk.orig ls -lah RTR01*.vmdk*

@coletrain23 Thank you, that did the trick for me !

Since I haven't received any feedback yet, here's a quick update and a more specific question. The cron script using pfSctl -c 'interface reload wan' works reliably and restores connectivity every time the modem reboots. Question: Does pfSctl -c 'interface reload wan' do the same cleanup (like clearing firewall states, resetting connections) as when pfSense detects a real physical link down/up event? I want to confirm this is safe for long-term use and won't deal any strange problems.

@netblues Have you made any progress in solving the problem? To be honest, I don’t remember whether I also tried disabling checksums for the driver in Proxmox. I’ll need to check that… It’s possible that what worked for me only does so in combination with the host settings.

@andydtoma said in pfSense CE 2.8.1 ships FreeBSD 15 qemu‑guest‑agent → ABI mismatch breaks Proxmox integration: pfSense CE 2.8.1 runs on FreeBSD 14.1-STABLE Run uname -a on the command line and if it report 14.1-STABLE then something went very wrong with the update from 2.7.2. 2.8.1 runs on FreeBSD 15-CURRENT. What Proxmox version are you running? I'm on 9.1.1 and the guest agent runs smooth. Memory usage is reported higher with Proxmox 9, as stated in the Proxmox 8 -> 9 Upgrade docu: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#VM_Memory_Consumption_Shown_is_Higher

I found the cleanest way to persist these changes is with the Filer package.

@stephenw10 Thanks for the link, I attempted a update from 2.7.2 to 2.8.1 and this time it seems to be working, updating didn't reproduce the issue. I will do some further testing and see if I can re-produce the problem then report back. Regards

My patch https://github.com/pfsense/FreeBSD-src/pull/57 fixing above redmine ticket (by enabling corresponding driver in kernel config) was merged last month and will be a part of 2.9.0, whenever that comes out.

@geovaneg It may not be related but whilst the PVSCSI is traditionally more performant, i've used the LSILogic SAS controller on my installs without issue. I believe it is also mentioned in the docs.

Hi, I don't know if there's any direct connection, but I decided to mention this issue here because this error message in UNMAP is occurring on the new VMs I'm creating with this setup. I've created a specific thread here: https://forum.netgate.com/topic/198476/unmap-failed-on-boot Thanks, Geovane

@KOM Oh! :) Thanks!