Closed StephenSo closed 8 months ago
If reattach_cdroms
is excluded in v1.2.5 is it successful?
If reattach_cdroms
is included in v1.2.4 is it successful?
@Hi-Angel - could you please take a look to see if the refactoring in https://github.com/hashicorp/packer-plugin-vsphere/pull/355 might have affected this behavior.
cc @nywilken @lbajolet-hashicorp
@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?
- 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.
@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 isourl 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 - 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 isourl 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.
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.
Will look at it tomorrow
Ha, jk. Created a fix: https://github.com/hashicorp/packer-plugin-vsphere/pull/388
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
Change to 1.2.5 - Build will timeout waiting for VMTools to install
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
Set the env var
PACKER_LOG=1
for maximum log detail.