VMware Cloud Community
csati
Contributor
Contributor

VM customization does not work until booted once

Hello,

We're running VMware ESXi, 6.7.0, 13006603 with vCenter 6.7.0 Build13639324 with SLES 15 SP1 guests. Our guests have open-vm-tools pre-installed.

I've tried at least two ways to customize Guest OS,

1., Deploy OVF template from Content Library and check 'Customize the operating system' tickbox and select the customization,

2., Simply import OVF (without Content Library) and after that customize it by right click, Guest OS, Customize Guest OS.

I get various errors mentioning that customization is not supported, such as:

Customization of the guest operating system 'sles15_64Guest' is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.

I have noticed that in "Summary" tab, it says VMware Tools: Not running, not installed.

Once the guest is powered on and boot procedure progresses until open-vm-tools is started, vSphere recognizes existence of open-vm-tools. However, customization is not possible when the VM is already powered on. With this at hand, the first startup is destined to fail without network addresses. After that, when VM is powered off, customization can be applied and in subsequent boot, everything works "like it should".

I have two questions:

1., Is there a way to circumvent this "first boot" and convince vSphere that open-vm-tools is available in the guest and apply customization already before the first boot? Can this information somehow be imported along with the OVF?

2., If there is a VApp of multiple VMs, is it expected that user has to select and apply VM customization templates individually to those VMs or can those be assigned when the VApp is deployed?

Thank you for your answers!

0 Kudos
1 Reply
csati
Contributor
Contributor

A potential solution, for at least question #1 seems to be to start vmtoolsd during the image creation process, which happens outside VMware in our case.

0 Kudos