Debian comes with VmWare tools. Dont bother installing/compiling the version that comes with VmWare.
First you need to activate the “contrib” packages in Debian.
$ sudo vi /etc/apt/sources.list
Add “contrib” to each line beginning with “deb”.
Now installing VmWare tools is as simple as
$ sudo apt-get update
$ sudo apt-get install open-vm-tools
Done! No restart needed.
The following observations are made on VmWare Server 2.0.2, with Debain 6.0 Host and Windows 2008R2 Guests, all systems being x64. The host has a Core2Quad CPU and 8GB of RAM.
A previously healthy environment turned very slow after setting up another Windows guest on the same host. The Windows guest system “felt slow” in the way that the GUI froze for seconds, and that loading times were very slow. The Linux host appeared healthy (immediate command line response, no swap usage, plenty of disk available). The top command revealed very high “waiting time”. I first interpreted this as an I/O problem… but it was not.
The three Windows guests all had 2 virtual cpus, making a total of 6 virtual CPUs running on four physical cores (I do believe it is four cores, not two cores with four threads, not 100% there). Assigning just one virtual CPU to each virtual guest essentially solved to problems.
Conclusion: Avoid virtual SMP in Vmware Server 2, unless you have “enough” physical cores.
Perhaps I will try a one-dual-cpu plus three-single-cpu configuration some day to see how that works.
The web interface of VmWare Server 2 comes with a console, that requires a browser plugin. I have been struggling with Firefox in Linux a lot, and now running Chrome I started looking for another solution.
And there is a great solution: use VmWare player
Simply install vmware player in Linux and invoke it like:
$ vmplayer -h ip.to.vmwareserver:8333
…login and enjoy!
It seems you have to use 8333 (8222 does not work).
I manage a few Linux machines that run VmWare Server 2.0.2. On those I have a few Windows Server OS guests.
A typical host is a Quad-Core Intel Core 2 processor, 8 GB RAM, separate system-drive and drive for virtual machines. It runs Debian (5.0 or 6.0) and VmWare Server 2.0.2.
A typical guest could be a Windows Server 2008 with 2GB RAM, 24GB C-drive, 12GB E-drive.
To get decent filesystem performance on the hosts I have used XFS and split the VmWare disk images into 2GB pieces. They have been allowed to grow dynamically.
Over time I have the feeling performance have grown worse, and not been very impressive. Different things have been tried. Finally, on of the hosts where reinstalled (Debian 6.0 instead of Debian 5.0), and btrfs was used instead of XFS. Horrible!
||Questionable (at least after 12 months)
||Horrible – 30min until Windows replies to ping
||Bad – replies to ping in less than three minutes, but both physical Linux and virtual Windows experiences I/O-delays of a few seconds. Very un-snappy.
||Excellent! Fast boot. Snappy.
Perhaps journaling filesystems have their advantages, but I make backups of all machines nightly and dont worry much of a filesystem crash. Also, ext2 can be considered fairly mature, proven and stable.
I will probably do some migration in the next days (reformat some XFS as ext2). Maybe I will provide some properly quantified measures. However, just moving the virtual machines and changing their format may fix problems with fragmentation, so it is hard to make a fair before-after-test.
Plenty of people have good reasons to want to access their VMWare Server 2.0.2 using http (port 8222) rather than https (port 8333). But VMWare did not make that so easy.
Many sites tell you that you enable http (disable http->https redirect) by editing /etc/vmware/hostd/proxy.xml
Replace (in all 5 places)
After that you should restart vmware.
$ sudo /etc/init.d/vmware restart
This is absolutely correct, but perhaps it is just 90% of the solution.
If it does not help, try re-running vmware-config.pl:
$ sudo /usr/local/bin/vmware-config.pl
When I did that, it asked me if I wanted to keep or replace my proxy.xml file (that I modified as suggested above). I choose to keep it, and after that http worked properly. It did many other things too… It seems overkill to recompile the kernel modules just to be able to disable http->https redirect. Maybe there is a smarter way, but at least this one worked.
If you are fine with the command line, and you want a simple, free, virtualization technology, I suggest QEMU.