random neuron misfires

This was a bugger to find out, and required installing and reinstalling Linux a dozen times in different ways, to narrow down on the actual cause.

If you run VMware Workstation on your Linux host, and are also trying to run Linux guests, you may run into a situation where your mouse cursor in the guest moves and tracks as you would expect, but any attempt to right-click or left-click is ignored entirely.

During my tests, I noticed that this happens 100% of the time with Ubuntu 14.04.4, does not happen with Ubuntu 14.04.2, and does not happen with Ubuntu 16.04.

But it is reproducible.

Originally, I thought this was due to having the wrong “mouse” vs. “vmmouse” driver in my Xorg configuration. That didn’t prove to be true.

Next, I tried doing some VMX file hacks, which also failed. I also tried disabling the “Drag and Drop” and “Cut and Paste” options in the VMware options. That also, did not solve the problem.

To fix the problem, go into your Guest settings and under the Processor sub-section, you want to uncheck the “Virtualize CPU performance counters” option. You can leave the rest as-is.

The option should look like this:

That’s it! Hopefully that helps someone else out there running into the same problem!

Playing more and more with Docker across multiple Linux distributions has taught me that not all Linux distributions are treated the same.

There’s a discord right now in the Linux community about systemd vs. SysV init. In our example, CentOS 7.x uses systemd, where all system services are spawned and started.

I am using this version of Linux to set up my own Docker lab host for tire-kicking, but it needs some tweaks.

I also wanted to see if I could use the Docker API from my Android phone, using DockerDroid, which (after configuring this) works famously!

Here’s what you need to do:

1. Log into your CentOS machine and update to the most-current Docker version. The version shipped with CentOS 7 in the repo as I write this post, is “docker-1.3.2-4.el7.centos.x86_64”. You want to be using something more current, and 1.4 is the latest. To fetch that (and preserve your existing version), run the following:

   $ su -
   # cd /bin && mv /bin/docker /bin/docker.el7
   # wget https://get.docker.com/builds/Linux/x86_64/docker-latest -O docker
   # systemctl restart docker
   # exit
   $ 
   

   Now you should have a working Docker with the right version (current). You can verify that:

   $ sudo docker version
   Client version: 1.4.1
   Client API version: 1.16
   Go version (client): go1.3.3
   Git commit (client): 5bc2ff8
   OS/Arch (client): linux/amd64
   Server version: 1.4.1
   Server API version: 1.16
   Go version (server): go1.3.3
   Git commit (server): 5bc2ff8

2. So far, so good! Now we need to make sure firewalld has a rule to permit this port to be exposed for external connections:

   $ sudo firewall-cmd --zone=public --add-port=4243/tcp --permanent
   $ sudo firewall-cmd --reload
   success
   

   You can verify that this new rule was added, by looking at /etc/firewalld/zones/public.xml, which should now have a line that looks like this:

   <port protocol="tcp" port="4243"/>

3. Now let’s reconfigure Docker to expose the API to external client connections, by making sure the OPTIONS line in /etc/sysconfig/docker looks like this (note the portion in bold):

   OPTIONS=--selinux-enabled -H fd:// -H tcp://0.0.0.0:4243
   

4. Restart the Docker service to enact the API on that port (if successful, you will not see any output):

   sudo systemctl restart docker

5. To test the port locally, install telnet and then try telnet’ing to the port on localhost:

   $ sudo telnet localhost 4243
   Trying ::1...
   Connected to localhost.
   Escape character is '^]'.
   
   HTTP/1.1 400 Bad Request
   
   Connection closed by foreign host.

   All looks good so far!

6. Lastly, install DockerDroid and configure it to talk to your server on this port:

   

Now you should be able to use DockerDroid to navigate your Images, Containers and API.

Good luck!

I find myself using rsync a lot, both for moving data around, for creating backups using rsnapshot (yes, even on Windows!) and for mirroring public Open Source projects and repositories.

