Hi, I setup four 4.9-RELEASE installs under ESXi 5.0.0:

amd64 as "Other"
amd64 as "FreeBSD"
i386 as "Other"
i386 as "FreeBSD"

All 4 got 512megs of RAM, unlimited use of the 8 available CPU cores, and totally default installs other than stress from ports.

After installing I ran "stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --hdd 4 --hdd-bytes 128M --timeout 60s" in an infinite loop for a few hours. Then I let them sit for a couple days. Then I the stress loops again for a few hours with 3 days of uptime. I verified the stress was pegging 95%+ of all CPU, doing about 75% of what the RAID array is capable of in disk read/write, and as much RAM as I'd let it have -- all verified using ESXi's standard host monitoring.

At the end of testing, I have no unusual messages in dmesg, a normal 0.5ish load when idle, and no noticed performance issues on all four virtual machines.

The ESXi host is a 3.5 year old SuperMicro server from Penguin Linux with 2xXeon X5365s, 32Gigs of ECC DDR3, and an Adaptec RAID controller. I can get a real dmesg out of the ESXi host if anyone wants it, and someone already provided a dmesg of 4.9-RELEASE under VMWare, but I can also provide those if desired.

I will leave these VMs around for at least a couple weeks so feel free to ask if you would like me to do anything to help troubleshoot the problem you're having.

It seems to me that running OpenBSD under virtual environments does not get a lot of attention (largely for obvious security reasons, I'd guess), but ESXi is an important part of the systems I manage and am happy to help as best I can with anything VMWare related.

On 10/28/2011 9:15 PM, Gene wrote:
I was wrong, just changing the guest OS type did not fix my problem.
The morning following this email I found the CPU being pegged again.

I ended up installing the i386 version of 4.9 and used FreeBSD 32-bit
as the guest os type.  These VMs have been running for four days
without a problem.  If it occurs again I'll try the other suggestions
provided here.

-Gene

--
Tyler Morgan
Systems Administrator
Trade Tech Inc.

Reply via email to