Packer vmware-iso builder on ESXi without DHCP

When you are building Windows Server 2012 R2 base images (vSphere Templates) using packer on vSphere (using vmware-iso packer builder); the process usually relies on the windows server to get an IP address automatically via DHCP. This allows the packer builder to then communicate to the server over WinRM and complete the provisioning.

What happens when there is no DHCP available in your vSphere VM Network?

The easy solution is to have the bootstrap of the windows server set a static IP for the server.
This would allow the packer builder to then communicate to the server over WinRM and complete the provisioning.
I already provide an Autounattend.xml to the windows server via the packer floppy_files stanza for the vmware-iso builder.

These user variables are populated with the environment specific floppy files:

I pass the config json file into the packer build command as shown below. This allows us to pass in different config per environment to the same build template for packer.

packer.exe build -var-file=Config-VMWare.json .\PackerBaseWin2012R2-VMWare.json

The Autounattend.xml executes the file a:\vmware-userdata.ps1 as the last step of the FirstLogonCommands setting of the Autounattend process.

The script for this particular environment then uses powershell cmdlets to configure the required static IP address allocated to the Packer Build VM:

Note: If you don’t wait long enough for the boot process to complete; the vmware-iso builder may detect the self assigned IP (169.x.x.x) prior to the userdata script setting the Static IP.
To solve this you can set the vmware-iso builder boot_wait to wait a bit longer, e.g. 10 mins.

This solves how to use packer on vSphere for Windows Server 2012 R2 bootstrapping where you don’t have a DHCP server on the subnet.

Setup Sublime Text for F# Development

After being asked to use Visual Studio 2015 for F# Development, I decided it’s way more lightweight to to develop it on my Mac using Sublime Text 3.

Software you need installed:

• Install Mono on your Mac
• Of course Sublime Text 3
• And the best package manager for Sublime, Package Control.

Install (using package control) these packages with package control in Sublime Text:

• F# – Gives you syntax Highlighting
• F-Sharp – Autocomplete, tooltips, definitions, etc.
• SublimeREPL – A multi language REPL including F#

If you are used to Visual Studio for any F# development; you can create some Sublime text keyboard shortcuts using your key bindings settings:

• Open REPL : CTRL+ALT+F
• Send selected code to REPL : CTRL+SHIFT+ENTER

The bindings I use are shown below:

You’ll want to configure Sublime 3 indentation settings to include these options to replace Tabs with spaces; as Sharp hates your tabs.

This setup also works on Sublime for Windows, but you need fsi.exe in your path and working with all dependencies (Windows SKD, .NET Framework etc.).

Windows 10 UEFI USB Boot in VMWare Fusion 7

You’ve downloaded your purchased Windows 10 ISO from Microsoft, and you’ve managed to create a bootable UEFI USB stick.
Now you’ve decided to run Windows 10 in VMWare Fusion Pro on your Mac. Yet the USB stick can NOT be booted from.
There is a solution. VMWare fusion has some (unsupported) EFI options you can enable to effect a USB boot.
First you’ll want to create a Windows 10 VM in VMWare Fusion.
Create a new VM, and select the more options icon:

Select Create a custom virtual machine and select Continue:

Select Windows 10 as the operating system, and select Continue – x64 is selected here as I’m 64 bit all the way:

Leave the virtual disk options and select Continue:

On the Summary Screen, you can use the Customize Settings button to change your VM defaults. I updated my RAM to 8GB, my CPU Cores to 2, and changed the VM Disk size to 100GB (60GB may be a bit small for most power users).

Before you start the VM; you’ll need to modify the vmx file directly.

1. In the Virtual Machine Library, right click on the Windows 10 VM and select Show in Finder.
2. Right click on the vmwarevm container and select Show Package Contents
3. Edit the *.vmx file using your favourite text editor
4. Append the following options to the configuration to enabled EFI booting:

firmware = "efi"
efi.legacyBoot.enabled = "true"


The Legacy boot option allows VMWare to see the USB device in some cases; and was required for me.
Boot your new VM:

You’ll find that the new EFI boot loaders are picked up, but not yet the USB. Since you couldn’t attach a USB before starting, you can do it now. Open the VM preferences and attach the USB containing the EFI Boot files:

VMWare will now boot into the Windows 10 setup.

Thanks to a post by A Virtual Den for pointing me in the right direction for the VMX LegacyBoot option!

Attempt to Deploy Netflix Edda on Wildfly 8.x

I’ve been trying to find a production platform for Edda, the Netflix OSS app for tracking AWS resources.

The application is written in Scala, which gets compiled as Java bytecode. The build toolset used by Netflix is gradle, and they deploy the application for testing into Jetty. Jetty can be used in a production environment, but the setup that comes with the build set with Edda is not really designed with a production server in mind. That said, a lot of people just end up running Edda by manually running up Jetty as a background process on a Linux box. Since I’ve been using Java application servers for quite a number of years (Websphere AS, Tomcat, Glassfish); I understand the need to run compiled Java web apps in production infrastructure. Therefore, I have been trying to find a reliable, OpenSource Java Web Application Server (WAS) to host Edda.

I’ve been thinking of trying out JBoss in the past, and the 8th major release of Jboss is now known as Wildfly, it seemed like a likely target for deploying Edda to.

The gradle build of Edda produces a WAR file, ready for deployment to a WAS. However, the war file from the gradle build won’t deploy by default on Wildfly, as shown with this error:

01:12:50,021 ERROR [org.jboss.as.server] (XNIO-1 task-10) JBAS015870: Deploy of deployment "edda-2.1.war" was rolled back with the following failure message:
{"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host.\"/edda-2.1\"" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host.\"/edda-2.1\": Failed to start service
Caused by: com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes."}}

Edda uses Jersey (a standard and portable JAX-RS API) for RESTful Web services, but the WAR file won’t deploy properly with the servlets configured to use Jersey. This is due to the fact that Jersey is no longer a (default) option for JAX-RS web services on Wildfly. It comes integrated with RestEasy as the JAX-RS implementation instead.

Using RestEasy makes it necessary to change your Web.xml file because Jersey and RestEasy have different deployment configurations. This will likely to apply to any Wildfly 8.2 release, even though I’m using 8.2.0

The solution for Edda; is to modify the web.xml that gets built into the WAR file. I’ve committed the modification for web.xml to a branch on my fork of Edda. This solves the deployment issue when you try to deploy Edda as a WAR file into Wildfly.

Yet after all this; I can’t actually get Edda to work properly on Wildfly.

In the end I went for the good old Tomcat Java Web App Server, and Edda runs with an out of the box build.