Using Ansible's WinRM configuration script with vSphere

13 Jul 2016

Method #1 - Guest Customization

Since this took me a few tries to get this working I thought it would help someone out there if they need Ansible working on boot. When adding a customization spec add the lines below to run once.

powershell -command "& {Set-ExecutionPolicy Unrestricted}"

powershell -command "& {Invoke-Expression ((New-Object System.Net.Webclient).DownloadString(\"https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1\"))}"

Method #2 - VMware Tools

With VMware Tools installed the configuration of WinRM can be executed via the guest operations API. There is already an Ansible module - vmware_vm_shell available for use. The playbook is available below.

---

- name: Ansible / WinRM / VMware vSphere Guest Tools 
  hosts: windows
  gather_facts: False
  tasks:
    - name: Enable WinRM to be used with Ansible 
      local_action:
        module: vmware_vm_shell
        hostname: 10.53.252.111
        username: Administrator@vsphere.local
        password: "" 
        vm_username: Administrator
        vm_password: ""
        vm_id: ansible-tools
        vm_shell: 'c:\windows\system32\windowspowershell\v1.0\powershell.exe'
        vm_shell_args: "" 
      with_items:
        - '-command "& {Set-ExecutionPolicy Unrestricted}"'
        - '-command "& {Invoke-Expression ((New-Object System.Net.Webclient).DownloadString(\"https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1\"))}"'
        - '-command "& {Set-ExecutionPolicy RemoteSigned}"'

Sources

http://www.davidklee.net/2012/09/05/execute-a-powershell-self-elevating-script-after-a-vmware-template-deployment/
http://blog.rolpdog.com/2015/09/manage-stock-windows-amis-with-ansible.html

Where ESXi belongs - Nested under KVM

25 Mar 2015

I can hear it now, why would you want to do that? Well for me the motivation was I need to test vSphere (ESXi and vCenter) automation and I don’t want to install VMware Workstation to do it.

First up, Nested ESXi

As always dependencies are first. I am using Fedora 21 so the packages commands will be related.

yum groupinstall "Development Tools" -y
yum install gcc-c++ glib2-devel zlibrary zlib-devel pixman-devel libfdt-devel spice-protocol SDL-devel spice-server-devel -y

QEMU Changes

Fortunately we have some very smart people at VMware that are willing to help our crazy cause. QEMU has changed since this post was originally written and so we must modify the patch. Below are the modifications required for QEMU 2.3, which is the latest development release - your mileage my vary kinda a thing but I haven’t had a problem yet.

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 36c69d7..6952bb3 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -242,8 +242,7 @@ static void pc_init1(MachineState *machine,
     }

     /* init basic PC hardware */
-    pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy,
-                         (pc_machine->vmport != ON_OFF_AUTO_ON), 0x4);
+    pc_basic_device_init(isa_bus, gsi, &rtc_state, &floppy,TRUE, 0x4);

     pc_nic_init(isa_bus, pci_bus);

With the modified QEMU lets get the source, patch and recompile.

Patch and compile QEMU

cd /opt
sudo git clone https://github.com/qemu/qemu.git
cd qemu
sudo curl "https://gist.githubusercontent.com/jcpowermac/3d9c732be08404302083/raw/ba97ceceefb2ffb085fa8da0f5f5a6142127454e/qemu.patch" | sudo patch -p1
sudo ./configure --enable-kvm --target-list=x86_64-linux-user,x86_64-softmmu
sudo make -j8
sudo wget "https://gist.githubusercontent.com/jcpowermac/36bfa62cd60781264b3f/raw/f26aa286d5ab85f17555141e04ab549e10727475/qemu-kvm"

This will leave our original QEMU install untouched, which is probably a good thing. Next up we need to define a virtual machine.

Create the ESXi virtual machine

There is an issue with ESXi 5.5 and the e1000 network adapter, so we have no real choice except to use vmxnet3. Below is an example domain specifically for 5.5 because of the inclusion of vmxnet3 adapter. ESXi 6.0 can and should be using e1000.

<domain type='kvm' id='12'>
  <name>esxi</name>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/opt/qemu/x86_64-softmmu/qemu-kvm</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/virtualmachine/esxi2'/>
      <backingStore/>
      <target dev='sda' bus='sata'/>
      <boot order='2'/>
      <alias name='sata0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='sata' index='0'>
      <alias name='sata0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <source bridge='ovsbr0'/>
      <vlan>
        <tag id='252'/>
      </vlan>
      <virtualport type='openvswitch'>
      </virtualport>
      <target dev='vnet1'/>
      <model type='vmxnet3'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' port='5901' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
    <video>
      <model type='vga' vram='9216' heads='1'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
  </devices>
