error removing cdrom prior to reattaching: invalid number: n must be between 0 and 0 about packer-plugin-vsphere HOT 8 CLOSED

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.

from packer-plugin-vsphere.

@Hi-Angel to triage.

from packer-plugin-vsphere.

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.

from packer-plugin-vsphere.

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:

1. Get the actual number of CDroms from the API
2. In step_reattach_cdrom.go take into account remove_cdrom
3. In 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).

from packer-plugin-vsphere.

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.

from packer-plugin-vsphere.

@StephenSo thank you for finding the bug! Its fix is being reviewed at #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 😊

from packer-plugin-vsphere.

from packer-plugin-vsphere.

Thanks @Hi-Angel, I will remove the use of remove_cdrom from my code. I will test and revert if it breaks the build.

from packer-plugin-vsphere.