1.2.5 No longer builds Windows 2019 & 2022

[StephenSo]

Overview of the Issue

Packer build for a given Windows server build no longer works, with the OS install ISO and VMWare tools ISOs getting swapped.
Version 1.2.4 and older:
D: = Windows Install media ISO
E: = VMware Tools ISO

Version 1.2.5:
D: = VMware Tools ISO
E: = Windows Install media ISO

Reproduction Steps

Works as per previous version: KO Packer build where

packer {
  required_plugins {
    ansible = {
      version = ">= 1.1.1"
      source  = "github.com/hashicorp/ansible"
    }
    vsphere = { # added due to https://www.hashicorp.com/blog/announcing-the-removal-of-bundled-plugins-in-hashicorp-packer
      version = "= 1.2.4"
      source  = "github.com/hashicorp/vsphere"
    }
  }
}

Change to 1.2.5 - Build will timeout waiting for VMTools to install

packer {
  required_plugins {
    ansible = {
      version = ">= 1.1.1"
      source  = "github.com/hashicorp/ansible"
    }
    vsphere = { # added due to https://www.hashicorp.com/blog/announcing-the-removal-of-bundled-plugins-in-hashicorp-packer
      version >= "= 1.2.5"
      source  = "github.com/hashicorp/vsphere"
    }
  }
}

Packer Version

1.8.3

Plugin Version and Builders

Please provide the plugin version.

1.2.5

Please select the builder.

• [] vsphere-iso

VMware vSphere Version

Please provide the VMware vSphere version.

vCenter Server 7.0 Update 3o
VMware ESXi 7.0 Update 3g

Guest Operating System

Windows 2022 & 2019

Simplified Packer Buildfile

source "vsphere-iso" "windows2022" {
  // https://github.com/vmware-samples/packer-examples-for-vsphere/blob/main/builds/windows/server/2016/windows-server.pkr.hcl
....
  storage {
      disk_size       = var.windows2022_vm_disk_sizeMB
      disk_controller_index = 0      
      disk_thin_provisioned = true
  }
  network_adapters {
      network         = var.vcenter_network
      network_card    = "vmxnet3"
  }
  cdrom_type          = var.windows2022_vm_cdrom_type
  remove_cdrom        = true
  reattach_cdroms     = 1

  // vSphere template settings
  convert_to_template = true
  export {
    force = true
    output_directory = var.ovfFile_location
  }
  create_snapshot     = false
  // OS Configuration
  guest_os_type       = "${var.windows2022_vm_guest_os_type}"
  notes               = "Default User: ${var.winrm_username}\nBuilt by Packer @ {{isotime \"2006-01-02 03:04\"}}."

  // Removable Media Settings
  iso_url             = "${var.windows_artifcatory}${var.windows2022_iso}"
  iso_target_path     = "${var.PACKER_CACHE_DIR}/${var.windows2022_iso}"
  iso_checksum        = var.windows2022_checksum
  iso_paths    = ["[] /vmimages/tools-isoimages/${var.windows2022_os_family}.iso"]
  floppy_files = [
    "${var.os_config_root}/${var.windows2022_os_family}/${var.windows2022_scripts_folder}/"
  ]
  floppy_content = {
    "autounattend.xml" = templatefile("${var.os_config_root}/${var.windows2022_os_family}/${var.windows2022_scripts_folder}/${var.windows2022_vm_firmware}_autounattend.pkrtpl.hcl", {
      vm_guest_os_language = var.windows2022_vm_guest_os_language
      vm_guest_os_keyboard = var.windows2022_vm_guest_os_keyboard
      vm_guest_os_timezone = var.windows2022_vm_guest_os_timezone
    })
  }

  // Boot and Provisioning Settings
  // http_port_min    = var.common_http_port_min
  // http_port_max    = var.common_http_port_max
  boot_order       = var.windows2022_vm_boot_order
  boot_wait        = var.windows2022_vm_boot_wait
  boot_command     = var.windows2022_vm_boot_command

Set the env var PACKER_LOG=1 for maximum log detail.

[tenthirtyam]

• If reattach_cdroms is excluded in v1.2.5 is it successful?

• If reattach_cdroms is included in v1.2.4 is it successful?

[tenthirtyam]

@Hi-Angel - could you please take a look to see if the refactoring in #355 might have affected this behavior.

cc @nywilken @lbajolet-hashicorp

[Hi-Angel]

@Hi-Angel - could you please take a look to see if the refactoring in #355 might have affected this behavior.

From what I read at the top post, it seems like the order has changed? It indeed sounds like the expected outcome of this commit (referring at PR because all commits were squashed upon merge, so they're only distinguishable there).

I'm not quite clear though, why is that a problem. Unless I'm missing something, the plugin does not document any guarantees about the order in which ISO files will be mounted. The proper course of action on the user's side would be to fetch info after the VM got created about which disk has which ISO, and then work from there. Am I wrong here?

[StephenSo]

• If reattach_cdroms is excluded in v1.2.5 is it successful?
• If reattach_cdroms is included in v1.2.4 is it successful?

I can try this tomorrow, time permitting.

[StephenSo]

@Hi-Angel - could you please take a look to see if the refactoring in #355 might have affected this behavior.

From what I read at the top post, it seems like the order has changed? It indeed sounds like the expected outcome of this commit (referring at PR because all commits were squashed upon merge, so they're only distinguishable there).

I'm not quite clear though, why is that a problem. Unless I'm missing something, the plugin does not document any guarantees about the order in which ISO files will be mounted. The proper course of action on the user's side would be to fetch info after the VM got created about which disk has which ISO, and then work from there. Am I wrong here?

In Packer docs
"If the "iso_url" is defined in addition to the "iso_paths", the "iso_url" is added to the VM first. This keeps the "iso_url" first in the boot order by default allowing the boot iso being defined by the iso_url and the vmware tools iso added from the datastore."

Also, there are references to VMware VM hardware drivers in the Autounattend.xml file that rely on the Vmtools ISO being in "E:"

[Hi-Angel]

@Hi-Angel - could you please take a look to see if the refactoring in #355 might have affected this behavior.

From what I read at the top post, it seems like the order has changed? It indeed sounds like the expected outcome of this commit (referring at PR because all commits were squashed upon merge, so they're only distinguishable there).
I'm not quite clear though, why is that a problem. Unless I'm missing something, the plugin does not document any guarantees about the order in which ISO files will be mounted. The proper course of action on the user's side would be to fetch info after the VM got created about which disk has which ISO, and then work from there. Am I wrong here?

In Packer docs "If the "iso_url" is defined in addition to the "iso_paths", the "iso_url" is added to the VM first. This keeps the "iso_url" first in the boot order by default allowing the boot iso being defined by the iso_url and the vmware tools iso added from the datastore."

Also, there are references to VMware VM hardware drivers in the Autounattend.xml file that rely on the Vmtools ISO being in "E:"

Oh, sorry, then it is my bad for missing the documentation. I'll look at fixing it tomorrow.

[Hi-Angel]

FTR, hoping it's gonna be quick I made a preliminary fix, but for unknown reason the order is still not what I'd expect. Will look at it tomorrow.

[Hi-Angel]

Will look at it tomorrow

Ha, jk. Created a fix: #388