</domain>

To define a new guest, do the following. A cd-rom will need to be added and most likely source bridge will need to be changed but the general hardware will be correct. Any of those changes can be done in virt-manager.

wget "https://gist.githubusercontent.com/jcpowermac/05e2faa322427f28b907/raw/6149bcc2e5420d13afa96d0f58abc91d6dc84058/esxi.xml"
sudo virsh define esxi.xml

Sources

https://communities.vmware.com/thread/451412 http://mattinaction.blogspot.de/2014/05/install-and-run-full-functional-vmware.html

Hanlon now supports Windows provisioning!

02 Mar 2015

It has been a long road but we finally have the ability to provision Windows in Hanlon. Currently it is limited to Windows 2012 R2 but the foundation is available to create additional models for the various client and server versions. The rest of the post is devoted to the Windows specific aspects of Hanlon provisioning a Windows instance, Tom McSweeney has created an excellent blog post describing the server component changes

Design Details

One of the important goals of this effort was to make sure that Windows provisioning followed as close as possible to the design of existing OS images, models and policies. This with the added constraint of avoiding a CIFS share if at all possible provides an incredibly unique solution for Windows installation.

WinPE Image

Since building a WinPE image is required we tried to make it as painless and automated as possible. We have included the build-winpe.ps1 script within ${HANLON}/scripts/winpe.

Image Details

We add quite a few packages to the WinPE image, this includes:

WinPE-WMI
WinPE-NetFx
WinPE-Scripting
WinPE-PowerShell
WinPE-Setup
WinPE-Setup-Server
WinPE-DismCmdlets

There are a few to note directly. We used PowerShell extensively in the hanlon-discovery and windows_install.erb, PowerShell is significantly easier to manage than legacy scripting languages, so WinPE-PowerShell is included. WinPE-Setup-Server as named is the setup executable and files required to launch a Server based setup, which we need since we are not using CIFS mapped back to an extracted Windows ISO. And finally including WinPE-DismCmdlets is our solution to adding drivers to the installed Windows image.

Drivers

To support your specific hardware at a minimum network and storage drivers will be required and available in %SYSTEMDRIVE%\drivers at the time of build-winpe.ps1 execution. The directory structure should not matter since we are using the recursive option with Add-WindowsDriver cmdlet.

Build Process

The build script performs the following actions:

First, it creates a mount point for WinPE, a directory for the scripts we’re adding to WinPE, and a directory for the drivers that are being added to WinPE if it doesn’t already exist (these directories are created on the root of the system drive).
Next, it tests for an installation of chocolatey and installs if unavailable.
Then install Windows ADK via chocolatey. If this fails, execute our fall back method for installation.
Next, it copies the the winpe image (winpe.wim) from Windows ADK path to a temporary location and mounts that image locally.
It then adds a few additional (required) Windows packages to the winpe image
Next, it adds an English language pack to the winpe image
Then, it adds the drivers needed for network and storage in your hardware to the winpe image (from the C:\Drivers folder)
Next, it downloads the hanlon-discover.ps1 script from Hanlon’s GitHub repository and adds that script to the winpe image
Next, it creates a startnet.cmd script and adds it to the WinPE image, generates a language ini file, and modifies the winpe registry (to disable the CD-ROM when the winpe image boots).
Finally, it unmounts the winpe image and renames the resulting image based on date and time.

Execution of build-winpe.ps1

Open a new PowerShell prompt and execute the commands below. The saved image will be in %SYSTEMDRIVE%\winpe named based on the current date and time.

Set-ExecutionPolicy Bypass -Confirm:$false -Force
Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/csc/Hanlon/master/scripts/winpe/build-winpe.ps1' -OutFile build-winpe.ps1
. .\build-winpe.ps1

Video Demo of Build Process

Hanlon Discover

The only third-party modification to WinPE image is the addition of the PowerShell script hanlon-discover.ps1. The only purpose of this script is to determine the location of the Hanlon server and execute the windows_install.erb.

We discovered last April that Windows DHCP client has no easy mechanism to support user-defined options without using the Win32 APIs. Fortunately we ran across this blog post providing the necessary details and PowerShell script that we could start with to retrieve the Hanlon specific options from the DHCP server. The Windows DHCP client supports vendor-encapsulated-options which can be used in conjunction with vendor-option-space to construct the encapsulated option.

Creating a option space:

option space hanlon;
option hanlon.server code 224 = ip-address;
option hanlon.port code 225 = unsigned integer 16;
option hanlon.base_uri code 226 = text;

