VMWare Server
1. Pre-Built images
One CentOS project member formerly offered vmware-images, prebuilt and updated. As of 2012, these are quite stale. See this CentOS bug report for details and the CentOS developer's site to download vmware-images.
2. Changing interface IP addresses in cloned images
When cloning a VMware guest, it will retain the IP configuration details of its parent. To address this and permit it to appear at a different IP, several steps are needed:
edit out the MAC address from the relevant interface configuration file at: /etc/sysconfig/network-scripts/
edit out the retrained state for that MAC address at: /etc/udev/rules.d/70-persistent-net.rules
- restart the cloned image copy, optionally assigning it a specific, and differing MAC address in the VMware server console
amend the details in: /etc/sysconfig/network-scripts/ifcfg-eth0 as appropriate
3. Timekeeping in VMware guests
One of the known problems has to do with the timer frequency set in the kernel. 2.6 kernels request clock interrupts at 1000Hz and it can be difficult for the virtual machine to keep up (see this bug report for details). To remedy this, CentOS used to offer kernels with the clock rate set to 100Hz.
As of CentOS 5.2, a new kernel option called "divider= " was made available. You can set the timer frequency to 100Hz just by adding divider=10 as the kernel option. Unfortunately, in many cases this is barely enough to keep the guest's clock accurate. As of this writing, the best practice for timekeeping is provided in this VMware's KB article:
http://kb.vmware.com/kb/1006427
Below is a brief summary of the instructions adjusted for CentOS:
- Add the kernel options as recommended in the above article. This includes the divider option and clocksource
Edit /etc/ntp.conf as follows:
(add to the top of the file) # modification as per http://kb.vmware.com/kb/1006427 # The configuration directive tinker panic 0 instructs NTP not to give up # if it sees a large jump in time and must be at the top of the ntp.conf file. tinker panic 0 # end of mod (comment out 2 lines as below) # modification as per http://kb.vmware.com/kb/1006427 # It is also important not to use the local clock as a time source, # often referred to as the Undisciplined Local Clock. NTP has a # tendency to fall back to this in preference to the remote servers # The following 2 lines commented out. # when there is a large amount of time drift. # server 127.127.1.0 # local clock # fudge 127.127.1.0 stratum 10
Create /etc/ntp/step-tickers and add these lines:
0.centos.pool.ntp.org 1.centos.pool.ntp.org
If you are using VMware Tools, disable periodic time synchronization.
rpm packages for VMware Tools are available from http://people.centos.org/hughesjr/open-vm-tools/
Vmware also provides prebuild RPMs for VMware-Tools (for ESXi), which they keep up-to-date. The repo can be found at http://packages.vmware.com/tools/esx/latest/index.html (use either rhel5 or rhel6). Even if these RPMs are built by Vmware, they are still recognized as '3rd-party/independent' by ESXi.
4. Change guest VM networking bridge to work across host wireless connection
You can easily change eth0 to a different location so that you don't have to use NAT across your wireless connection. First stop the service vmware, but first make sure all guest VMs are not running.
{{{ # service vmware stop }}}
Next, edit the vmware configuration file and change all instances of eth0 to your wireless connection. In my case, this is eth1.
{{{# vim /etc/vmware/locations answer VNET_0_INTERFACE eth1 answer VNET_0_INTERFACE eth1 }}}
Save and exit this file. Now start vmware services back up.
{{{# service vmware start }}}
You should now be able to bridge across your host wireless and VM with no more fuss. You also don't need to worry about loading any wireless drivers on the guest OS, because it's bridged across the virtual VMware network interface.