You may want to install ESXi on the host server instead of fighting VMware Server. I have installed VMware Server 2.0 for 4 different clients on Windows 2003 and Ubuntu 8.10 host OSes. The hardware was simliar to to yours in that we were using 7200RPM SATA drives on a PERC RAID controller. When we tried running SBS 2003 and Windows 2003 guests on it the IO performance was atrocious (in the sub 10MB/sec category). When we installed ESXi and migrated the guest OSes on it IO performance jumped to 90MB/sec and the results were much better.
I don't know how flexible you can be with the OS on that server but you may end up saving much more time by just moving to ESXi.
It should 'just work'. Even though the vm has no dedicated physical hardware, it still has access to several very good sources of randomness. For example, it can use the CPU's TSC to time its read from virtual disks, which will ultimately wind up timing physical disks to the billionth of a second. These timings depend on turbulent airflow shear in the hard drive, which is unpredictable.
Similar logic applies to network traffic. Even though the interface is virtualized, so long as the packet originates on a physical network (and isn't local to the box, say originating in another vm), the packet timing depends on the phase offset between the crystal oscillator on the network card and the crystal oscillator that drives the TSC. This is dependent on microscopic zone temperature variations in the two quartz crystals. This too is unpredictable.
If for some reason it's not working, the simplest solution is to write a program to mine entropy and add it to the system pool. The network interface is your most reliable source. For example, you can write code to:
1) Query the TSC.
2) Issue a DNS query to a server known not to be on the same physical machine.
3) Query the TSC when the query completes.
4) Repeat this a few times, accumulating all the TSC values.
5) Perform a secure hash on the accumulated TSC functions.
6) Pass the secure hash function's output to the system's entropy pool.
7) Monitor the entropy pool level, and wait until it's low. When it is, go back to step 1.
Linux has simple IOCTL calls to add entropy to the pool, check the pool's level, and so on. You probably have rngd
, which can take entropy from a pipe and feed it to the system pool. You can fill the pipe from any source you want, whether it's the TSC or 'wget' requests from your own entropy source.
Best Answer
Generally there's no need to optimize Windows 7 Virtual Machines. Unlike previous Windows releases it's pretty smooth right out of the box as long as it's got at least 1Gb RAM allocated. I'm using Windows 7 x64 under VMWare Fusion on OSX and it's blisteringly fast.
We run a lot of Windows VMs for software testing on a dedicated ESXi machine (about three each of 2000/XP/Vista/2003/2008/2008R2/Vistax64), so I can provide a few tips that apply Windows VMs in General.
My experience is only with the VMWare family of virtualization products (Workstation, Server, ESXi and Fusion) and I haven't come across any issues with Windows 7. I'd suggest downloading the VMWare Workstation and seeing if there might be a bottleneck somewhere with the VirtualBox implimentation.
Remember, system requirements for Win7 states a minimum of 1Gb RAM. Minimum. Performance is good with 1Gb, but give it less and you're asking for trouble.