I used to create all sorts of filters and scripts to make sure I was getting only the files I wanted and needed, but I found a better way, and it wasn’t exactly intuitive.

--include="*/" --include="*.iso" --exclude="*"

In order for this to work as intended, the “include” patterns have to come before the “excludes”. This is because the very first pattern that matches is the one that gets evaluated. If your intended filename matches the specified exclude pattern first, it gets excluded from the scope.

When dealing with a very large, possibly unknown remote directory structure, you either have to include all of the remote subdirectories individually like this:

--include="/opt" --include="/var" --include="/home"

Or you can use the following syntax to include all directories (not files) in the scope:

--include="*/"

Once you’ve included every directory below your target scope, you can pass the filespec you’re interested in (in this case, I wanted every bootable ISO file from a remote CentOS mirror), and then you exclude everything else that doesn’t match that filespec. It looks like this:

1.) Include every directory:

--include="*/"

2.) Include *.iso as your intended matching scope

--include="*.iso"

3.) Exclude everything else

--exclude="*"

That’s the magic sauce.

Some of these options and the order they appear in may seem very non-intuitive, so please read the rsync documentation carefully paying specific attention to the “EXCLUDE PATTERNS” section of the docs.

When in doubt, always use “–dry-run –stats” to check your work before copying or modifying any data.

Measure twice, cut once.

It may seem odd, that it’s almost 2015, and I’m writing a post describing how to install VMware Tools inside Ubuntu 5.04, a Linux distribution that was released on April 8th, 2005 and went End of Life on October 31, 2006.

I run a home lab here with a number of test machines (all VMs now), which includes every single major Linux distribution and version. Yes, really. I’ve been going back trying to update all of them to current tools, VMHW versions, NIC drivers and tweaking other things. Among these, were a number of very old Linux distributions who did not support VMware drivers natively (eg: open-vm-tools didn’t exist at that time).

If you run the standard configuration (I run it non-interactive as below)…

# ./vmware-install.pl --clobber-kernel-modules=vmci     \
                      --clobber-kernel-modules=vmxnet3  \ 
                      --clobber-kernel-modules=pvscsi   \
                      --clobber-kernel-modules=vmmemctl \
                      --clobber-kernel-modules=vsock    \ 
                      -d

At some point after the X11 configuration, you’ll see this error displayed:

Creating a new initrd boot image for the kernel.

$Id: mkinitrd,v 1.201 2004/05/16 22:00:48 herbert Exp $

Usage: /usr/sbin/mkinitrd [OPTION]... <-o outfile> [version]

Options:
  -d confdir  Specify an alternative configuration directory.
  -k          Keep temporary directory used to make the image.
  -m command  Set the command to make an initrd image.
  -o outfile  Write to outfile.
  -r root     Override ROOT setting in mkinitrd.conf.

See mkinitrd(8) for further details.
ERROR: "/usr/sbin/mkinitrd" exited with non-zero status.

Your system currently may not have a functioning init image and may not boot
properly.  DO NOT REBOOT!  Please ensure that you have enough free space
available in your /boot directory and run this configuration script again.

Execution aborted.

Found VMware Tools CDROM mounted at /media/cdrom0. Ejecting device /dev/hdc ...

But there’s a one-line fix! Open up “vmware-tools-distrib/bin/vmware-config-tools.pl” in an editor and go down to line 7692, and you’ll see something that looks like this:

      $initmodfile = '/etc/sysconfig/kernel';
      if ($gSystem{'distribution'} eq 'suse') {
          $syscmd = join(' ', $binary, $kernelList, $initrdList);
      } else {
          $syscmd = $binary;
      }

You’ll want to modify that last “$syscmd” line to look as follows:

      $initmodfile = '/etc/sysconfig/kernel';
      if ($gSystem{'distribution'} eq 'suse') {
          $syscmd = join(' ', $binary, $kernelList, $initrdList);
      } else {
          $syscmd = join(' ', $binary, '-o', "/boot/initrd-$kernRel.img", $kernRel);
      }

