Moving on from Studio...

It's been a long time since VMware Studio came to be.

At present I'm migrating my OVA builds to Packer, which I'm already using for AWS image construction.

 Check it out: https://packer.io from the awesome peeps at Hashicorp.

Thanks for your interest in VMware Studio! It was a fun project and I got a lot of mileage out of it at VMware, HyTrust and Atlassian.

Create a bootable ISO installer from your VMDK disk files

I've run into a situation where I need to distribute a VM as a bootable ISO image, not the usual VM descriptor file + disk image(s).

Getting this to work was a little hacky but not too hard. My idea was to create a rescue CD/DVD ISO image file with an automated installer and the target VM filesystem contents.

The overall process looks like this:

1. build your appliace as usual
2. use VDDK to extract the full filesystem contents of your VM to one or more archive files
3. extract the contents of a Linux rescue CD (sysresccd) to a temporary file tree
4. copy the VA filesystem archives to the root directory of the rescue cd files (isoroot)
5. drop in an installer shell script named "autorun" into the isoroot
6. roll up the new ISO image via mkisofs

First I downloaded sysresccd from http://www.sysresccd.org/Main_Page and VMware's virtual disk access application VDDK from http://www.vmware.com/support/developer/vddk/

I do all my development on Linux (CentOS5 amd64) so to install VDDK I first had to install fuse and fuse-lib via "yum -y install fuse fuse-lib". After that I could expand the VDDK compressed tarball and run its vmware installer.

The "autorun" script performs the following functions:

