Friday, July 28, 2006

Slow Time with FreeBSD 6.1 guest on VMware Server 1.0.0 build-28343

I was prepared to release a new FreeBSD 6.1-based Sguil virtual machine today, but I ran into an old problem. The VMware Server Release Notes say "Full support for 32-bit and 64-bit FreeBSD 6.0 as guest operating systems." I expected that meant the timing problems that had forced me to use FreeBSD 5.x were no longer a problem with FreeBSD 6.x.

Well, today I built a FreeBSD 6.1 guest VM on a Windows XP SP2 host running VMware Server 1.0.0 build-28343. It turns out the guest OS runs at about half speed. I am apparently not the only person with this problem; a #snort-gui regular mentioned running ntpdate every 3 seconds (!!) to mitigate this problem.

I posted this Vmware forum question to see if anyone responds with similar experiences. If you are running FreeBSD 6.x on VMware Server, how are you handling time problems?

17 comments:

Jason Huggett said...

Do they have the VMWare Tools available for FreeBSD? I've had a few similar issues with obscure Linux distro's that were resolved by installing the tools on the VM.

Richard Bejtlich said...

Yes, they are installed but not helping.

Anonymous said...

Richard;

I'm sorry to post without providing an answer to your quesiton, but since you are "THE" FreeBSD guru as far as VMware is concerned, he I am...Do you know if FreeBSD 4.7 will run on VMWARE ESX 2.5 or 3 (or for that matter VM anything!)? I have a requirement to do some development/ testing on that platform and would prefer to use a VM. Any insight you could provide would be greatly appreciated...

Doug

Murali Raju said...

Doug,
VMware ESX 2.5 does not "support" FreeBSD (at least 6.x) and I was not able to boot the VM. OpenBSD 3.9 and -current boots fine and I currently use OpenBSD to do firewall (PF/CARP) and VPN services on ESX 2.5. I am currently testing 3.0, but have not had a chance to install FreeBSD yet, but I will keep everyone posted or you may want to check out the VMTN forums. Again, the lack of VMware tools for *BSD on ESX prevents using the memory/cpu or resource managment features on ESX that are available to both Linux and Windows. Also, Solaris 10 is supported (experimental) and I am not sure why VMware ignores the *BSDs.

Thanks.

P.S I am the one Richard mentions on the post regarding Time Sync issues on *BSD using VMware Server 1.0. You can also check out the VMware white paper regarding Time Sync - http://www.vmware.com/pdf/vmware_timekeeping.pdf for more info.

Chris Buechler said...

FreeBSD 4.x is supported in ESX 2.5, and VMware tools works fine. I believe ESX 3.0 and FreeBSD 4.x should work fine as well, but I haven't yet tried it and have noticed that FreeBSD is no longer available for selection as an OS when you're setting up a new VM.

FreeBSD 5.x and 6.x won't boot in ESX 2.x nor 3.x due to SCSI driver issues. There have been attempts recently to fix this in RELENG_6, but thus far they have been unsuccessful.

Richard Bejtlich said...

I can confirm that using SCSI disks in VMware Server also results in FreeBSD 6.1 not seeing the hard drives when trying to install the OS.

Anonymous said...

On Debian GNU/Linux with the latest stable kernel I'm using the patch vmware-any-any-updateXXX.tar.gz from
http://ftp.cvut.cz/vmware/ to get VMWare working.

See readme.txt

As far as I know, they have patches for 64bit hosts too. However, I haven't tried that one and I also don't know if this works for FreeBSD as well.

Daniel

Richard Bejtlich said...

A responder to my VMware forum question suggested disabling APIC. I'll give that a try.

With VMware Tools installed I think the time loss is acceptable, at least for demos and classes. Therefore, expect to see a public release of a new FreeBSD/Sguil VM shortly.

Anonymous said...

Richard,

Add the following to /boot/loader.conf and reboot: kern.hz="100"

According to the author of this solution it has something to do with the amount of interrupts/second that various kernels generate. Reducing the load creates a work around for the problem.

Richard Bejtlich said...

Anonymous,

Thank you -- that worked perfectly, as far as 20 minutes of uptime shows!

Anonymous said...

Thanks for the fix!

G.

Anonymous said...

kern.hz="100" does not help me and I guess disabling APIC is no acceptable, because VM has 2vCPU on real Athlon64 X2 CPU Linux host.

I tried also:
kern.timecounter.hardware: ACPI-fast, TSC and i8254. All did not help me.

kern.timecounter.smp_tsc=1 I do not know what it is, but I tried and nothing.

In VM configuration file *.vmx:

after reading http://www.vmware.com/pdf/vmware_timekeeping.pdf

I tried executing VM with these 2 params:

monitor_control.virtal_rdtsc = "false" and "true"

monitor_control.pseudo_perfctr = "true" and "false"

My VM os is FreeBSD-6.2-BETA3 and VM Server version 1.0.1 build-29996

without VM tools.

Andy Shellam said...

Hi Rich,

Been following your posts as I've had the same issue with FreeBSD 6.1. I've added kern.hz="100" to my loader.conf and it seems to work better - I'll keep watch!

Responding to an earlier comment you made "I can confirm that using SCSI disks in VMware Server also results in FreeBSD 6.1 not seeing the hard drives when trying to install the OS."

I'm using SCSI disks in VMware Server and not had a problem. I'm running 1.0.1-build-29996 so maybe they've fixed the driver?

Thanks for the help with the time-keeping issue

Andy.

Anonymous said...

The loader line kern.hz="100" worked great for me. I solved the 6.1 problem of seeing the SCSI drives by using the latest snapshot of the OS. It works perfectly now. Now I am going to get it setup as my database server.

Thanks for all the hints and help!

Anonymous said...

I may have another potential solution here. Good luck all.

Anonymous said...

Solutions like the one the previous Anonymous poster suggested will not work; clock drift is not constant under VMware (or any other solution for that matter).

As clockdrift is not constant, determining the 'average' clock drift or the 'actual' clock frequency is not very useful, as these numbers will be bogus.

VMware tries to maintain a proper number of PIT (i8254) interrupts; if it's running behind, it will try to catch up by generating a few more interrupts. Running the VMware tools is your best bet, as (amongst other things) if will correct the clock if it has drifted more than 60 seconds (despite efforts made by VMware to maintain a steady stream of clock interrupts).

dghnfgj said...
This comment has been removed by a blog administrator.