VMware ESX 3.5 ntpdate strangeness
We just noticed that the time was very far off on our sparkly new VMware EXS 3.5 server. When I went to run ntpdate to bring it up to sync, I was suprised to find that it could not make a connection to the time server because outbound UDP 123 traffic was blocked by the internal firewall.
Here is what I got:
/usr/sbin/ntpdate -u time.nist.gov
9 Apr 03:47:53 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:54 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:55 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:56 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:57 ntpdate[20245]: no server suitable for synchronization found
Normally I would just add a rule to the “/etc/sysconfig/iptables” file to allow traffic out on this port, but Vmware ESX server does not use iptables… It uses its own firewall, so I had to figure out how to change it. Happily, it turns out that there is a handy “esxcfg-firewall” command built just for such things.
Running this:
/usr/sbin/esxcfg-firewall -q | grep 123
12300 1803K valid-tcp-flags tcp -- * * 0.0.0.0/0 0.0.0.0/0
Confirmed that UDP port 123 outbound was disallowed.
Running this opened it up:
/usr/sbin/esxcfg-firewall -e ntpClient
Grep out “123″ again just to be sure:
/usr/sbin/esxcfg-firewall -q | grep 123
1 76 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
And you can now run ntpdate to sync up the time:
/usr/sbin/ntpdate -u time.nist.gov
9 Apr 09:52:54 ntpdate[20319]: step time server 192.43.244.18 offset 21689.039217 sec
VMware Fusion Evaluation
Since much of my job involves rolling out Linux solutions I’ve been experimenting with VMware Fusion Beta for the Macintosh in my development environment. Given that the product is still in beta, I have very few complaints about its actual stability. Most of the features work reliably as advertised, but there are some basic points of functionality that I feel the software is lacking. More on that later.
First, let’s take a look at exactly what VMware Fusion is. At its core, the package allows the user to create and run virtual machines on the Macintosh. For those who are new to virtualization, it is a way to run multiple virtual computers on one actual computer. The hardware resources are abstracted and shared to the virtual machines through the virtualization software — in this case VMware Fusion. A complete description on virtualization can be found here.
Previous to Fusion, only VMware player was available to Macintosh users, so it is nice to actually be able to create virtual machines locally. The snapshot feature is also very nice for development purposes since you can instantly roll back to a previous working state should you corrupt the software on the virtual machine.
Perhaps the problem that annoyed me most, however, was the fact that there is no clear way to delete virtual machines from within the software. I actually tried to get rid of one by deleting this folder:
/Volumes/Macintosh HD/Users/myaccount/Documents/Virtual Machines/Mymachine.vmwarevm
But I just ended up breaking the “Virtual Machine Library” application and having to uninstall and reinstall everything from scratch. The process detailing how to delete a virtual machine did not exist anywhere in the VMware Fusion FAQ or documentation as far as I could tell. Granted, it’s beta software, but I would think this should be a core feature of any virtualization product. At least they provide an “Uninstaller” script.
VMware Fusion is a basic piece of software that succeeds in fulfilling the most fundamental of virtualization requirements. If all you want to do is be able to run a virtual machine or two on your Mac, it will most likely work for you. If you are looking to deploy it as part of an enterprise solution, I would suggest letting the product mature a while and using something like Parallels instead.
