Packer: Different name convention for guest_os_type between packer and VMWare

[luHub]

Overview of the Issue

The name given by documentation from ESXi differs from the name convention used in packer.
"centos7_64Guest" according to VMWare documentation and .ofv OperatingSystemSection tag, additional to that is not only different in the name but also in the usage of underscore (_) and dash (-).

As workaround "centos7-64" was the right choice but more as an effect of guess, try and error.

Reproduction Steps

Use centos7_64Guest as "(guest_os_type)[https://packer.io/docs/builders/virtualbox-iso.html#guest_os_type]"

Packer version

From 1.5.1

Simplified Packer Buildfile

"builders": [
{
"type": "vmware-iso",
"version": "13",
"guest_os_type": "centos7_64Guest"
}
]

Operating system and Environment details

ESXi Server 6.5

Log Fragments and crash.log files

2020-02-07 14:28:33.394 | [1;31m==> vmware-iso: Error starting VM: VMware error: Error: The operation was canceled[0m
2020-02-07 14:28:33.394 | [1;32m==> vmware-iso: Waiting 4.265005182s to give VMware time to clean up...[0m
2020-02-07 14:28:38.674 | [1;32m==> vmware-iso: Deleting output directory...[0m
2020-02-07 14:28:38.674 | [1;31mBuild 'vmware-iso' errored: Error starting VM: VMware error: Error: The operation was canceled[0m

[sylviamoss]

Hey there! Thanks for reaching out. Could you provide the complete logs?

[luHub]

Hi sylviamoss

On Monday I will get the production logs.

[luHub]

Placed in this (gist) the mist complete logs I could get.

Additionally, in relation with this story I found that I am not the only one using workarounds

[jasonberanek]

@luHub I cannot find the specific .ovf reference you mention, but looking at the vSphere API link you sent part of this issue appears to be that the API uses different values for the guest OS enumeration than what's used within the VMX file definitions used by VMware's hypervisor products. If you were to build a VM from scratch with ESXi, Workstation, or Fusion; you would see that the VMX file uses guest OS names similar to the centos7-64 format you mention.

Packer does not use the vSphere API you referenced, which is why the values from that enumeration don't work as expected. All of the VMware ISO builders work by building VMX files and supporting files, then use VMware APIs to start up those VMs. This allows the different vmware targets (ESXi, Workstation, Fusion, Player) to all share the same interface, since the vSphere API itself only works with a licensed ESXi host. The downside is that users have to deal with the fact the VMX format isn't officially documented, or just use the default guest-os type of other.

Based on the above, I don't believe Packer can fix this issue in the code, though some caveats/warnings in the docs would be beneficial for others encountering the same problem you've come across.

[luHub]

Hi Jason

I am using vmware ESXi 6.7.0. I just created this morning a VA from scratch and this is the result after export the .ovf I find in the the OperatingSystemSection tag centos7_64Guest instead of centos7-64.

This are the repro steps that I am using:

1) Login into vmware ESXi

2) Create a VA with the following settings from scratch using the following settings:

• Compatibility: ESXi 6.5
• Guest OS family: Linux
• Guest OS version: CentosOS 7 (64-bit)

3) Export the VA using the settings menu

4) This is the ovf file that I get: settings

In this .ovf file the OS guest version is named as centos7_64Guest

• What are your repro steps?

• Do you need more information? Because for some reason we are getting different results.

  I will try to contact the people from vmware esxi and ask them for a list.

[jasonberanek]

@luHub,

VMware only imports from or exports to the OVF, it does not run or create VMs using that format.
Instead, it uses its internal VMX format, which uses a different naming convention for the guest OS than the OVF standard. OVF's exported from VMware will use the names you saw, but VMware requires the VMX to create/run a VM inside its hypervisor.

To see the value the VMX is using internally, you can download the VMX file for your VM from your ESXi server's data store by following the VMware documentation on how to Edit configuration files here. You should see the .vmx file for the VM you referenced list the guest OS as centos7-64.

[luHub]

@jasonberanek

Yes, you are right I did that, I found that for different versions of ESXi, the os_guest_type might change, for example: ESXi 6.0 uses centos-64 and ESXi 6.5 uses centos7-64 (because it seems that they made the Centos guest os type selection more detailed) . So with this workaround looking into the .ovf file, I don't need to guess anymore and build the right virtual machine using packer.

Still, I think that the message "Error starting VM: VMware error: Error: The operation was canceled" is not very intuitive. Because I am new in this community, I would like to know how to proceed if I would like a more intuitive error message, and also a warning in the documentation as you suggested about this to prevent future packer users to run into this issue might be very useful.

[jasonberanek]

@luHub

If Packer can provide a better error message, I think it should; along with the documentation update. I'm in process of getting an ESXi instance up to run some tests, and I'll take a look to see if it is at least possible to detect the specific error.

I'll defer to primary contributors on how to characterize the issue for now, I'm just getting my bearings again on the community process after being away for a while.

[jasonberanek]

@luHub

I setup an ESXi 6.7 VM to run some tests using an Ubuntu template and the more recent 1.5.2 Packer build. That setup showed different results than yours, with ESXi treating the invalid name as a guest of type "other". I haven't tried to setup another ESXi host to verify yet, however looking at similar errors caused when having an invalid guest OS name against VMware fusion, I don't think Packer will have enough feedback to say why the build is failing. Effectively, the VMware command to start the VM is failing, and that's what Packer is responding to (e.g., Error starting VM). It only outputs whatever errors come from the VM command on exit, so if VMware's tool doesn't provide detailed feedback Packer just knows that process exited in an unclean manner or some error occurred.

[luHub]

@jasonberanek Then it seems that the best at this point is to have at least a warning in the documentation, do you agree on this? Do you know how we could update the documentation?

[jasonberanek]

@luHub The Packer website source is part of the repo under the website directory. I can make the change, or if you'd like to try your hand at making a pull request I can let you make the suggestion. The file I believe we'd need to update is here.

From there, I'd defer to a primary contributor like @sylviamoss on when the update would be pushed to the website, as I'm not up to date on those workflows.

For the update itself, here is my draft thoughts (new items in bold):

• guest_os_type (string) - The guest OS type being installed. This will be
  set in the VMware VMX. By default this is other. By specifying a more
  specific OS type, VMware may perform some optimizations or virtual hardware
  changes to better support the operating system running in the
  virtual machine. Valid values differ by platform and version numbers, and may
  not match other VMware API's representations of guest OS names. Consult your
  platform for valid values.

Does that seem reasonable?

[sylviamoss]

Nice discussion here! Thanks for digging into this @jasonberanek and @luHub!
Both of you can open a PR to update the documentation whenever you find it necessary. Feel free to do it!

Also, I like @jasonberanek draft for the update. 👍

[luHub]

I am very happy that we could close this. Thanks @jasonberanek for making the necessary changes. Looking forward for next adventures :+1:

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.