ESXi 6.5.0 Guest OS errors…
-
"While that doesn't seem like a lot per month, over the course of a year, that's a nice savings that can go to other things :)"
Are you paying this bill? Is this your house or a place of business? Lets call it $50 a month savings.. Or $600 a year… How much does it cost the company when something doesn't come back up and you have people sitting at their desk not able to work?
"Switches (that's about 140w alone),"
What switches are you running that pull 140watts? You running POE? A cisco 3850-48 doesn't even pull 140W under full load.. This doesn't sound like a home setup...
-
FYI- There was a patch for the vga/vt race crash in FreeBSD-CURRENT so be brought it in, if we end up having to rebuild 2.4.0 it may end up in the release, otherwise it will be in 2.4.1 which will be very close behind (a week or two at most).
-
The kern.vty=sc workaround worked for me.
I rebooted a dozen times and didn't see the panic, which is definitely an improvement.
Thanks so much for the workaround and for incorporating the fix!
-
Smoke'm if you got'em?
This is a tangent from the original post, but you can actually get worse performance with additional cores. The way VMware does its scheduling, it will only give a VM a time slice if there are as many cores free as the max defined, regardless of what the VM is currently using. If you have a 12-core box and have defined pfSense as using 8 of those cores, then it's only going to get time when 8 cores are free – even if pfSense is only using 2 for example. Depending on load from other VMs, this can delay a VMs scheduling of CPU time in a detrimental way.
-
The kern.vty=sc workaround worked for me.
I rebooted a dozen times and didn't see the panic, which is definitely an improvement.
Thanks so much for the workaround and for incorporating the fix!
Great news! That's a much better workaround than letting it crash and reboot.
-
@KOM:
Smoke'm if you got'em?
This is a tangent from the original post, but you can actually get worse performance with additional cores. The way VMware does its scheduling, it will only give a VM a time slice if there are as many cores free as the max defined, regardless of what the VM is currently using. If you have a 12-core box and have defined pfSense as using 8 of those cores, then it's only going to get time when 8 cores are free – even if pfSense is only using 2 for example. Depending on load from other VMs, this can delay a VMs scheduling of CPU time in a detrimental way.
Understand, and thank you. I have 16 cores and 48GB RAM for three VM’s. FreeNAS, an Ubuntu web server, and pfSense. The web traffic is minimal and FreeNAS is more static storage. PfSense pulls the greatest load through VPN traffic. Really, it’s massive overkill for all guests. Our encryption settings for a site-to-site trunk are maxed out, so I provide the CPU for OpenVPN.
-
jimp, thanks for looking into the crash so much as well as reporting it :)
So, back to the original posting/question… I guess we will have to wait for FreeBSD to fix the issue then, thankfully the original issue isn't detrimental.
Once again, thanks to all, it's much appreciated. :)
-
Another possible workaround is to set kern.vty=sc in /boot/loader.conf.local since this appears to be a race condition in the VT console, according to the FreeBSD bug report.
I did manage to make one of my VMs crash once, finally.
I opened a bug report for it here: https://redmine.pfsense.org/issues/7925
This bug can also seems to be avoided by using safe mode during install, for those that may be creating a new VM from the ISO.
Interrupt the boot with <space>, then 6 4 1 1.
As you said, to make the workaround persist after the install is complete, invoke a shell and run:
echo set kern.vty=sc >> /boot/loader.conf.local</space>
-
This bug can also seems to be avoided by using safe mode during install, for those that may be creating a new VM from the ISO.
Interrupt the boot with <space>, then 6 4 1 1.
As you said, to make the workaround persist after the install is complete, invoke a shell and run:
echo set kern.vty=sc >> /boot/loader.conf.local</space>
If you are going to that trouble, drop to a loader prompt and run:
set kern.vty=sc bootAlso you don't need "set" in /boot/loader.conf.local, just "kern.vty=sc"
-
I don't think that warning really matters. VMWare is simply not properly identifying the Guest OS but you already manually selected FreeBSD, so the drivers and hardware emulation is accurate. The same occurs when I update to brand new releases of macOS or Ubuntu builds.
I arrived here via Google looking for the answer to this problem and wanted to comment on this because it does matter.
In ESXi you can't do snapshots (or backups via tools like Veeam) unless ESXi thinks the host is in a consistent state. As long as this message appears, ESXi thinks the host is inconsistent, so no snapshots/backups.
-
@El:
I arrived here via Google looking for the answer to this problem and wanted to comment on this because it does matter.
In ESXi you can't do snapshots (or backups via tools like Veeam) unless ESXi thinks the host is in a consistent state. As long as this message appears, ESXi thinks the host is inconsistent, so no snapshots/backups.
I just just took a snapshot of pfSense 2.4.1 CE vm in ESXI 6.5. Whatcha talking about?
-
@El:
I arrived here via Google looking for the answer to this problem and wanted to comment on this because it does matter.
In ESXi you can't do snapshots (or backups via tools like Veeam) unless ESXi thinks the host is in a consistent state. As long as this message appears, ESXi thinks the host is inconsistent, so no snapshots/backups.
I just just took a snapshot of pfSense 2.4.1 CE vm in ESXI 6.5. Whatcha talking about?
I'm running ESXi 6.5.0 Update 1 (Build 6765664). I'm running pfSense 2.4.1-RELEASE (amd64).
ESXi reports "The configured guest OS (FreeBSD (64-bit)) for this virtual machine does not match the guest that is currently running (FreeBSD 11.1-RELEASE-p2). You should specify the correct guest OS to allow for guest-specific optimizations." for my pfSense VM.
If I attempt to take a snapshot of the pfSense VM ESXi errors out with "Failed - The operation is not allowed in the current state."
That's what I'm talking about.
-
@El:
I'm running ESXi 6.5.0 Update 1 (Build 6765664). I'm running pfSense 2.4.1-RELEASE (amd64).
ESXi reports "The configured guest OS (FreeBSD (64-bit)) for this virtual machine does not match the guest that is currently running (FreeBSD 11.1-RELEASE-p2). You should specify the correct guest OS to allow for guest-specific optimizations." for my pfSense VM.
If I attempt to take a snapshot of the pfSense VM ESXi errors out with "Failed - The operation is not allowed in the current state."
That's what I'm talking about.
How do you conclude that one has anything to do with the other? Check vmware.log for details of snapshot request.
-
Just going to bump this as it's still an issue even in 2018.
I'm on Esxi version: 6.5.0 Update 1 (Build 7388607)
PfSense version: 2.4.2-RELEASE-p1 (amd64)The warning keeps appearing every time I go to the "Virtual Machine" section on the ESXI web portal. Here's a screenshot of the bugger: https://image.prntscr.com/image/zN7e5RPmQbCYjVYcv_Qymg.png
It doesn't really seem to hurt anything for me, I can still run all features just fine but it's just a little annoying.
-
It's not a problem in pfSense, it's in ESX and/or the open-vm-tools. The same error happens with a Linux Mint VM. It's trying to be overly specific with the OS full name.
-
It's not a problem in pfSense, it's in ESX and/or the open-vm-tools. The same error happens with a Linux Mint VM. It's trying to be overly specific with the OS full name.
Hmm…Sounds like modifying the Open-VM-Tools to report the OS full name the same as FreeBSD may fix the issue. But I guess it probably won't be worth the effort for a small rather cosmetic issue.
-
FYI- The errors go away with ESX 6.7 and VM version 14 set for "FreeBSD 11 (64-bit)".
So maybe the tools got a little bit ahead of themselves.
