VMware Server 2 Beta: Use Virtual Infrastructure Client to Speed Up Administration

Filed under: Linux, Virtualization — Written by Chrissy on Tuesday, January 8th, 2008 @ 11:39 am

The web interface for VMware Server 2 Beta for Linux is garbage; it's both slow and unattractive. Even VMware Server 1 and ESX Server 2.5 from years ago had a faster/nicer web interface. VMware Server looks a bit like ESX and my experience with ESX taught me that it can be administered with both the web interface and Virtual Infrastructure Client (VIC). I wondered if perhaps Server 2 could be administered with VIC too and fortunately, my hunch was confirmed by the VMware forums.

VIC on VMware Server Beta 2 is much faster than the web interface and even provides a more information about the VMs resource histories. It can be assumed that pushing the slower web interface for the free product isn't so much tech driven as it is marketing/$$ driven but that's only a guess. VIC is a big part of the high end, high price ESX server but can be also be found hidden in the rpms and tarballs of VMware Server. I could not find it, however, in the Windows version of VMware Server 2, even after extracting contents of the executable using the /a option.

To find the VIC (Windows only client, Linux clients are out of luck) in an RPM, run the following commands:

mkdir vmware
mv VMware-server-e.x.p-63231.x86_64.rpm vmware/
cd vmware
rpm2cpio VMware-server-e.x.p-63231.x86_64.rpm  | cpio -i --make-directories

The file can then be found at ./usr/lib/vmware/hostd/docroot/client/VMware-viclient.exe. As for the tarball, expand it (tar -xvzf or WinRAR in Windows) and the file can be found at ./vmware-server-distrib/lib/hostd/docroot/client/VMware-viclient.exe.

The thick client is so much nicer; I know it's unlikely that I'll ever use the resource intensive MUI so I uninstalled it by running:

chkconfig httpd.vmware off
vmware-uninstall-mui.pl

Even though I ran the uninstaller, the MUI magically started up on the next reboot so I modified the permissions on /etc/init.d/vmware and then commented out the following line: $watchdog -s webAccess -u 30 -q 5 "$webAccess $webAccessOpts start" > /dev/null 2>&1 &. I then restarted the vmware service and it worked exactly as I hoped.