That will now result in the following successful output:

Creating a new initrd boot image for the kernel.
   Checking acpi hot plug                                              done
Starting VMware Tools services in the virtual machine:
   Switching to guest configuration:                                   done
   Guest operating system daemon:                                      done
The configuration of VMware Tools 9.0.5 build-1065307 for Linux for this
running kernel completed successfully.

You must restart your X session before any mouse or graphics changes take
effect.

You can now run VMware Tools by invoking "/usr/bin/vmware-toolbox-cmd" from the
command line.

To enable advanced X features (e.g., guest resolution fit, drag and drop, and
file and text copy/paste), you will need to do one (or more) of the following:
1. Manually start /usr/bin/vmware-user
2. Log out and log back into your desktop session; and,
3. Restart your X session.

Enjoy,

--the VMware team

Voila! Now you have a successful build of the native VMware modules and can switch your ethernet module to VMXNET3 from E1000 to save a little memory on the ESXi side.

I have a lot of data that I archive away on a regular basis, both on my “PC” machines and my mobile devices OTA. I needed a secure, reproducible way to secure those data with a very strong, complex password using extremely tight compression.

Unfortunately, p7zip on Linux and 7-Zip for Windows don’t permit a non-interactive way to pass in a password. So I came up with a quick-and-dirty workaround!

