VMware Server 2.0 under Ubuntu Intrepid Ibex

Following my Ubuntu Linux router upgrade project, and my "Ubuntu Hardy Heron under VMware" post, I felt it was time to swap things around and run VMware Server 2.0 under Ubuntu Intrepid Ibex (8.10).

The goal is to run one of the virtual machines I need to keep running quite often on my Shuttle K-4500-N2 which is being used as my router and left running all the time anyway. While it's not exactly a high-performance machine, it should suffice for the virtual machine I'm looking to move, which operates fine with only 256 MB RAM. This will allow me to keep my regular desktop powered off more, and save some power.

vsock Installation Issue

The first issue I had with the host installation under Ubuntu Intrepid Ibex was an issue with building the "vsock" module:

None of the pre-built vsock modules for VMware Server is suitable for your
running kernel.  Do you want this program to try to build the vsock module for
your system (you need to have a C compiler installed on your system)? [yes]

Extracting the sources of the vsock module.

Building the vsock module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config0/vsock-only'
make -C /lib/modules/2.6.27-7-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.27-7-generic'
  CC [M]  /tmp/vmware-config0/vsock-only/linux/af_vsock.o
  CC [M]  /tmp/vmware-config0/vsock-only/linux/driverLog.o
  CC [M]  /tmp/vmware-config0/vsock-only/linux/util.o
/tmp/vmware-config0/vsock-only/linux/util.c: In function âVSockVmciLogPktâ:
/tmp/vmware-config0/vsock-only/linux/util.c:157: warning: format not a string literal and no format arguments
  CC [M]  /tmp/vmware-config0/vsock-only/linux/vsockAddr.o
  LD [M]  /tmp/vmware-config0/vsock-only/vsock.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: "VMCIDatagram_CreateHnd" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: "VMCIDatagram_DestroyHnd" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: "VMCI_GetContextID" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
WARNING: "VMCIDatagram_Send" [/tmp/vmware-config0/vsock-only/vsock.ko] undefined!
  CC      /tmp/vmware-config0/vsock-only/vsock.mod.o
  LD [M]  /tmp/vmware-config0/vsock-only/vsock.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.27-7-generic'