Aside from the bad web interface, I'm really impressed by this version of VMware server and I'm definitely recommending it at work once the final arrives. I honestly hope that Microsoft's new virtualization platform can impress me as much and even more once their product matures. As for xen, I successfully set it up in SuSE, it was eas as pie. However, my Opteron 270 doesn't appear to support hardware virtualization (even though AMD's docs say they do, perhaps I have to upgrade my BIOS) so I can't run Windows VMs. Totally unacceptable. xen is something I want to keep an eye on, though. Big companies like Citrix, Oracle and Sun are using it in their own virtualization platforms. Now to find a test server that supports hardware VT...

Update: You can also find the VMware-viclient.exe here on some .edu website. I haven't used it and can't vouch for its safety, but it's there (at least for now) in the event that you don't want to go through all of the above steps. The timestamp on it is December 2007 which is good for now, but I woudln't use it past June 2008.

Install VMware Server 1.0 on SuSE 10.2 x64

Filed under: Linux, Virtualization — Written by Chrissy on Tuesday, October 2nd, 2007 @ 11:55 am

Ahh! One of my servers had a bad stick of RAM and caused all sorts of problems with VMWare ESX Server. At first, I thought ESX was too sensitive but later realized the stick was just super bad. Meanwhile, my evaluation version expired and so I decided to use VMware Server 1.0 (free) on top of SuSE 10.2 (also free).

Thankfully, this dude setup a really nice guide to get around some kernel issues in SuSE. It's pretty simple; before installing the VMware Server RPM, I ran the following:

# cd /usr/src/linux
# make mrproper; make cloneconfig; make modules_prepare

After installing the RPM, I ran vmware-config.pl and VMWare complained that a few files were missing. As it turns out, I needed the x86 version of a few packages. I loaded up
Yast -> Software -> Software Management -> Search -> [X] Provides -> [Missing Filename here]. I believe I ended up installing the following packages:

Several.. (many auto-selected themselves)

xorg-x11-libICE-32bit-7.2-13.x86_64.rpm
xorg-x11-libXau-32bit-7.2-8.x86_64.rpm
xorg-x11-libXdmcp-32bit-7.2-8.x86_64.rpm
xorg-x11-libSM-32bit-7.2-12.x86_64.rpm
xorg-x11-libX11-32bit-7.2-13.x86_64.rpm
xorg-x11-libXext-32bit-7.2-12.x86_64.rpm
xorg-x11-libXrender-32bit-7.2-12.x86_64.rpm
xorg-x11-libXt-32bit-7.2-13.x86_64.rpm
expat-32bit-2.0.0-32.x86_64.rpm
xorg-x11-libXfixes-32bit-7.2-13.x86_64.rpm
xorg-x11-libXmu-32bit-7.2-13.x86_64.rpm
xorg-x11-libXp-32bit-7.2-8.x86_64.rpm
xorg-x11-libXpm-32bit-7.2-12.x86_64.rpm
xorg-x11-libXv-32bit-7.2-8.x86_64.rpm
xorg-x11-libxkbfile-32bit-7.2-12.x86_64.rpm
zlib-32bit-1.2.3-33.x86_64.rpm
freetype2-32bit-2.2.1.20061027-11.x86_64.rpm
xorg-x11-libXprintUtil-32bit-7.2-8.x86_64.rpm
xorg-x11-libfontenc-32bit-7.2-12.x86_64.rpm
fontconfig-32bit-2.4.1-19.x86_64.rpm
xorg-x11-libs-32bit-7.2-19.x86_64.rpm
audit-libs-32bit-1.2.6-20.x86_64.rpm
cracklib-32bit-2.8.9-20.x86_64.rpm
libstdc++41-32bit-4.1.2_20061115-5.x86_64.rpm
libxcrypt-32bit-2.4-30.x86_64.rpm
db-32bit-4.4.20-16.x86_64.rpm
pam-32bit-0.99.6.3-24.x86_64.rpm

Next, used YaST to open up my firewall's port 902. Everything seemed to go well until I ran into PAM issues while attempting to remotely manage it using the VMWare Server Console (Windows). I received the error Permission denied: Login (username/password) incorrect. So I took a look at /var/log/messages and found this crappy news:

vmware-authd: PAM unable to dlopen(/usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so)
vmware-authd: PAM [error: /usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so: cannot open shared object file: No such file or directory]

After searching the web for a solution (thanks web!), I edited /etc/vmware/pam.d/vmware-authd and now it looks like the following:

#%PAM-1.0
#auth       sufficient       /usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so shadow nullok
#auth       required         /usr/lib/vmware/lib/libpam.so.0/security/pam_unix_auth.so shadow nullok
#account    sufficient       /usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so
#account    required         /usr/lib/vmware/lib/libpam.so.0/security/pam_unix_acct.so
auth sufficient /lib/security/pam_unix.so shadow nullok
auth required /lib/security/pam_unix_auth.so shadow nullok
account sufficient /lib/security/pam_unix.so
account required /lib/security/pam_unix_acct.so

Once that was done, I created a symbolic link to make restarting VMWare more comfy (ln -s /etc/init.d/vmware /usr/sbin/rcvmware), then I restarted the vmware service (rcvmware restart) and connected successfully from my remote machine. Now I'm happily installing Windows Server 2008 RC0. Hooray!

And my procrastination paid off -- while I was waiting for the motivation to troubleshoot the RAM issue, the price of my server's RAM dropped drastically -- from $160 to $99. Niiiice! I'm buying 5 for a total of 8 Gigs :D

Installing Longhorn x64 on VMWare ESX Server 3.0.x

Filed under: Virtualization, Windows — Written by Chrissy on Tuesday, April 24th, 2007 @ 11:54 am

I recently attended a Longhorn Roadshow in Santa Clara and learned quite a bit about Microsoft's emphasis on virtualization in Longhorn. A lot of companies are going towards virutalizing servers, even those still running NT or Exchange 5.5. The main reasons seem to be saving rackspace and saving electricity (fewer machines, less A/C) which both translate to saving money. Fortunately, my employer now has the infrastructure setup and virtualization on a mass scale seems like a possiblity. After a quick evaluation, I don't have much faith in Microsoft's current Virtual Server product but an evaluation of ESX Server 3.0 has proven impressive. VMWare has it together and it is likely the solution I'll be recommending in '08 when we're ready to move forward.

That said, it's been tough installing Longhorn x64 on VMWare ESX server. It should be expected, though; the support for Longhorn x64 isn't even experimental yet -- it's non-existent. I had to select Vista 64-bit Experimental as my base VM and hope for the best. What I've experienced is almost as painful as installing Windows 2003 R2 on a Macbook :|  Most of the frustration revolves around the CD-ROM drivers. The initial install of Longhorn on ESX is so promising but then a message pops up that says: "A required CD/DVD drive device driver is missing." At first, I thought this was because I was using an external USB DVD-R drive but that turned out not to be the case. I figured that gem out only after going through all these steps:

  • I installed some dumb .flp that never loaded the CD-ROM drivers as promised
  • I asked a friend to bring me an internal CDROM only to find out it's EIDE and my server doesn't support it
  • I took my work workstation's IDE CD-ROM and hooked it half-up to my server (the IDE cable) and half-up to a workstation (the power cable because my server didn't have any free power cables left).
  • Enabled IDE in the BIOS and finally had ESX recognize the drive
  • Still had the same problem

So then I got creative and decided to create the Longhorn image on another workstation. Doh! The workstation's CPU was not 64-bit enabled. So then I tried it on my laptop.. doh! It's 64-bit enabled but doesn't have some special VT chip that's often times not found in laptops. This is why I hate hardware.

So I gave in and ..

  • Wiped ESX and reinstalled Longhorn 64-bit.
  • Installed the free VMware server, created a Longhorn Virtual Machine and installed Longhorn
  • Once the install was complete, I backed up the vmdk to another machine
  • I then wiped Longhorn on the server, resinstalled ESX and copied the vmdk to /vmfs/volumes/storage1/longhorn
  • Next, I ran vmkfstools -i longhorn-64ws.vmdk longhorn-64esx.vmdk
  • Once that was done, I created a new Virtual Machine within ESX and selected Custom then used the new image longhorn-64esx.vmdk

Ahhh, that worked! But now VMWare tools was giving me trouble. The CD-ROM still didn't work (the CD-ROM, listed as NECVMWar VMWare IDE CDR00 ATA Device, gives the status of "The Device Cannot Start" (Code 10)) so I had to figure out another way around the problem. I copied the windows.iso from /vmimages/tools-isoimages to my workstation using Veeam FastSCP, mounted the ISO, saved the files as a zip under my web root then used IE on the Longhorn server to fetch the zip. Installed and voila, it works!