Using within a subnet definition:

class "MSFT" {
  match if substring (option vendor-class-identifier, 0, 4) = "MSFT";
  option hanlon.server 192.168.122.254;
        option hanlon.port 8026;
        option hanlon.base_uri "/hanlon/api/v1";
        vendor-option-space hanlon;
}

We create an object based on the values retrieved from the vendor-encapsulated-options section of the registry. The object properties are used to construct the proper uri to the RESTful endpoint of Hanlon. Since there isn’t a method to pass boot time arguments to Windows we use WMI to determine the SMBIOS uuid which can be used in a RESTful request to retrieve the active_model. Once the active_model is determined the windows_install.erb is requested and executed which continues the process.

Windows Install

This script picks up where hanlon-discover.ps1 leaves off. The first task is where to grab the install.wim. In order to deploy Windows without CIFS we needed a temporary location to store the install.wim, but the question was where to put it. I knew that Windows setup would want the beginning of the disk for itself so why not create a partition at the end of the disk. Using WMI to grab the size of the disk, we subtract 8GB and use that as the offset to diskpart.

$image_disk_size = 8
$offset = [math]::floor((Get-WmiObject Win32_DiskDrive).size / 1024) - (1024*1024*$image_disk_size)

$command = @"
select disk 0
clean
create partition primary offset=$offset
select volume 0
format fs=ntfs label=image quick
assign letter=I
"@

$command | diskpart

I am sure some of you are wondering can I get that 8GB returned and the answer is yes. Just delete the partition and extend the system drive within Disk Management. In a follow up we will be adding additional scripts that could perform this action.

Next we download the drivers, the install.wim and the autounattend.erb. After those three files are downloaded we inject the required drivers into the install.wim using the DISM PowerShell cmdlets.

mount-windowsimage -imagepath "I:\install.wim" -index <%= wim_index %> -path "I:\mount-point" -erroraction stop
Add-WindowsDriver -Recurse -Path "I:\mount-point" -Driver "I:\drivers"
dismount-windowsimage -save -path "I:\mount-point" -erroraction stop

Therefore we don’t force a user of Hanlon to modify their install.wim in anyway but can still provide the ability to install on hardware that may require specific drivers. This also means potentially additional packages or updates could be injected to the image if desired.

Once setup is complete there are a series of callback to Hanlon and finally the WinPE instance reboots.

Auto Unattend

The autounattend.erb is very simple as an unattend.xml usually is. I think there is only a few things to point out. Since we are creating a partition at the end of the disk I need to make sure WillWipeDisk is set to false

<WillWipeDisk>false</WillWipeDisk>

To determine which edition of Windows to install and core vs GUI we use the following option:

<MetaData>
<Key>/IMAGE/INDEX</Key>
<Value><%= wim_index %></Value>
</MetaData>

And finally our last callback we use the RunSynchronousCommand and PowerShell.

<component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Order>1</Order>
                    <Path>powershell -NoLogo -Command "Invoke-WebRequest -Uri  <%= callback_url("postinstall", "final") %> -Method GET -UseBasicParsing"</Path>
                    <Description>Hanlon Postinstall Final</Description>
                </RunSynchronousCommand>
            </RunSynchronous>
      </component>

Conclusion

IMHO we have created a one of a kind, most automated installation mechanism for deploying Windows instances. Without requiring a CIFS and the ability to inject drivers on the fly to the install.wim we have reduced complexity in Windows deployment.

Acknowledgements

Tom McSweeney

Without Tom we certainly not be here today. He did extensive changes to the image slice, model slice, static location and modified the app.rb to support chunking significantly reducing memory requirements. It has been educating experience and I am glad that I got the opportunity to work with him on this project.

Chris Yantha

After struggling with the unattend.xml for hours, a single email to Chris provided us a working example that we could use in the autounattend.erb.

Russell Teague and Aaron Dean

Both Russell and Aaron provided moral support and offloading of tasks to allow us to continue with this initiative.

Older Newer

Virtomation Automation in a virtually contained world...

Using Ansible's WinRM configuration script with vSphere

Method #1 - Guest Customization

Method #2 - VMware Tools

Sources

Where ESXi belongs - Nested under KVM

First up, Nested ESXi

QEMU Changes

Patch and compile QEMU

Create the ESXi virtual machine

Sources

Hanlon now supports Windows provisioning!

Design Details

WinPE Image

Image Details

Drivers

Build Process

Execution of build-winpe.ps1

Video Demo of Build Process

Hanlon Discover

Windows Install

Auto Unattend

Conclusion

Acknowledgements