Added Hyper-V support for Server 2008 R2 to 2016

[jborean93]

Added support for building an image on Hyper-V for all hosts except Server 2008. Server 2008 R2 is pending a merge and release of hashicorp/packer#6219 in Packer.

Total changes in this PR;

• Specify the VM builder with opt_packer_setup_builder with either hyperv or virtualbox (default)
• Revamped bootstrapping process, all files are pre-downloaded and attached as an ISO. This means the host no longer needs internet access in this step and saves time/bandwidth when running multiple times
• The above adds a dependency on mkisofs but I feel this is a simple tradeoff
• Tried to make the bootstrapping process a bit more config driven, it is a lot easier to add/remove updates to install in this process now the steps are driven by vars/main.yml

Fixes: #7

[sbarthelemy]

Added support for building an image on Hyper-V

in this case, do you need to run packer-windoze (ie. ansible then packer) from a Windows host?
Do you install mkisofs on the Windows host?

Revamped bootstrapping process, all files are pre-downloaded and attached as an ISO. This means the host no longer needs internet access in this step and saves time/bandwidth when running multiple times

in the same spirit, what about not using ansible at all in packer's provisioning step? I suspect it would make the support of more packer builders (say, vmware or vsphere) transparent: communicating with the temporary instance would be left to packer, packer-windoze wouldn't have anymore to find out how packer communicates with the instance and pass it over to ansible.

(sorry for the noob questions!)

[jborean93]

in this case, do you need to run packer-windoze (ie. ansible then packer) from a Windows host?
Do you install mkisofs on the Windows host?

You still need to run ansible packer-setup to create all the initial files that Packer requires. The whole setup process is all run in WSL so everything, including mkisofs is run there. Once things are set up, the Packer is run from the Windows side and not WSL. I need to redo the docs a bit but you can run the whole process like so;

bash.exe -ic "ansible-playbook packer-setup.yml -e man_packer_setup_host_type=2016"
packer.exe build -force 2016\packer.json

in the same spirit, what about not using ansible at all in packer's provisioning step? I suspect it would make the support of more packer builders (say, vmware or vsphere) transparent: communicating with the temporary instance would be left to packer, packer-windoze wouldn't have anymore to find out how packer communicates with the instance and pass it over to ansible.

Mostly it's just how I've set things up so far, there's no reason why you can't just run all this in PowerShell but I see the following as benefits for keeping Ansible in this phase;

• The provisioning steps call some complex APIs like WUA and Scheduled Tasks that Ansible abstracts away, doing it in pure PowerShell is definitely possible
• The biggest reason would be with handling reboots, in cases (like updating) we loop through code and reboot multiple times depending on the outcome. Doing this as a pure Packer provisioner would be hell as we would need to exit the currently executing script and call the reboot step in Packer

The fact that we need to connect to the host outside Packer is painful but until it actually works properly over Windows with the Ansible provisioner, there's not much I can do about it.

Arguably the biggest part Ansible plays in this process is the packer-setup.yml playbook that set's everything up for Packer to run. This is a key step and will probably always require Ansible, because of this I don't see the requirement for Ansible during the build process being removed anytime soon as it wouldn't remove the dependency on Ansible.

(sorry for the noob questions!)

No need to be sorry, asking questions is healthy and helps us learn more about how things work.

[zoredache]

I have done some testing on this. Everything mostly looked good for 2016/2012R2 builds. Haven't tested others yet.

I had a couple problems.

The configure-hyperv-network.ps1 seems to be confused about what the working directory is when it runs. When packer launches it on my system it seemed to get launched with $Env:USERPROFILE as my working directory instead of the directory I had packer-windoze. I adjusted the template like this, and it seemed to be fine on my system.

diff --git a/roles/packer-setup/templates/configure-hyperv-network.ps1.j2 b/roles/packer-setup/templates/configure-hyperv-network.ps1.j2
index 038e441..0171d08 100644
--- a/roles/packer-setup/templates/configure-hyperv-network.ps1.j2
+++ b/roles/packer-setup/templates/configure-hyperv-network.ps1.j2
@@ -30,6 +30,8 @@ Function Get-VMIPAddress($vm_name) {
    return $ip
}

+Set-Location "$PSScriptRoot\..\"
+
$inventory_file = '{{man_packer_setup_host_type}}\hosts.ini'
$vm_name = '{{pri_packer_setup_builders.vm_name}}'

It would be good to have the hyperv switch name be configurable. Perhaps something like this?

diff --git a/roles/packer-setup/vars/main.yml b/roles/packer-setup/vars/main.yml
index 1089221..e3bfed1 100644
--- a/roles/packer-setup/vars/main.yml
+++ b/roles/packer-setup/vars/main.yml
@@ -120,7 +120,7 @@ pri_packer_setup_builders_info:
    ram_size: 2048
    secondary_iso_images:
    - '{{man_packer_setup_host_type}}/secondary.iso'
-    switch_name: packer-windoze
+    switch_name: "{{opt_hyperv_switchname | default('packer-windoze')}}"

pri_packer_setup_provisioners_info:
common: []

[jborean93]

Thanks for the info @zoredache, I’ll add your changes to the next commit. If you do end up trying 2008 R2, Packer by itself won’t work. You’ll need to use the changes in the PR hashicorp/packer#6219 so Packer can find the actual IP address. Sadly 2008 (non R2) won’t work at all.

[stefaz]

Hi,
regarding the configure-hyperv-network.ps1 script I also encountered an error running the Hyper-V packer build on a Win10 RS4 host.

==> hyperv-iso: Connected to WinRM! ==> hyperv-iso: Executing local command: 10-x64/configure-hyperv-network.ps1 hyperv-iso: Exception calling "GetSteppablePipeline" with "1" argument(s): "The expression after '&' in a pipeline element produced an object that was not hyperv-iso: valid. It must result in a command name, a script block, or a CommandInfo object." hyperv-iso: At C:\Program Files\WindowsPowerShell\Modules\PSLog\5.0.2.0\PSLog.psm1:557 char:13 hyperv-iso: + $steppablePipeline = $scriptCmd.GetSteppablePipeline($MyI ... hyperv-iso: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ hyperv-iso: + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException hyperv-iso: + FullyQualifiedErrorId : RuntimeException hyperv-iso: ==> hyperv-iso: Clean up secondary dvd drives...

Seems to be related with calling the script through powershell.exe because directly calling the script in a PS session works fine.
Replacing the Write-Host commandlets in the script with Write-Output solves this issue, which goes along with the Best Practice of trying to avoid Write-Host whenever possible.

[jborean93]

Thanks for the feedback @stefaz, I've just removed the host calls altogether, you will easily see if something goes wrong or what IP was chosen when the Ansible step runs next.

I'm also going to see if the IP Address is available as a variable, I keep on seeing references in some provisioners but need to try it out and see what is possible.

[jborean93]

Thanks everyone for testing and feedback, I'm happy so far with the changes and have started creating the Hyper-V boxes for v0.3.0. Server 2008 R2 to 2016 should be all up and available within the next few hours.