Closed StephenSo closed 3 months ago
@Hi-Angel to triage.
Oh, I see, thank you. I'll have to dig into it, so I'll probably take a look into it tomorrow or on Friday at worst.
Took a quick look into it. It's a funny bug: the reason the problem happens is because in step_reattach_cdrom.go
we expect the number of cdroms to be equal to s.CDRomConfig.ISOPaths
. However, it does not take into account the existence of remove_cdrom = true
HCL option which would remove remove cdroms, thus making this assumption invalid.
Possible solutions I see:
step_reattach_cdrom.go
take into account remove_cdrom
remove_cdrom
processing take into account reattach_cdroms
1
seems like the best one, except Idk offhand what API should I use and wouldn't it make request over the network (which isn't good).
2
I tried and there does not seem to be access to remove_cdrom
value in step_reattach_cdrom.go
file.
3
I didn't try yet, but I presume the problem would be similar to 2
(i.e. having to access to reattach_cdroms
in wherever the remove_cdrom
is processed).
Okay, got a fix locally by adding a function enlisting cdrom devices, which is the best way to handle that I think. But it doesn't quite work + I guess I need to add tests for that case as well, so it will take some more time.
@StephenSo thank you for finding the bug! Its fix is being reviewed at https://github.com/hashicorp/packer-plugin-vsphere/pull/394
That said, I just wanted to mention that you can make it work without waiting for the fix to get merged by removing the remove_cdrom
line from the config. I don't see the point of removing the cdroms if you want them immediately to be readded. Reattached cdroms should have no flies attached to them in case that's what you were afraid of. As it stands, the option is just excess code for you to read and for your server to execute π
Thanks for the update. During the build there's 2 cdroms in use (1 for the OS and the other for VM tools), where only 1 is required in the VM template. In the docs, maybe I misunderstood the process. Remove cdroms and then keep only 1 for final config. So the correct process is to not remove cdroms and just use reattach_cdroms? It is confusing. Perhaps the variable should simply be retain_cdroms = # (to specify how many to be left in the template) ?
On Fri, 22 Mar 2024, 12:27 Konstantin K, @.***> wrote:
@StephenSo https://github.com/StephenSo thank you for finding the bug! Its fix is being reviewed at #394 https://github.com/hashicorp/packer-plugin-vsphere/pull/394
That said, I just wanted to mention that you can make it work without waiting for the fix to get merged by removing the remove_cdrom line from the config. I don't see the point of removing the cdroms if you want them immediately to be readded. Reattached cdroms should have no flies attached to them in case that's what you were afraid of. As it stands, the option is just excess code for you to read and for your server to execute π
β Reply to this email directly, view it on GitHub https://github.com/hashicorp/packer-plugin-vsphere/issues/393#issuecomment-2014972022, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIKYKZPJUN2HH35CWFAYZTYZQPUFAVCNFSM6AAAAABE7GC42SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJUHE3TEMBSGI . You are receiving this because you were mentioned.Message ID: @.***>
Thanks for the update. During the build there's 2 cdroms in use (1 for the OS and the other for VM tools), where only 1 is required in the VM template. In the docs, maybe I misunderstood the process. Remove cdroms and then keep only 1 for final config. So the correct process is to not remove cdroms and just use reattach_cdroms? It is confusing.
Well, I do not seem to see at all reattach_cdrom
being documented on the hashicorp site. I think they haven't uploaded the docs last few releases. For now there's documentation in the repo and it says, quoting:
When set to a value in the range (
1..4
, remark is mine),remove_cdrom
is ignored and the CD-ROM devices are kept without any attached media.
So the interaction with remove_cdrom
is documented and it says the option is just ignored (although in the code it actually isn't, which resulted in this bug, but as far as a user concerned there's no visible difference in the option behavior when reattach_cdrom
is set as well).
Perhaps the variable should simply be retain_cdroms = # (to specify how many to be left in the template) ?
I think retain
would be misleading, because it implies that some amount of cdroms would see no changes. Which is not true, because the code does some change: specifically, it deattaches ISO files from them.
Thanks @Hi-Angel, I will remove the use of remove_cdrom
from my code. I will test and revert if it breaks the build.
Overview of the Issue
Packer build for a given Windows server build no longer works. I believe the 1.2.5 refactoring release created this issue, it only became apparent once #386 was corrected. Now the build finishes, with the error
Version 1.2.4 and older: D: = Windows Install media ISO E: = VMware Tools ISO
Version 1.2.6: D: = VMware Tools ISO E: = Windows Install media ISO
Reproduction Steps
Works as per previous version: KO Packer build where
Change to 1.2.6 - Build will timeout waiting for VMTools to install
Packer Version
1.8.3
Plugin Version and Builders
Please provide the plugin version.
1.2.6
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.