a. sanity checks the system using dmidecode (to make sure it's not going to wipe out your workstation hard drive by accident)
b. autopartitions the first hard drive it finds (sda) by piping partition data to fdisk
c. formats the new partitions
d. mounts the new parttions
e. transfers the filesystem contents from the compressed tar archives
f. verify file checksums to ensure the transfer wasn't corrupted
g. update fstab and other config files if necessary
h. reboots

The ISO image is only ~12MB more than the OVF/OVA due to good compression of the appliance filesystem contents in the ISO image. The bulk of sysresccd is hardly noticed.

Cool eh?

Renaming OVF files

Studio2 creates both OVF v0.9 and OVF/OVA 1.0 specification files for VI3 and vSphere4 support respectively. Unfortunately Studio2 uses hardcoded filename suffixes of "OVF09" and "OVF10" to describe the two which doesn't really mean anything to a user who's trying to decide which variant to download.

To correct this naming issue you can edit the suffix hardcodes easily enough. Login to your studio2 vm as root and edit the following file:

/opt/vmware/lib/build/VADK/Constants.pm:

Replace the following section:

#
# OVF/OVA filename constants. These must agree with mkovf.
#
use constant OVF09FILESUFFIX    => '_OVF09.ovf';
use constant OVF10FILESUFFIX    => '_OVF10.ovf';
use constant OVF10OVAFILESUFFIX => '_OVF10.ova';

...With:

#
# OVF/OVA filename constants. These must agree with mkovf.
#
#use constant OVF09FILESUFFIX    => '_OVF09.ovf';
#use constant OVF10FILESUFFIX    => '_OVF10.ovf';
#use constant OVF10OVAFILESUFFIX => '_OVF10.ova';
# hackingstudio improved filename suffixes: 
use constant OVF09FILESUFFIX    => '_VI3.ovf';
use constant OVF10FILESUFFIX    => '_vSphere4.ovf';
use constant OVF10OVAFILESUFFIX => '_vSphere4.ova';

And also edit the file /opt/vmware/share/mkovf, replacing:

#
# These must agree with the values in the build module Constants.pm
#
OVF09FILESUFFIX="_OVF09.ovf"
OVF10FILESUFFIX="_OVF10.ovf"

...With:

#
# These must agree with the values in the build module Constants.pm
#
#OVF09FILESUFFIX="_OVF09.ovf"
#OVF10FILESUFFIX="_OVF10.ovf"
# hackingstudio improved filename suffixes: 
OVF09FILESUFFIX="_VI3.ovf"
OVF10FILESUFFIX="_vSphere4.ovf"

And that's it. Nothing to restart, your next build will have OVF and OVA files that are named more intuitively for VMware users.

If anyone is using studio2 to create appliances for non-VMware platforms I'd love to hear about it in the comments, thanks.

Setting User Passwords Longer Than 8 Characters

When creating Red Hat/CentOS appliances using Studio & Studio2 the passwords accepted for root and user accounts are truncated to 8 characters as they're encrypted using the very limited crypt function.

To use md5 hashes instead you need to generate an md5 hash on an existing Linux system, like:

[root@will cli]# adduser tmpuser
[root@will cli]# passwd tmpuser
Changing password for user tmpuser.
New UNIX password: [enter a long password, over 8 chars]
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Then grab the hash:

[root@will cli]# grep tmpuser /etc/shadow
tmpuser:$1$PhmFj24Z$nu/7FF2813kKiEt2DWiB81:14623:0:99999:7:::

In this case we want: $1$PhmFj24Z$nu/7FF2813kKiEt2DWiB81

Escape the dollar signs with a \ character for each: \$1\$PhmFj24Z\$nu/7FF2813kKiEt2DWiB81

Now edit your build profile XML file for the appliance you are working on and change the vadk:passwordFormat value to "des" and the vadk:password value to the escaped hash.

for example:

<vadk:User vadk:username="myuser" vadk:password="\$1\$PhmFj24Z\$nu/7FF2813kKiEt2DWiB81" vadk:passwordFormat="des" vadk:fullname="My User" vadk:uid=""/>

Don't mind that the passwordFormat says "des" when in fact we're using md5 hashes, it's a goofy misnomer for "already encrypted, just use the specified string".

And build. Boot your new appliance and try to login with only the first 8 characters of the specified password, now you should be denied as the full password is respected.

CentOS 5.4 support

Leong, a really solid guy at VMware, has a post up describing how to add a build profile for CentOS/Red Hat 5.4, here:

http://blogs.vmware.com/vapp/2009/09/vmware-studio-adding-rhel-54-support-in-minutes.html

Studio2 Suicide After Reboot

If you have to reboot the Studio2 appliance it will lose its OS image ISO internal loopback mounts. Upon losing them it will not simply try to remount them, instead it will try to download the image again but will save it with an indexed extension over and over until your Studio2 disk is full.

There are two fixes involved. The first simply attempts to remount the ISO. The second deletes the ISO (fragment?) before attempting to redownload the same image.

Here's the patch:

root@vmstudio:/opt/vmware/lib/build/VADK# diff -u /opt/vmware/lib/build/VADK/bkp/ISO.pm /opt/vmware/lib/build/VADK/ISO.pm 
--- /opt/vmware/lib/build/VADK/bkp/ISO.pm       2009-10-08 10:20:37.000000000 +0000
+++ /opt/vmware/lib/build/VADK/ISO.pm   2009-10-08 13:23:59.000000000 +0000
@@ -77,6 +77,12 @@
    #       
    my $already_mounted = `mount | cut -f3 -d' ' | fgrep $mountpoint`;
 
+# Will: simply remount it if possible
+if (!$already_mounted && (-f $filename)) {
+  &mount($filename, $mountpoint);
+  $already_mounted = `mount | cut -f3 -d' ' | fgrep $mountpoint`;
+}
+
    if (!$already_mounted) {
 
       if ($iso =~ /^(ht|f)tp:(.+)$/i) {
@@ -90,7 +96,12 @@
          if (-r $envFile) {
             $wgetcmd = ". $envFile; ";
          }
-         $wgetcmd .= 'cd '.$stageDir.'; wget '.VADK::Constants::WGET_TIMEOUT.' '.$iso;
+
+# Will: fix re-download attempts (were saving with .index extension)
+unlink($filename);
+$wgetcmd .= 'cd '.$stageDir.'; wget'.$iso;
+
+         # $wgetcmd .= 'cd '.$stageDir.'; wget '.VADK::Constants::WGET_TIMEOUT.' '.$iso;
 
          my $ret = VADK::System::systemWrapped($wgetcmd);
          if ($ret->{'exit_value'}) {

I also stripped out the retry and timeout arguments to wget as they were causing wget to abort on a peer reset instead of continuing with a new connection.

If you've run into this problem do delete all the files in the download ISO cache:

rm -vf /opt/vmware/cache/build/ISO/*

Porting Builds to Studio2

A few tips when migrating builds from VMware Studio v1 to Studio v2:

- studiocli has a built-in feature to convert build profiles from v1 to v2 but I've been unable to make that work and don't feel like fixing the python behind it

# studiocli -C -p studio1vm.xml
Traceback (most recent call last):
 File "/opt/vmware/share/build/profconv", line 658, in 
   main()
 File "/opt/vmware/share/build/profconv", line 639, in main
   osspecific(xp)
 File "/opt/vmware/share/build/profconv", line 406, in osspecific
   newurl.setContent(VMTOOLS)
UnboundLocalError: local variable 'VMTOOLS' referenced before assignment

So I used the Studio 2 GUI to rough out some new build profiles then with two vim sessions side-by-side I migrated the settings, users, scripts etc manually. That sucks pretty hard when you've got a handful of appliances to port.


- The embedded shell scripts used to require escaping on variable references, like:

FOO=/tmp/foo
echo 1 > \$FOO

..but in studio 2.0 the escaping is no longer necessary, like this:

FOO=/tmp/foo
echo 1 > $FOO

- studiocli can no longer be run with remote SSH due to some environment issue. Instead just run vabs.pl directly, as in:

ssh root@vmstudio2 /opt/vmware/share/build/vabs.pl \
                -cvp /tmp/profile.xml -i instanceX

It sure is nice building OVA and OVF 1.0 targets now. Retiring VMware Server 1 is a joy too as both the Studio2 VM and builds happen within one ESX system. Build times are improved by about 15% despite the additional targets.

I'm working on vApp creation to bundle up a handful of appliances in my nightly builds and can post about that if people are curious.

VMware Studio 2.0 shipped!

Last Monday the production release of VMware Studio 2.0 made its way to the download servers.

It was great seeing some of the VMware Studio team on the VMworld show floor. There's a lot to be proud of with last week's production release of Studio 2.0.

Upgrade from the Studio 2.0 Beta release immediately. I advise Studio 1.0 users run Studio 2.0 side-by-side with Studio 1.0 to ease migration.

Studio 2.0 Beta got some security love from Security Focus. Good times

Winner VMworld09 Best of Show and Gold Security!

Congrats to my fantastic team of engineers and architects at HyTrust for sweeping the awards at this year's VMworld in San Francisco.

http://hytrust.com/

VMworld 09

Hey folks I'll be at VMworld on Wednesday and expect to make the party afterwards. You can visit me at the booth of my brilliant security startup HyTrust. I'm the short blond Dutch/Canadian/Californian. Say hi :)

VMware Studio 2.0 Beta1 is out!

And it looks very good. The underlying product framework is fundamentally the same but there are loads of new features.

64bit Linux builds are supported as are Windows 2003,8. Windows makes a lot of sense for big enterprises who need to standardize internal VM images. It's a big step up over using a tuned VM template.

You no longer need to have a copy of the venerable VMware Server 1.0 to provision VMs. You can now use Workstation and ESX3/4/VC. Have a look:




You now have a choice of v4 and v7 virtual hardware with enforced CPU and memory limits to match. Using v7 compatibility costs you some older hosted compatibility (Server 1.x and Player) but will let your appliance users scale the VA to 8 vCPUs and 255GB RAM for heavier workloads:





Multiple virtual appliance images can be rolled up into one "vApp" bundle. This really helps with scalability especially since different components of a software platform have different bandwidth and headroom needs. Think of a scaled LAMP stack but with Apache/perl on one VM and MySQL on another. The MySQL VM can be hosted on a physical server tuned for fast IO and the Apache/Perl VM can be hosted on a much cheaper edge server. That would be a great candidate for a vApp style multi-VM appliance. One OVA, many VMs, one logical VA.






The build targets include OVF v1.0 in addition to the OVF v0.9 spec used by Server 1.0. OVA bundles are now supported as an additional build target. This is an archive of the OVF XML file along with the VMDKs but to my disappointment Studio 2.0 does not sign these to ensure their integrity for distribution. I hope they consider this in the next release.

There are better tools for helping bundle applications for inclusion in the appliances, for both the set of supported Linuxes and Windows too. I haven't dug into that much as my professional life is in already well bundled in .war and .rpm files these days. The dependency resolution is far improved, that should help new users.

Under the hood the PXE boot sequence used during VA provisioning has been replaced with a more reliable canned VMDK bootstrap process. This change is transparent to most users but can help keep Studio from getting confused by custom PXE implementations on the same LAN. A good change for sure.

Peruse the release notes for Studio 2.0 Beta here:

http://communities.vmware.com/viewwebdoc.jspa?documentID=DOC-10175

And download it. Give it a whirl. I love to see a relatively OS agnostic vendor like VMware reduce the basic OS to a rather small/trivial piece of an application. OS vendors should be freaking out right now and innovating like mad before they're as unseen and ubiquitous as the average C library...

Windows support

I was just asked about creating a VMware Studio template for Windows.

Edit July 2009: Windows 2003/2008 support is in the beta release of Studio 2.0, have at it :)


Original post:

In a nutshell...

The VMware Studio build system was architected with Windows in mind.
The XSL template necessary would create a Windows unattended install file.
VMware would have to deliver new guest software for Windows too,
though I generally build appliances without the VMware guest stack.

The PXE setup code in a Windows build profile XML reference would take a bit of
effort but is doable.

What flavour of Windows are people using for appliances?

Anyone tried unattended installs of Windows 7?

VMware Studio and its host hardware

I've been building appliances on an AMD phenom 9850 quad core with 8GB RAM of late. This system has been running Ubuntu 8.04 amd64 and my builds took about 45 minutes when my local Aberdeen NAS was behaving.

This week while attempting to upgrade to Ubuntu's Jaunty the software raid mirroring (!) fell over and that build box crashed. It was really strange since grub settings were saved correctly on one drive in the mirror set but not the other.

So I blew it all away and installed CentOS 5.2 x86_64 [ 5.3? eh? before xmas *cough* ;) ] ..And put VMware Server 1.0.8 on there without installation headaches and hey, my builds are down to 26 minutes. Fantastic improvement.

I may use Ubuntu again as a deskside workstation but never on a server. Seriously flakey upgrades. RHEL/CentOS has the reliability win for now.

I know VMware Server 2 is gaining popularity but from what I know VMware Studio still only supports Server 1.x. Would love to see ESX support as I have a farm of cool AMD Shanghai boxes now.

I've an Intel Nehelem i720 system on order. 12GB ddr3 and 4 sata drives in a stripe set while install sources will continue to reside on the NAS. I like to keep build hosts as stateless as possible. Studio logs build times in both its debug and verbose logs and I'll post a follow-up to that once the new box is online. I'm guessing 20 minutes, will see..

For home I have an AMD Shanghai 720 on order. Don't know if I'll get VMware Server running on that unless someone asks me to. That system will replace a pre-release first-gen opteron 2ghz that is more than 5 years old. Wow. I miss getting free & early access to AMD and Intel CPU samples.

For the record the Aberdeen NAS runs Windows and absolutely sucks serving NFS. Avoid them if you have any Linux/Unix/OSX infrastructure.

From the GUI to the CLI

VMware ships Studio as a virtual appliance (VA). I'm guessing they use VMware Studio to create VMware Studio based on the embedded CIM stack and management web GUI.

In this appliance there are a bunch of files. Lots of these are normal Linuxy files, many are from VMware.

The Studio VA itself is Ubuntu Feisty, 32bit. Almost all of the VMware bits reside in /opt/vmware/.

The easiest way to explain what files live where is to walk through an appliance build from scratch using the web interface.

Login to the VMware Studio GUI, http://whateverIP/

Click the Create Appliance button near the right side of the screen, select your base OS and specify a name for the appliance:

The list of base operating systems is generated by the XML files found in the directory:
/opt/vmware/etc/build/templates/

You'll notice an extra OS in the screenshot above, CentOS 5.2 x86_64. I added that by copying the file /opt/vmware/etc/build/templates/centos/5/2/build_profile.xml and making a few tweaks to it--those tweaks are another post in themselves.

Using the web GUI, type in your appliance name, version, description, etc. Keep clicking Next at the bottom of the screen to progress through the wizard. The only important thing here is that you have a VMware Server v1.something installed and accessible for the last step.

Click Save and Build to ensure this new profile and your build environment settings are working. If you have issues please rtfm else respond to this post and we can figure it out.

At this point you should have a completed build from the web GUI. Great stuff. What has happened under the hood is that the reference profile template was used to create a new appliance profile XML file in the directory /opt/vmware/var/lib/build/profiles/. The file in this directory should have a familiar name to it.

From now on you're ready to build from the command line. Run the command:

studiocli -cvp /opt/vmware/var/lib/build/profiles/myAppliance.xml

...And there you go. Nice. Debug-level verbosity is had with a second -v argument, as in:

studiocli -cvvp /opt/vmware/var/lib/build/profiles/myAppliance.xml

At this point you no longer need to use the web GUI to make changes to the appliance profile XML file. That file looks much like an OVF file with a few VMware Studio enhanced sections.

Nifty eh?

Building appliances with other OS images (ISO files)

VMware Studio ships with support for virtual appliance creation using a few different OS versions. Each OS version requires a specific ISO image with fixed md5 checksum.

Fortunately, the ISO image and its checksum are part of the appliance profile XML file and we can change those readily. People who roll their own ISO images with Fedora's Revisor or something similar will generally want to use a new ISO image each time they build an appliance.

I'm not going to describe how to build your own ISO image here but let's assume you regularly build one and save it to a web-accessible folder, for example:

http://yourserver/iso/latest/my-custom-centos52.iso

Now edit your appliance profile XML file to use this ISO image instead of the stock value. Appliance profiles are found in the directory /opt/vmware/var/lib/build/profiles/.

Look for the line:

<vadk:iso path="file:///opt/vmware/www/ISV/ISO/CentOS-5.0-i386-bin-DVD.iso" 
  md5sum="b5633ee6ee3b2e10d92672c74e594d75">
</vadk:iso>

And change it to point to your custom ISO image instead and change the md5sum to null to skip that validation:

<vadk:iso path="http://yourserver/iso/latest/my-custom-centos52.iso " 
  md5sum="">
</vadk:iso>

Studio will cache ISO images locally so to make it download this ISO image for each build we have to flush Studio's local ISO extraction cache by running:

root@localhost:~# studiocli -v --flushIsoCache

And now you can fire off your appliance builds as usual:

root@localhost# studiocli -cvp myAppliance.xml -i 20081010
Using build instance name: 20081010
Validating profile schema...
Validating Appliance Version formatting...
Validating Appliance Memory Size...
Validating non-empty ISO path...
Validating Appliance usernames and passwords...
Validating Appliance logo path...
Validating ovf:DiskSection_Type...
Validating ApplicationPackages URL...
Validating OS Package elements...
Validating controllers and disks...
Validating file transfer for ProvisioningEngine...
Validating provisioning engine connection...
Validating vmguest_lan...
Validating available disk space...
Preparing the OS installation files.
Creating the virtual machine.
Installing the OS and applications.
Creating an inventory of installed software.
Packaging the virtual machine.
Creating a software update for upgrading older appliance releases.
Publishing the software update to remote servers.
Removing temporary files.
The build has completed successfully.