Configuring the vMA as ESXi syslog server

An ESXi host has a number of important logfiles located in /var/log (or /scratch/log) for each of it’s components. Reviewing those logs the standard way can be quite cumbersome: Some logs can be viewed through the DCUI (if you like to torture yourself) or you have to enable SSH each time on each host to browse through the logs. Compared to that, having your host-local logs in one central place can be very useful for things like audits or troubleshooting. VMware also noticed that back in vSphere 4 an included the vilogger component directly into the vMA. Unfortunately vilogger was removed with vSphere5 for reasons completely beyond me.
Instead VMware included the ESXi Syslog collector for vCenter, but it’s quite basic and not really the greatest way to centralize your hosts logs, especially in larger environments. I’m also missing my bash and *nix tools to properly filter and navigate through the volume of information contained in the logs.
So as the vMA 5.x Linux OS already comes with the default syslog-ng daemon, why not take advantage of that and let your hosts log there? The steps outlined here were done with the vMA 5.0 but should work without a hitch on the 5.1 release too.

Continue reading

Virtual Appliance nitpicking and vMA optimizations

Unfortunately, most virtual appliances, including those distributed by VMware are not quite well-maintained. Nitpicking incoming.

This starts with them being released in the old, ESX3.x compatible vHardware version 4. Backwards compatibility is cool and all, but I suppose they could have at least jumped on the v7 wagon with the release of vSphere5 (and HW v8).

Another thing I dislike is the frequent use of the Open VMTools. Now don’t get me wrong, I usually love open source implementations, but the problem with the Open VMTools is that you lose the ability of quickly being able to check if a guest’s tools are up-to-date on a given host.

Instead of a clear “Current” or “Out of date” message, you’re simply greeted with an ambigious “Running/3rd Party Independant” or “Unmanaged” for the VMs.
You also can’t simply upgrade the Open VMTools via the vSphere easy Install/Upgrade VMTools wizards or via Update Manager.

Virtual Appliances want to be operated in a fire&forgot approach. After swiftly deploying them, you’re supposed to just use them for what they were intended to and don’t think about anything else you might have in mind when you deploy an ordinary OS in a VM. Updating a VA also often means deploying the whole new OVF package of the current version and deleting the old VM, even for minor version upgrades. Luckily this seems to slowly improve with built-in update functions. (It’s a shame VMware never made use of the vima-update functions back in the day.)

Besides these points theres always a handful of things to make me frown or chuckle, or sometimes both:

vi-admin@vma:~> cat /proc/cmdline
root=/dev/sda3 append server= serverdir=/build/.0/repo/iso resume=/dev/sda2 splash=silent showopts quit

Um, ok VMware, whatever floats your boat at


A couple of things to make working with the vMA more convenient
Here are some things I would change on a freshly deployed vMA in order to make my life easier:

  • install GNU screen:
    yast2 -i screen
  • disable IPv6 which I don’t use in my environment:
    echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf ; sysctl -p
  • getting a list of all registered hosts at every login/screen window so i can quickly copy hostnames for use with my vicfg-*, esxcli etc. commands:
    echo "vifp listservers | sort" >> ~/.bashrc
  • fixing keybinding problems when connecting by SSH from my urxvt host for at least forward/backward words:
    ctrl-v ctrl-leftarrow and ctrl-v ctrl-rightarrow – fixing the .inputrc with "\eOd": backward-word and "\eOc": forward-word
  • creating a tiny script that lets me quickly open resxtop sessions to my commonly-named hosts without having to change the vifptarget every time, like “./ 0014”:

    resxtop –server esxhost$@.localdomain –user root