Using VMware Player to Connect to an ESXi Guest

Did you know that you can connect the VMware Player client to a guest running on VMware ESX/ESXi?

This is handy, especially for Windows guests where you don't want to enable RDP or some other remote desktop service (VNC).

The guest will automatically start if it isn't already running. A drawback (or benefit depending on how you look at it), via VMware Player you don't have the ability to edit hardware configuration or manage snapshots. You'll still need to use the VIC for that.

I was running a Windows guest (via VMware Player) on my Fedora 10 desktop to have access to MS Office, support for corporate Windows only apps, and most importantly access to the Virtual Infrastructure Client. Even with a fairly speedy dual core workstation, the Windows guest consistently bogged down the workstation. So, I decided, why not run this thing on the server and let it handle the load?

I used VMware Converter (free) to convert the VMware Player guest to a Virtual Infrastructure guest and sent it to the datastore on the ESXi server. I didn't realize that VMware Converter could transfer the converted guest on the fly to the ESXi server without purchasing extra licenses, well, it can and does.

Once the guest completed conversion and transfer to the ESXi server, i created a desktop launcher for VMware Player to launch the guest directly. The command line is as follows:

/usr/bin/vmplayer -h 10.1.1.2 -u "flakrat" "[datastore1] winxp01/winxp01.vmx"

Unfortunately, I don't see any method of adding VI guests to the list of "Recent Virtual Machines" in VMware Player client. Thus the custom desktop launcher.

The migration from Rocks to xCAT

Thinking of using an alternative HPC solution to Rocks? Check out xCAT.

xCAT appears to be much more flexible, and less entangled with the underlying operating system (in Rocks case, either Red Hat EL5 or CentOS5). This is appealing in that you can apply core OS updates without the worry that you'll break compatibility with the cluster stack.

There's a long history of discussions on the Rocks mailing list about how to apply core OS updates, and which packages to avoid. Over the releases, Rocks has moved much of the functionality into its own space or commands (for example, old Rocks had a modified /usr/sbin/useradd). Some users now claim that they apply updates to the nodes on a weekly basis without any problems, while others say that it's still possible to break components by applying the updates.

xCAT lives in its own space, under $XCATROOT (I think I have that right). Since xCAT is perl based, your biggest exposure would be updating the core perl to a much newer release, but you'd have to do that outside the normal yum repos.

One of Rocks strengths is that a novice Linux user can install and manage a basic cluster fairly easy, and conversley xCAT appears to have a steep learning curve and certainly requires a good deal of familiarity with Linux in a CLI environment (sorry no GUI yet).

More to come as I get time to play with xCAT.