From the labs: Building an Ubuntu 14.04 Appliance with VMware Studio 2.6

VMware Studio 2.6 was released way back in March 2012,  and surprisingly there seems to be no new update in sight. While VMware Studio technically still works, even with newer versions of ESXi and vCenter, the supported operating systems for the appliances it can build is somewhat outdated:

  • Red Hat Enterprise Linux 5.5/6.0
  • SUSE Linux Enterprise Server 10.2/11.1
  • Ubuntu 8.04.4/10.04.1
  • Windows Server 2003 R2 / 2008 R2 w/SP1

The Problem:

For a yet to be announced project we are working on internally at EVRY, we needed to build an appliance that was based on newer software packages and development tools. Recent events like heartbleed and shellshock also highlight the need to build new appliances on new and supported distributions.

Attempts at upgrading an existing Ubuntu 10.04.1 appliance to 14.04 failed miserably, due to architectural changes between the Ubuntu versions and how Virtual Appliance Management Infrastructure (VAMI) is installed by VMware Studio and in the end we were pretty much left to two options:

  1. Build the appliance from scratch, and lose VAMI, which was one of the primary reasons for building the appliance with VMware Studio in the first place.
  2. Find a way to build the appliance with Ubuntu 14.04, with VMware Studio.

Option 1 felt a bit like giving up, and option 2, well that was a challenge we couldn’t just walk away from.

The Solution:

Thanks to the brilliant mind of my coworker Espen Ødegaard, we were able to come up with a set of solutions that does the trick.

First we added a new profile to VMware Studio connecting to the VMware Studio VM via SSH, and by issuing the following command:
[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”1″]
studiocli –newos –osdesc “Ubuntu14.04” –profile /opt/vmware/etc/build/templates/ubuntu/10/041/build_profile.xml
Basically this creates a new OS template in VMware Studio by copying the existing Ubuntu 10.04.1 profile.

Next edit line 462 in /opt/vmware/etc/build/templates/Ubuntu14.04/Ubuntu14.04.xsl and change scd0 to sr0.

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
if ! mount -t iso9660 -r /dev/scd0 /target/${cdrom_dir} ; then \
if ! mount -t iso9660 -r /dev/hda /target/${cdrom_dir} ; then \
cdrom_mounted=0; \
fi ; \

This fixes a problem with the appliance not being able to mount the Ubuntu installation iso when it is built. Place the Ubuntu 14.04 ISO in /opt/vmware/www/ISV/ISO, and create a new Build profile using the VMware Studio Web Interface.

Now, before an appliance can be built, we need to fix some other problems that prevent VAMI from starting up, and preventing login to the VAMI web interface. First of, make sure that libncurses5 is added as package under Application -> List of packages from OS install media. Next, add the following to the first boot script under OS->Boot Customization, we can move around those problems.

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
# Create symlinks required for Ubuntu 14.04 and VAMI

# Copy and symlink libncurses to the location VAMI looks for them

cp /lib/i386-linux-gnu/ /opt/vmware/lib/
rm /opt/vmware/lib/
ln -s /opt/vmware/lib/ /opt/vmware/lib/

# Symlink PAM libraries in order for them to work with VAMI
# This “unbreaks” authentication in the web interface
mkdir /lib/security
ln -s /lib/i386-linux-gnu/security/* /lib/security/

For details on how all of this works, and how to create build profiles, check the official VMware Studio documentation.

The build process should now complete successfully, and you should have an Ubuntu 14.04 based appliance built with VMware Studio!

Note that all of this is completely unsupported by VMware, and you are pretty much on your own. Hopefully there will be a new version of VMware Studio available soon, and we won’t have to rely on unsupported hacks to get it working with newer operating systems.

Adding a secondary NIC to the vCenter 5.1 Appliance (VCSA)

While building my lab environment, I ran into a situation where I wanted to have a completely sealed off networking segment that had no outside access.

This is a trivial task on it`s own, just create a vSwitch with no physical NICs attached to it, and then connect the VMs to it. The VMs will then have interconnectivity, but no outside network access at all.

In this particular case, I was setting up a couple of nested ESXi servers that I wanted to connect to the “outside” vCenter Appliance (VCSA). This VCSA instance was not connected to the internal-only vSwitch, but rather to the existing vSwitch that as local network access.

Naturally, the solution would be to add a secondary NIC to the VCSA, and connect that to the internal-only vSwitch.

It turns out that adding a secondary NIC to a VCSA instance, isn`t as straight-forward as you might think. Sure, adding a new NIC is no problem through either the vSphere Client, or the vSphere Web Client, but getting the NIC configured inside of VCSA is another matter.

If you add a secondary NIC, it will turn up in the VCSA management web page, but you will not be able to save the configuration since the required configuration files for eth1 is missing.

In order to rectify this, I performed the following steps:

  1. Connect to the VCSA via SSH (default username and password is root/vmware)
  2. Copy /etc/sysconfig/networking/devices/ifcfg-eth0 to /etc/sysconfig/networking/devices/ifcfg-eth1
  3. Edit ifcfg-eth1 and replace the networking information with your values, here is how mine looks:
    [cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
  4. Create a symlink for this file in /etc/sysconfig/network[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
    ln -s /etc/sysconfig/networking/devices/ifcfg-eth1 /etc/sysconfig/network/ifcfg-eth1[/cc]
  5. Restart the networking service to activate the new setup:[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
    service network restart[/cc]Check the VCSA web management interface to verify that the new settings are active

Client 2013-04-25 10-54-37

By adding a secondary NIC, configuring it and connecting it to the isolated vSwitch I was now able to add my sequestered nested ESXi hosts to my existing VCSA installation.


Client 2013-04-25 13-07-01

There may be several reasons for a setup like this, perhaps you want your VCSA to be available on a management VLAN but reach ESXi hosts on another VLAN without having routing in place between the segmented networks, or you just want to play around with it like I am in this lab environment.


Is this supported by VMware? Probably not, but I simply don`t know. Caveat emptor, and all that jazz.

Update February 2016:

This post is written with VCSA5.x in mind, and is not tested on VCSA 6.x. William Lam has posted Caveats when multi-homing the vCenter Server Appliance 6.x w/multiple vNICs with information on what caveats exist if you are looking to do this with the newer v6.x infrastructure.

Iomega IX2 and Time Machine Support

As Mr. Simon Seagrave has pointed out, there is a fix available to enable OSX Lion Time Machine support for Iomega IX2 and IX4 NAS storage devices.

I decided to take this a little step further, and try to upgrade my old (and discontinued) Iomega IX2-200 to the new IX2-200 Cloud Edition firmware.

Initially this was a big failure, as I seemingly managed to brick my device. It was only responding to pings (so the TCP/IP stack was loaded and working), but I could not bring up the web based management tool nor connect via telnet or SSH.

Thankfully Will van Antwerpen had investigated the firmware upgrade to cloud edition a bit more than I had, and pointed me to the General NAS-Central Forums where I found a link to a great HowTo explaining the entire process: Upgrading Iomega ix2-200 to Cloud Edition.

As that article also mentions, I had to do the process twice to get it to kick in and un-brick my IX2-200 and get it running with the new Cloud Edition firmware.

After configuring the IX2 with security and setting up Time Machine on the Macbook Air, Time Machine seems to be running without problems.