1. First, generate a complex password and put this in a file with one line. Make sure there are no leading or trailing characters in this file, including a trailing newline. There should be one and only one line in this file. Here’s are some examples of a password generated with the level of complexity you’ll want for secured archives (42 characters in length, 15 minutes of generated entropy from a hardware dongle):

   {Kt8}m.Gs7:g}=%-nfX[F_E(tKs[X,}GrN$mz^?m7^
   +S/>>@7DzKafmLkSkS:-"4-*@k)#u@mQ>"=7j_vvu,!
   <prX9WG#h,t-Ka`poA9rhJWc]H9M}`NA(8_93tD\hR
   

2. Now with that password in a file, run the following loop to compress the data and pass in the password inline.

   You’ll notice that on Windows, I use Cygwin here, because I can create scripts and retain previous commandline history to reproduce this on a regular basis.

   I’m also using lzma2 here because it gives me slightly tighter compression for minimally more CPU time to generate the archives.

   On Linux

   cat your-pw-file | for i in *.xml; do 7z u -t7z -m0=lzma2 -mx=9 -mfb=64 -md=64m -ms=on $i.7z $i -p --; done;
   

   On Windows (using Cygwin)

   cat your-pw-file | for i in *.xml; do do /cygdrive/c/Program\ Files/7-Zip/7z.exe u -t7z -m0=lzma2 -mx=9 -mfb=64 -md=64m -ms=on $i.7z $i -p --; done;
   

3. To verify that the files are properly encrypted and the right password works as expected, test as follows:

   On Linux

   cat your-pw-file | for i in *.7z; do 7z t $i -p --; done;
   

   On Windows (using Cygwin)

   cat your-pw-file | for i in *.7z; do do /cygdrive/c/Program\ Files/7-Zip/7z.exe t $i -p --; done;
   

4. Now you can delete that password file from disk. I can’t stress this enough. Once you’ve used the password, and secured it in a managed password container, you’ll want to delete all traces of it that you do not need in plain sight on disk.

That’s it. Now when you want to decompress those archives, you’ll need to supply the password you generated before. Make sure you keep this password secured in a managed location. A password is only as secure as your ability to manage it.

Good luck!

I run a VMware ESXi server here that hosts ~500 separate VMs, clones, templates and test builds of operating systems for testing, development, personal playground and other roles.

Some of these VMs are older Fedora, Ubuntu, Debian and various other Linux distributions. Since those distributions are no longer active, maintained by the community, the update URLs to install packages have gone away, or been moved to new locations.

Here’s how to update and fix those older versions of Fedora Linux so you can continue to install packages on them, past their “community expiration” date. I’ll post another entry for the same work for Ubuntu and Debian as well.

In your /etc/yum.repos.d/ directory are a number of configuration files specific to yum and repositories. It’s contents may look something like this:

[root@fedora-fc4 / yum.repos.d]# ls -lart
total 72
drwxr-xr-x  116 root root 12288 Nov 23 22:57 ..
-rw-r--r--    1 root root   344 Nov 24 14:42 fedora-updates-testing.repo
-rw-r--r--    1 root root   336 Nov 24 14:42 fedora-updates.repo
-rw-r--r--    1 root root   305 Nov 24 14:42 fedora-extras.repo
-rw-r--r--    1 root root   319 Nov 24 14:42 fedora-extras-devel.repo
-rw-r--r--    1 root root  1130 Nov 24 14:42 fedora-devel.repo
-rw-r--r--    1 root root   300 Nov 24 14:43 fedora.repo
drwxr-xr-x    2 root root  4096 Nov 24 14:43 .

In the case of Fedora Linux, you’ll want to change each of these so they reflect the new archive site, vs. the original download site, which no longer resolves and does not exist.

The original URL looks like this:

baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/

You’ll want to edit that to point to the following new URL (highlighted in red below):

baseurl=http://archive.fedoraproject.org/pub/archive/fedora/linux/core/$releasever/$basearch/os/

Once you make these edits to all of the repository files, you can run ‘yum update’ again and fetch all of the legacy update packages, install, remove and keep them as current as those distributions were at that time.

$ sudo yum install git-core
Setting up Install Process
Setting up repositories
updates-released          100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
base                      100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for git-core to pack into transaction set.
git-core-1.4.4.2-2.fc4.x8 100% |=========================|  67 kB    00:00
---> Package git-core.x86_64 0:1.4.4.2-2.fc4 set to be updated
--> Running transaction check

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size
=============================================================================
Installing:
 git-core                x86_64     1.4.4.2-2.fc4    extras            2.9 M

Transaction Summary
=============================================================================
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 2.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/1): git-core-1.4.4.2-2 100% |=========================| 2.9 MB    00:05
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 1ac70ce6
public key not available for git-core-1.4.4.2-2.fc4.x86_64.rpm
Retrieving GPG key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
Importing GPG key 0x1AC70CE6 "Fedora Pre Extras Release "
Is this ok [y/N]: y
Key imported successfully
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: git-core                     ######################### [1/1]

Installed: git-core.x86_64 0:1.4.4.2-2.fc4
Complete!

Now it works. Good luck!

Another quick VMware Tools patch and fix if you’re using Linux Kernel 3.10 and 3.11.0 (and probably later, until this gets integrated into mainline). This time, if you’re seeing the following error:

Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-CZk9AS/vmmemctl-only'
/usr/bin/make -C /lib/modules/3.11.0-999-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
	  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.11.0-999-generic'
  CC [M]  /tmp/modconfig-CZk9AS/vmmemctl-only/backdoorGcc64.o
  CC [M]  /tmp/modconfig-CZk9AS/vmmemctl-only/os.o
  CC [M]  /tmp/modconfig-CZk9AS/vmmemctl-only/vmballoon.o
/tmp/modconfig-CZk9AS/vmmemctl-only/os.c: In function ‘vmballoon_procfs_init’:
/tmp/modconfig-CZk9AS/vmmemctl-only/os.c:468:4: error: implicit declaration of function ‘create_proc_entry’ [-Werror=implicit-function-declaration]
/tmp/modconfig-CZk9AS/vmmemctl-only/os.c:468:8: warning: assignment makes pointer from integer without a cast [enabled by default]
/tmp/modconfig-CZk9AS/vmmemctl-only/os.c:470:10: error: dereferencing pointer to incomplete type
cc1: some warnings being treated as errors
make[2]: *** [/tmp/modconfig-CZk9AS/vmmemctl-only/os.o] Error 1
make[1]: *** [_module_/tmp/modconfig-CZk9AS/vmmemctl-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.11.0-999-generic'
make: *** [vmmemctl.ko] Error 2
make: Leaving directory `/tmp/modconfig-CZk9AS/vmmemctl-only'

create_proc_entry() has been deprecated in the latest kernel, replaced with proc_create(), with different accessors. I hacked up a quick-and-dirty patch to fix it:

--- os.c	2013-03-23 10:01:51.000000000 -0400
+++ os.c.patched	2013-08-23 15:00:01.416322190 -0400
@@ -460,15 +460,16 @@
    .release = single_release,
 };

-static void
+static int
 vmballoon_procfs_init(void)
 {
    struct proc_dir_entry *pde;

-   pde = create_proc_entry("vmmemctl", S_IFREG | S_IRUGO, NULL);
-   if (pde) {
-      pde->proc_fops = &vmballoon_proc_fops;
+   pde = proc_create("vmmemctl", 0, NULL, &vmballoon_proc_fops);
+   if (pde == NULL) {
+      return -ENOMEM;
    }
+   return 0;
 }

 static void

Apply this patch to os.c in vmmemctl-only, and you’ll have a clean build:

1. Mount your VMware Tools ISO somewhere

   # mkdir /tmp/cdrom
   # mount /dev/sr0 /tmp/cdrom

2. Extract the tarball to /tmp/

   # cd /tmp/cdrom
   # tar zxvf VMwareTools-9.0.5-1065307.tar.gz -C /tmp/

3. Change into the VMware Tools directory that was just created

   # cd /tmp/vmware-tools-distrib/

4. Patch the tree with the above patch

   # tar -xvf lib/modules/source/vmmemctl.tar
   # cd lib/modules/source/
   # patch -p0 < /tmp/vmware-tools-linux-kernel-3.11.0_vmmemctl_proc_create_vmballoon.patch

5. Tar up the patched source so we can rebuild using the new tarball

   # tar -cf vmmemctl.tar vmmemctl-only/

6. Now let's rebuild it!

   # cd /tmp/vmware-tools-distrib/
   # ./vmware-install.pl --clobber-kernel-modules=vmci    \
                     --clobber-kernel-modules=vsock   \
                     --clobber-kernel-modules=vmxnet3 \
                     --clobber-kernel-modules=pvscsi  \
                     --clobber-kernel-modules=vmmemctl
   

And it works, of course!

Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-AssZbT/vmmemctl-only'
/usr/bin/make -C /lib/modules/3.11.0-999-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
	  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.11.0-999-generic'
  CC [M]  /tmp/modconfig-AssZbT/vmmemctl-only/backdoorGcc64.o
  CC [M]  /tmp/modconfig-AssZbT/vmmemctl-only/os.o
  CC [M]  /tmp/modconfig-AssZbT/vmmemctl-only/vmballoon.o
  CC [M]  /tmp/modconfig-AssZbT/vmmemctl-only/vmmemctl.mod.o
  LD [M]  /tmp/modconfig-AssZbT/vmmemctl-only/vmmemctl.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/modconfig-AssZbT/vmmemctl-only/vmmemctl.mod.o
  LD [M]  /tmp/modconfig-AssZbT/vmmemctl-only/vmmemctl.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.11.0-999-generic'
/usr/bin/make -C $PWD SRCROOT=$PWD/. \
	  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/modconfig-AssZbT/vmmemctl-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/modconfig-AssZbT/vmmemctl-only'
cp -f vmmemctl.ko ./../vmmemctl.o
make: Leaving directory `/tmp/modconfig-AssZbT/vmmemctl-only'

Reboot your machine, and you should see something like the following:

$ uname -a 
Linux ubuntu-1304-esx-vm 3.11.0-999-generic #201308230405 SMP Fri Aug 23 08:06:47 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Good luck!

UPDATE: I tested this against the 3.10.9-200.fc19.x86_64 kernel in Fedora FC19 as well as the 3.11.0-999 kernel in Ubuntu Kernel Mainline, and they both work flawlessly. YMMV, but email me if you have trouble.

Well, 11.6 hours later after scanning the NAS with fdupes, I noticed that I’ve got some dupes across my system backups.

# time ./fdupes -R -Sm "/nas/Backups/System Backups/"
2153352 duplicate files (in 717685 sets), occupying 102224.5 megabytes


real	698m15.606s
user	38m20.758s
sys	92m17.217s

That’s 2.1 million duplicate files occupying about 100GB of storage capacity in my backups folder on the NAS. DOH!

Now the real work begins, making sense of what needs to stay and what needs to get tossed in here.

UPDATE: I may give up on fsdupes altogether, and jump to rmlint instead. rmlint is significantly faster, and has more features and functions. Here’s a sample of the output:

# rmlint -t12 -v6 -KY -o "/nas/Backups/System Backups/"
Now scanning "/nas/Backups/System Backups/".. done.
Now in total 3716761 useable file(s) in cache.
Now mergesorting list based on filesize... done.
Now finding easy lint...
Now attempting to find duplicates. This may take a while...
Now removing files with unique sizes from list...109783 item(s) less in list.
Now removing 3917500 empty files / bad links / junk names from list...
Now sorting groups based on their location on the drive... done.
Now doing fingerprints and full checksums..
Now calculation finished.. now writing end of log...
=> In total 3716761 files, whereof 1664491 are duplicate(s)
=> In total  77.66 GB  [83382805000 Bytes] can be removed without dataloss.

If you run a current version of VMware Workstation, VMware Server, ESXi or VMware Fusion with a recent Linux kernel as a guest, you’ve most-likely run into this already.

UPDATE: If you’re using Linux kernel 3.11.0, see my updated blog post for the patch and fix for that revision.

 
Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-N9AMbf/vmci-only'
/usr/bin/make -C /lib/modules/3.8.0-19-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
	  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.8.0-19-generic'
  CC [M]  /tmp/modconfig-N9AMbf/vmci-only/linux/vmciKernelIf.o
  CC [M]  /tmp/modconfig-N9AMbf/vmci-only/linux/driver.o
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:127:4: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit-function-declaration]
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:127:4: error: initializer element is not constant
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:127:4: error: (near initialization for ‘vmci_driver.remove’)
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:1754:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vmci_probe_device’
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:1982:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vmci_remove_device’
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:119:12: warning: ‘vmci_probe_device’ used but never defined [enabled by default]
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:121:13: warning: ‘vmci_remove_device’ used but never defined [enabled by default]
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:2063:1: warning: ‘vmci_interrupt’ defined but not used [-Wunused-function]
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:2137:1: warning: ‘vmci_interrupt_bm’ defined but not used [-Wunused-function]
/tmp/modconfig-N9AMbf/vmci-only/linux/driver.c:1717:1: warning: ‘vmci_enable_msix’ defined but not used [-Wunused-function]
cc1: some warnings being treated as errors
make[2]: *** [/tmp/modconfig-N9AMbf/vmci-only/linux/driver.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [_module_/tmp/modconfig-N9AMbf/vmci-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.8.0-19-generic'
make: *** [vmci.ko] Error 2
make: Leaving directory `/tmp/modconfig-N9AMbf/vmci-only'

Here’s the patch to fix it. Either cut-and-paste the code snippet below and save it to a file, or you can download it here.

--- vmci-only/linux/driver.c	2012-11-01 16:22:03.000000000 +0900
+++ vmci-only/linux/driver.c.patched	2013-03-01 04:21:08.402942111 +0900
@@ -124,7 +124,11 @@ static struct pci_driver vmci_driver = {
    .name     = "vmci",
    .id_table = vmci_ids,
    .probe = vmci_probe_device,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3,8,0)
    .remove = __devexit_p(vmci_remove_device),
+#else
+   .remove = vmci_remove_device,
+#endif
 };
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19)
@@ -1750,7 +1754,11 @@ vmci_enable_msix(struct pci_dev *pdev) /
  *-----------------------------------------------------------------------------
  */
 
-static int __devinit
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3,8,0)
+ static int __devinit
+#else
+ static int 
+#endif
 vmci_probe_device(struct pci_dev *pdev,           // IN: vmci PCI device
                   const struct pci_device_id *id) // IN: matching device ID
 {
@@ -1978,7 +1986,11 @@ vmci_probe_device(struct pci_dev *pdev,
  *-----------------------------------------------------------------------------
  */
 
-static void __devexit
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3,8,0)
+ static void __devexit
+#else
+ static void
+#endif
 vmci_remove_device(struct pci_dev* pdev)
 {
    struct vmci_device *dev = pci_get_drvdata(pdev);

And here's how to apply it and fix the problem:

1. Mount your VMware Tools ISO somewhere

   # mkdir /tmp/cdrom
   # mount /dev/sr0 /tmp/cdrom

2. Extract the tarball to /tmp/

   # cd /tmp/cdrom
   # tar zxvf VMwareTools-9.0.5-1065307.tar.gz -C /tmp/

3. Change into the VMware Tools directory that was just created

   # cd /tmp/vmware-tools-distrib/

4. Patch the tree with the above patch

   # cd lib/modules/source/
   # tar -xvf vmci.tar
   # patch -p0 < /tmp/vmware-tools-linux-kernel-3.8_vmci_pci_hotplug_struct.patch

5. Tar up the patched source so we can rebuild using the new tarball

   # tar -cf vmci.tar vmci-only/

6. Now let's rebuild it!

   # cd /tmp/vmware-tools-distrib/
   # ./vmware-install.pl

If you've done it right, it will build cleanly:

Using 2.6.x kernel build system.
make: Entering directory `/tmp/modconfig-qs1htj/vmci-only'
/usr/bin/make -C /lib/modules/3.8.0-19-generic/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
	  MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-3.8.0-19-generic'
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/linux/driver.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/linux/vmciKernelIf.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciContext.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciDatagram.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciDoorbell.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciDriver.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciEvent.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciHashtable.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciQPair.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciQueuePair.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciResource.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/common/vmciRoute.o
  CC [M]  /tmp/modconfig-qs1htj/vmci-only/driverLog.o
  LD [M]  /tmp/modconfig-qs1htj/vmci-only/vmci.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/modconfig-qs1htj/vmci-only/vmci.mod.o
  LD [M]  /tmp/modconfig-qs1htj/vmci-only/vmci.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.8.0-19-generic'
/usr/bin/make -C $PWD SRCROOT=$PWD/. \
	  MODULEBUILDDIR= postbuild
make[1]: Entering directory `/tmp/modconfig-qs1htj/vmci-only'
make[1]: `postbuild' is up to date.
make[1]: Leaving directory `/tmp/modconfig-qs1htj/vmci-only'
cp -f vmci.ko ./../vmci.o
make: Leaving directory `/tmp/modconfig-qs1htj/vmci-only'

That's it! This same patch will work with all previous kernels, as well as those up to the most current 3.8 kernels.

If you're rebuilding your kernel modules using the command vmware-install.pl from the VMware Tools package, remember to use the following, to force a module rebuild:

vmware-install.pl --clobber-kernel-modules=vmci    \
                  --clobber-kernel-modules=vsock   \
                  --clobber-kernel-modules=vmxnet3 \
                  --clobber-kernel-modules=pvscsi  \
                  --clobber-kernel-modules=vmmemctl

Note: I haven't tested Linux kernel 3.10.9 or later yet, but I will shortly and update this post to reflect those results (see here for the fix for the 3.11.0 kernel).

Good luck!