cp -f vsock.ko ./../vsock.o
make: Leaving directory `/tmp/vmware-config0/vsock-only'
Unable to make a vsock module that can be loaded in the running kernel:
insmod: error inserting '/tmp/vmware-config0/vsock.o': -1 Unknown symbol in module
There is probably a slight difference in the kernel configuration between the
set of C header files you specified and your running kernel.  You may want to
rebuild a kernel based on that directory, or specify another directory.

The VM communication interface socket family is used in conjunction with the VM
communication interface to provide a new communication path among guests and
host.  The rest of this software provided by VMware Server is designed to work
independently of this feature.  If you wish to have the VSOCK feature  you can
install the driver by running vmware-config.pl again after making sure that
gcc, binutils, make and the kernel sources for your running kernel are
installed on your machine. These packages are available on your distribution's
installation CD.
[ Press the Enter key to continue.]

I found a solution to this posted on the Ubuntu Forums: "VMware server 2 vsock warning", specifically the patch to "vmware-config.pl" posted by "delgurth" on 2008-11-28: http://ubuntuforums.org/showpost.php?p=6267637&postcount=17.

Web Interface

I've been using the VMware Server 1.x versions on my Windows desktop and some other machines for quite some time, and things have worked quite well. The 2.0 version is quite an upgrade, and one that I first tested on my Windows desktop. While it brings many new features, I, like many others, was disappointed in the migration to - and apparent requirement to use - the web-based interface.

Included in the issues against the web interface is an issue with SSL certificates. For one, the server certificates are self-signed, which causes various warnings and issues under any browser, but these are common and somewhat-easily worked around. (See also: "Firefox SSL-Certificate Debate Rages On", 2008-08-22, slashdot.org.)

However, there is also an issue where client certificates are continuously prompted for. On the Windows host, I simply avoided this by connecting to the HTTP port (8222) instead of HTTPS (port 8333). The Linux host installation, however, redirects any HTTP requests to HTTPS. The 2 most informative search results I found were on the VMware forums: "VI constantly asks for Client Certificates?" and "identify yourself with a certificate". Unfortunately, I didn't have success with any of the listed suggestions.

Fortunately, the "VMware Infrastructure Client" can be used to connect instead, very similar to the "VMware Server Console" in the 1.x versions. From a Windows install, the client installation is located at "\VMware\VMware Server\hostd\docroot\client\VMware-viclient.exe" underneath Program Files. In order to get it to connect, I had to suffix the port number to the host name (:8333). It also seems to connect to the HTTPS port only, not HTTP.

Unfortunately, the VMware Infrastructure Client seems to have a few issues of its own. For one, I can't keep a console window open for a VM without keeping the main "VMware Infrasturcture Client" open as well. Additionally, it seems that some settings are only available under the web interface, or at least some settings that only work underneath the web interface. For example, when trying to configure the amount of "Reserved Memory" after going into maintenance mode, I get an error: "A specified parameter was not correct. spec.virtualMachineReserved". Configuring the same option through the web UI does work, however.

I was happy to see that the web UI was standardized across operating systems since the 1.x version. Previously, Microsoft IIS was required for any web management under Windows. While this worked well for me under Windows Server 2003 environments, it didn't work so well under Windows XP Professional, where there is a limit of only one operational virtual web site at a time. (See also: "IIS5.1 in XP Pro", Brett Hill, 2002, iisanswers.com.) While this may be fine for a dedicated VMware host, it prevents the use of the "Default Web Site" or any other desired sites.

Now, Apache Tomcat & Java are used. Unfortunately, continually running the web access service consumes ~100 MB of RAM. This is to significant of a waste for me for a process that is only going to be seldom used, especially on a machine that only has a maximum of 2 GB RAM available to begin with (which includes shared video memory). If the other issues were fixed, and/or if VMware made it easy to reuse existing Java/Tomcat instances instead of installing their own, I may reconsider.

Final Thoughts

I've been hearing more and more good things about VirtualBox, now developed by Sun Microsystems. I plan on giving it a try...

Dell Latitude E6500 VID_413C PID_8149

After about 7.5 years, I finally got a new laptop - a Dell Latitude E6500.

Since I previously posted in "No 64-bit Windows for Dell", the situation has improved. See the update there for details, but Dell is now definitely making 64-bit versions of Windows available to their customers, even if not yet available as pre-installed.

Having received my Dell OEM "Reinstallation DVD" for "Windows Vista Ultimate 64BIT SP1", I began the upgrade process. Considering that the system came with an apparently complete set of recovery DVDs and CDs, I wasn't too concerned about wiping the hard drive and starting from scratch. However, as a precaution, I pulled the hard drive and imaged the first 2 partitions, "Diagnostic - DellUtility" and "Recovery".

The recovery partition looked rather interesting. The original partition was somewhere between 1-2 GB, but wasn't even half-full. The copied, compressed image is only 383 MB. According to Dell's documentation, "Dell Factory Image Restore (Microsoft Windows Vista only) returns your hard drive to the operating state it was in when your purchased the computer.". 383 MB seems rather impossible for that task, and probably not enough enough to reinstall Windows, much less any of the Dell drivers or applications. To no surprise, manually searching through the recovery partition didn't yield anything Dell-specific.

I was able to reinstall all the drivers with minimal issues, except one. The main issue is that I don't know what it is! There is one remaining device in the Windows Device Manager that simply lists as "Unknown device", as shown:

All this really shows is that the mysterious device is connected via USB.

Before I reformatted, I worked with the pre-installed image for a bit just to see how things originally were. In hindsight, I wish I would have imaged the whole drive, or for this particular issue, at least taken some "before" screenshots from the Device Manager. The one thing that I do remember, which was a bit of a surprise, was that my system apparently has Wireless USB support, as was indicated by an applet in the notification area (system tray).

As I no longer see this after the reinstall, and since I only have the one unknown device, it would seem that this unknown device must be related to the Wireless USB. Additionally, the Dell Bluetooth device is a "Dell Wireless 410 Bluetooth Module with UWB", where UWB is Ultra-wideband, which Wireless USB is based on.

However, none of the Dell Wireless 410 Bluetooth drivers (specifically R197543.exe) are recognized as valid for the unknown device.

Looking at the details tab of the device properties in Device Manager, the following details are shown:

Hardware Ids

USB\VID_413C&PID_8149&REV_0100
USB\VID_413C&PID_8149

Compatible Ids

USB\Class_FE&SubClass_01&Prot_02
USB\Class_FE&SubClass_01
USB\Class_FE

The only Google result after searching for the above VID and PID to date is a forum post by "Justin77" on 2008-10-16, where he seems to have the same question: http://forum.notebookreview.com/showpost.php?p=4041896&postcount=599. (I'm guessing this will quickly become 1 of 2 Google results for the search!)

The Linux USB Project has a the most comprehensive list of USB Vendor IDs and Product IDs I've seen at http://www.linux-usb.org./usb.ids. This clearly shows that the 413C Vendor ID belongs to "Dell Computer Corp.". While it doesn't currently list a match for the Product ID of 8149, it does show that PID 8140 is "Wireless 360 Bluetooth", and that PID 8142 is "Mobile 360 in DFU". If Dell has any method to assigning their Product IDs, it would seem that PID 8149 should be related to the Dell Bluetooth device.

The listed Compatible IDs, however, seem to hint away from Wireless USB. http://www.usb.org/developers/defined_class lists Class FE as "Application Specific", and SubClass 01 as "Device Firmware Upgrade" - though it lists this next to Protocol 01, where mine is is 02. This also seems to relate to the above 8142 PID - "Mobile 360 in DFU", or "Device Firmware Upgrade".

However, another forum post by "somms" on 2008-11-08, seems to confirm that I should have a "Dell Wireless 410 Wireless USB Device", as shown in the included screenshot at http://forum.notebookreview.com/showpost.php?p=4133796&postcount=21.

Just in case this was an issue with the 64-bit version of Windows, I dual-booted another install of the 32-bit version, and had exactly the same issue. None of the drivers installed there resolved this unknown device, either.

I'm starting to wonder if this whole issue is at all related to "USB mode switching", as was the case with my Alltel UM175AL USB EVDO device.

That's all I have for now. I have an escalated support request open with Dell. Hopefully I'll hear something back during the next week after the holiday weekend is over. Besides resolving this "Unknown device" issue, I hope to find out what the situation was with the recovery partition. I'll add an update here with anything I find out.

In the meantime, time to give Ubuntu Linux a try on the Latitude E6500...

Update (2008-11-30):

This "Unknown device" is definitely a "Dell Wireless 410 Bluetooth & UWB Mini-card". User "somms" posted a response at http://forum.notebookreview.com/showthread.php?t=297416&page=3, containing a link to a torrent containing a WiQuest driver. After a lengthy download, I found that "Drivers\Wiquest\Vista\Delwusb.inf" contained the following:

;.------------------------------------------------------------------.
;|      Dell Wireless 410 Bluetooth & UWB Mini-card                 |
;'------------------------------------------------------------------'
;       Dell MO9 WUSB HWA

%LOADER_HWA_BT_DESC_DELL%     = WQ_LDRHWA.Dev,  USB\VID_413C&PID_8149
%UWB_HWA_BT_DESC_DELL%        = WQ_USBUWB.Dev,  USB\VID_413C&PID_8150
%HWA_GENERIC_BT_DESC_DELL%    = WQ_USBHWA.Dev,  USB\VID_413C&PID_8150&MI_00

After loading the driver, anything with "PID_8149" no longer appears in the Device Manager. Instead, there are the following devices:

• "Dell Wireless 410 Wireless USB Device"
  • Hardware Ids

    USB\VID_413C&PID_8150&REV_:513
    USB\VID_413C&PID_8150
    

  • Compatible Ids

    USB\Class_E0&SubClass_02&Prot_01
    USB\Class_E0&SubClass_02
    USB\Class_E0
    

• "Dell Wireless 410 Wireless USB Host Wire Adapter"
  • Hardware Ids

    USB\VID_413c&PID_8150&MI_00
    

  • Compatible Ids

    USB\Class_e0&SubClass_02&Prot_01
    USB\Class_e0&SubClass_02
    USB\Class_e0
    

So it definitely seems that there is some sort of USB mode switching in effect.

Now, I'd just like to find the official source of these drivers. I can't find anything on Dell's website. While the drivers are listed as from "WiQuest Communications, Inc.", they are Dell-branded - both in the installer and in the application.

Note that WiQuest folded at the end of October (PC Magazine 2008-11-4, EE Times 2008-10-31), which should make things interesting.

The installation provided by "somms" contained the drivers and applet for the WUSB as well as the Bluetooth. However, the driver version for the Bluetooth was 6.1.0.4500 (2008-03-07), where the latest provided by Dell is 6.1.0.4100 (2008-01-31). This makes me wonder if there is a slightly newer version of the WUSB driver available as well.

Regardless, at least now I have the functionality working that was shipped with the laptop, whether or not WUSB is "dead". At least now I can disable the WUSB radio with some certainty and maybe save some power and battery life!

IBM PK70653 WebSphere XSLT Empty DOM Debug Failure

I'm pleased to see that the details of a PMR I had opened with IBM over 3 months ago now are now publicly acknowledged as PK70653: XSLT TRANSFORMATION IN DEBUG MODE FAILS ON AN EMPTY INPUT XML DOCUMENT WITH MESSAGE [FATAL ERROR] PREMATURE END OF FILE.

There are some details which seem to have been left out of the above APAR / PK that may be useful:

• No application Throwable is ever thrown. The described error is generated only to stderr.
• The transformation is aborted and nothing is ever set on the result. If passing in a DOMResult as the "requestResult" listed in the APAR, setNode(…) is never called, and getNode() will return null - potentially leading to additional application errors, probably as a NullPointerException if unchecked.
• As documented in the Transformer's transform(…) method, passing in an empty Source is explicitly allowed by the API.
• There is a temporary work-around. Follow the instructions at http://www-01.ibm.com/support/docview.wss?uid=swg21258865 to disable the XSLT Debug Adapter, either by setting the "com.ibm.debug.attach.agent.xslt.enabled" JVM custom property to "false", or by modifying a preference in Rational Application Developer (RAD) if using the WebSphere Application Server (WAS) Test Environment.

Finally, just for reference purposes, here is the error that may be seen in stderr if experiencing this issue (also as shown in the APAR):

[Fatal Error]  :-1:-1: Premature end of file.
SystemId Unknown;Line #-1; Column #-1; Premature end of file.

Kudos to Dorine, Bruce, Samantha, and the others involved at IBM for taking attention to and resolving this issue!