Check if you have run the migration assistant from the VCSA ISO.

Hi guys,

I'm fairly experienced doing scripted installs of esxi dating back to esxi 4.1. With the latest release (6.5.x) however I'm getting some issues.

The issue is: my ipv4 address for the management is not being set and therefore the host is not usable after the installation.

Here is what I do to install:

vmaccepteula 
rootpw --iscrypted here_is_my_password

# Install parameters 
#Local Storage, HP Raid Controller Driver 
install --firstdisk=hpsa,local --overwritevmfs  

network --bootproto=static --device=vmnic0 --ip=192.168.10.100 --netmask=255.255.255.0 --gateway=192.168.10.1 --nameserver=192.168.10.1 --hostname=ESXi6.virtualfrog.lab --vlanid=00 --addvmportgroup=0 

reboot --noeject

This however results in my ipv4 configuration to be set to "disabled". It does not matter if I try this on a nested esxi on my VMware Fusion or if I use a HPE Bladeserver.

I have a workaround by setting the ip again during the %firstboot part of my kickstart script, but I wonder if you guys are having trouble with the 6.5 kickstart install as well or if I missed some change in 6.5 regarding kickstart installation.

thank you.

Edit: Here is the link to the documentation center regarding this approach for 6.5. As far as I can see I follow the procedure accordingly: VMware vSphere 6.5 Documentation Library

It seems the vmware tools in your dell custom image are corrupt.

Did you know that you can download the vmware tools, put them on a shared datastore and point all the hosts' locker configuration to that datastore? It gives you control over which vmware tools version is determined to be "up to date" and you can be sure that the downloaded vmware tools are not corrupt by doing the md5 checksum. if you're interested in how to achieve this let me know (or ask google^^)

In regards to your windows 2012 terminal server. I had similar issues in the past and my only solution was to remove vmware tools completely (reboot) and then reinstall them.

The only way for you to get back into evaluation mode is by doing a reinstall of your esxi hypervisors. This way you will have the 60 day evaluation mode again with all the features unlocked.

installing VCSA 6.5, I Cant to connect for stage 2 this is the message "the installer is unable to connect the vcenter server appliance management interface vcsa 6.5" I don´t have to access for IP but DNS is ok.

The 6.5d target VCSA instance fails to start vAPI service at 66% of stage 2, step 2 in installer.exe wizard from the VCSA .ISO at firstboot and my upgrade fails.  Our topology is 2x 6.0u2 external PSCs at different sites in enhanced link mode that are working fine in the environment and appear service healthy and no less than 20% free space on any internal partition.  The exact error from the wizard is:

--------------------

An error occurred while starting service 'vapi-endpoint'

Failed to start the vAPI Endpoint Service

Failed to configure vAPI Endpoint Service at the firstboot time

Resolution

Please file a bug against VAPI

--------------------

It doesn't look like a network problem since the wizard gets through the network verification settings and I've verified that the machine running installer.exe has functional DNS to everything involved, but just to confirm, I've tried:

- using an ephemeral port group instance of our management VLAN on the distributed switch, as installer.exe requests (but not a standard switch yet)

- using straight IP addresses instead of FQDN because I've had other VMware products cause this grief before during setup

- entirely disabling the Windows firewall

- running the installer as a domain admin of the domain our PSC is configured to talk to over LDAP as an identity source (it is not joined to the domain, however)

I opened a support case with VMware a week ago / last Wednesday, but they have been very slow to give in and ask for logs to escalate up to engineering.  PLEASE, has anyone else had this issue and what helped get you through the PSC upgrade?

Support told me to look at this, but we don't have any GPO under software restrictions at all so it does not seem relevant:

Windows vCenter Server 6.5 installation fails while configuring the vAPI EndPoint Service

Does anyone know if the installer.exe invokes Java from an internal bundle or if Java must be installed in Windows as a prerequisite?

Thanks for any ideas... at all.

Alex,

Did you ever find a solution to your issue? I am seeing the exact same situation that you describe.  Autodeploy on 6.5 host w/ distributed switch fails and no gateway is entered. 

The VCSA upgrade fails...

I receive the following error message in the session logs:

2017-06-17 18:10:14.835389 CIP Service: [VCSA INFO] fetch File form VM - result:{"type":"result","statusCode":"OK","sessionId":"nwDX-cxUM-Lvpf-sCWH","requestId":"715","requestComponentId":"fileTransfer","requestObjectId":"8088-jT99-8gEX-Xsia","result":"{\n    \"status\": \"error\", \n    \"info\": [], \n    \"question\": null, \n    \"progress_message\": {\n        \"args\": [\n            \"VMware License Service\"\n        ], \n        \"id\": \"ur.upgrade.script.export.progress.text\", \n        \"localized\": \"Exporting VMware License Service data...\", \n        \"translatable\": \"Exporting %(0)s data...\"\n    }, \n    \"warning\": [], \n    \"error\": {\n        \"resolution\": {\n            \"id\": \"ur.upgrade.script.internal.resolution\", \n            \"localized\": \"Send upgrade logs files to GSS for further assistance.\", \n            \"translatable\": \"Send upgrade logs files to GSS for further assistance.\"\n        }, \n        \"detail\": [\n            {\n                \"args\": [\n                    \"Export\", \n                    \"VMware License Service\"\n                ], \n                \"id\": \"ur.upgrade.script.internal.text\", \n                \"localized\": \"Internal error occurs during Export of VMware License Service.\", \n                \"translatable\": \"Internal error occurs during %(0)s of %(1)s.\"\n            }, \n            {\n                \"args\": [\n                    \"Export\", \n                    \"VMware License Service\"\n                ], \n                \"id\": \"ur.upgrade.script.internal.text\", \n                \"localized\": \"Internal error occurs during Export of VMware License Service.\", \n                \"translatable\": \"Internal error occurs during %(0)s of %(1)s.\"\n            }\n        ], \n        \"componentKey\": \"upgrade_framework\", \n        \"problemId\": null\n    }, \n    \"progress\": 34\n}","isFinal":"true"}

I've been unsuccessful at finding any relevant KB articles and am hoping that someone here has run into this issue before

Looking at the export-upgrade-runner.log from the 5.5 VCSA showed me this:

2017-06-17T22:10:02.83Z INFO upgrade.states.component_states license:Export: 2017-06-17T22:10:01.271Z INFO license License export started ...

2017-06-17T22:10:02.83Z INFO upgrade.states.component_states license:Export: 2017-06-17T22:10:01.271Z INFO license Start exporting management license data...

2017-06-17T22:10:02.83Z INFO upgrade.states.component_states license:Export: 2017-06-17T22:10:01.271Z INFO license Extracting data...

2017-06-17T22:10:02.83Z INFO upgrade.states.component_states license:Export: 2017-06-17T22:10:01.271Z ERROR __main__ Upgrade Phase 'license:Export' failed. Exception: RSA key format is not supported

2017-06-17T22:10:02.83Z INFO upgrade.states.component_states license:Export: Traceback (most recent call last):

2017-06-17T22:10:02.84Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/componentPhaseLauncher.py", line 379, in main

2017-06-17T22:10:02.84Z INFO upgrade.states.component_states license:Export:     executionResult = systemExtension(exeContext)

2017-06-17T22:10:02.84Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/libs/sdk/extensions.py", line 94, in __call__

2017-06-17T22:10:02.84Z INFO upgrade.states.component_states license:Export:     result = self.extension(*args)

2017-06-17T22:10:02.85Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/libs/sdk/extensions.py", line 110, in _func

2017-06-17T22:10:02.85Z INFO upgrade.states.component_states license:Export:     return func(*args)

2017-06-17T22:10:02.85Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/__init__.py", line 110, in exportData

2017-06-17T22:10:02.85Z INFO upgrade.states.component_states license:Export:     licenseDataExporter.exportData()

2017-06-17T22:10:02.85Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/python/ls_export/license_data_exporter.py", line 60, in exportData

2017-06-17T22:10:02.86Z INFO upgrade.states.component_states license:Export:     managementData = self._exportManagementLicenseData()

2017-06-17T22:10:02.86Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/python/ls_export/license_data_exporter.py", line 76, in _exportManagementLicenseData

2017-06-17T22:10:02.86Z INFO upgrade.states.component_states license:Export:     managementData = managementDataProvider.getData()

2017-06-17T22:10:02.86Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/python/ls_export/management/management_data_provider.py", line 31, in getData

2017-06-17T22:10:02.86Z INFO upgrade.states.component_states license:Export:     vpxdInstanceConfig = VpxdInstanceConfig(self.log, config_dir)

2017-06-17T22:10:02.87Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/python/ls_export/management/vpxd_instance_config.py", line 60, in __init__

2017-06-17T22:10:02.87Z INFO upgrade.states.component_states license:Export:     self._LoadConfigurations()

2017-06-17T22:10:02.87Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/python/ls_export/management/vpxd_instance_config.py", line 187, in _LoadConfigurations

2017-06-17T22:10:02.87Z INFO upgrade.states.component_states license:Export:     self.userPassword = self.DecodePassword(self.userPassword)

2017-06-17T22:10:02.88Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/python/ls_export/management/vpxd_instance_config.py", line 77, in DecodePassword

2017-06-17T22:10:02.88Z INFO upgrade.states.component_states license:Export:     self.privateKey = RSA.importKey(open(privateKeyFile, 'r').read())

2017-06-17T22:10:02.88Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/lib/Crypto/PublicKey/RSA.py", line 247, in importKey

2017-06-17T22:10:02.88Z INFO upgrade.states.component_states license:Export:     return self._importKeyDER(der)

2017-06-17T22:10:02.88Z INFO upgrade.states.component_states license:Export:   File "/tmp/vmware-root/tmpvmware186/payload/component-scripts/license/upgrade_lib/lib/Crypto/PublicKey/RSA.py", line 234, in _importKeyDER

2017-06-17T22:10:02.89Z INFO upgrade.states.component_states license:Export:     raise ValueError("RSA key format is not supported")

2017-06-17T22:10:02.89Z INFO upgrade.states.component_states license:Export: ValueError: RSA key format is not supported

2017-06-17T22:10:02.89Z INFO upgrade.states.component_states license:Export: Script completed for 2.0601439476 secs with return-code='1', and executionId=3c4f7042-8cb5-440d-86d1-81bff0d36818

2017-06-17T22:10:02.93Z ERROR upgrade.states.component_states license:Export: Remote script failed with an error [InternalError()]

2017-06-17T22:10:02.93Z ERROR upgrade.states.component_states license:Export: failed with internal error. For details take a look at Export_com.vmware.license_2017_06_17_22_09.log.

I guess I could regenerate the self-signed certificates that the VCSA to see if that helps.

Error stuff in upgrade-source-requirements.log (vm-support.tgz)

2017-06-18T17:58:08.328Z ERROR apply_networking Failed to get source system network configuration stdout: , stderr: /opt/vmware/share/vami/vami_get_network: error while loading shared libraries: libvami-common.so: cannot open shared object file: No such file or directory

, exit-code: 127.

2017-06-18T17:58:08.328Z ERROR __main__ Fatal error during upgrade collect requirements.

Traceback (most recent call last):

  File "/tmp/vmware-root/tmpvmware206/bootstrap_scripts/run_linux_preupgrade_checks.py", line 1736, in main

    deploymentType, applianceVersion)

  File "/tmp/vmware-root/tmpvmware206/bootstrap_scripts/run_linux_preupgrade_checks.py", line 1391, in _addAppliancePnid

    mismatches)

  File "/tmp/vmware-root/tmpvmware206/bootstrap_scripts/run_linux_preupgrade_checks.py", line 1334, in _pickAppliance60Fqdn

    _validatePnidDnsResolvable(legacyPnid, mismatches)

  File "/tmp/vmware-root/tmpvmware206/bootstrap_scripts/run_linux_preupgrade_checks.py", line 1001, in _validatePnidDnsResolvable

    nwConfig = vamiGetNetwork(processManager=LocalOperationsManager())

  File "/tmp/vmware-root/tmpvmware206/bootstrap_scripts/apply_networking.py", line 144, in vamiGetNetwork

    output = _execNetworkConfigCommand(processManager, [VAMI_GET_NETWORK_CMD, interface])

  File "/tmp/vmware-root/tmpvmware206/bootstrap_scripts/apply_networking.py", line 72, in _execNetworkConfigCommand

    raise NetworkConfigError(error)

NetworkConfigError: Failed to get source system network configuration stdout: , stderr: /opt/vmware/share/vami/vami_get_network: error while loading shared libraries: libvami-common.so: cannot open shared object file: No such file or directory

, exit-code: 127.

2017-06-18T17:58:08.334Z INFO root Exiting with exit-code 1

For the above error, the workaround helps!

Thanks PuliSukumar.

Hi folks:

I'm not sure if this is the right place to put this question or not, but I've been using William Lam's maclearn vib for a couple of years now because I have a VM that runs OpenVPN in bridge mode, and that needs promiscuous mode.  As with the nested ESXi situation that he wrote maclearn to address, this causes excessive CPU usage on that VM if there is lots of traffic on the virtual switch.  Because of that when I did updates I had to use "software profile update" instead of "software profile install" so that the maclearn vib didn't get removed. 

I was going through the dry-run of updating to 6.5d and it failed with a dependency check:

[root@naplesesxi:~] esxcli software profile update --dry-run --depot=/vmfs/volumes/539b4dcd-0d43b62e-2a98-e840f2d1736d/Upgrades/ESXi650-201704001

.zip --profile=ESXi-6.5.0-20170404001-standard

[DependencyError]

File path of '/usr/lib/vmware/vmkmod/dvfilter-maclearn' is claimed by multiple non-overlay VIBs: {'VMware_bootbank_vmware-esx-dvfilter-maclearn_1.00-1.00', 'VMware_bootbank_esx-dvfilter-maclearn_6.5.0-0.0.4282379'}

File path of '/usr/libexec/jumpstart/plugins/dvfilter-maclearn.json' is claimed by multiple non-overlay VIBs: {'VMware_bootbank_vmware-esx-dvfilter-maclearn_1.00-1.00', 'VMware_bootbank_esx-dvfilter-maclearn_6.5.0-0.0.4282379'}

Please refer to the log file for more details.

I had read something about a new fling being available that added a better version of maclearn, but it required a Distributed Virtual Switch, and as I only have the essentials package, I didn't have the ability to create a Distributed Virtual Switch, so I was intending to just stay with what I had.  I had not read or heard that the original version of maclearn was going to actually become a standard part of ESXi, but if I am reading the error message correctly, I believe it's trying to tell me that it is.  If I do the command as "install" instead of update, it says that my version will be removed, along with some other ones that I'll need to research:

[root@naplesesxi:~] esxcli software profile install --dry-run --depot=/vmfs/volumes/539b4dcd-0d43b62e-2a98-e840f2d1736d/Upgrades/ESXi650-20170400

1.zip --profile=ESXi-6.5.0-20170404001-standard

[Exception]

You attempted to install an image profile which would have resulted in the removal of VIBs ['VFrontDe_bootbank_sata-xahci_1.10-1', 'VMware_bootbank_vmware-esx-dvfilter-maclearn_1.00-1.00', 'VMware_bootbank_lsu-lsi-mptsas-plugin_1.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_esx-dvfilter-maclearn_6.5.0-0.0.4282379']. If this is not what you intended, you may use the esxcli software profile update command to preserve the VIBs above. If this is what you intended, please use the --ok-to-remove option to explicitly allow the removal.

Please refer to the log file for more details.

[root@naplesesxi:~]

The release notes didn't mention anything about maclearn, but it looks like it's here.  I guess my best bet would be to remove Lam's original vib first, assuming that this new vib is really the old maclearn version that works on systems without a Distributed Virtual Switch, and then apply the update in "update" mode so that I don't remove the others. 

I guess what I'm looking for feedback on is whether or not that VMware_bootbank_esx-dvfilter-maclearn_6.5.0-0.0.4282379 really is a plug replacement for the original maclearn vib.

Comments welcome.

Thank you! That helps me a lot

Hi Guys,

I found that c:\program files\vmware\vcenter server\openSSL dir not updated by vcenter installer

Ive stop all vmware services, run vmware-openssl.msi from the packages - after it I got new openssl libraries in c:\program files\vmware\CIS\openssl (instead of c:\program files\vmware\vcenter server\openSSL)

then ive copied contents to c:\program files\vmware\vcenter server\openSSL - to which folder rhttpoxy config pointers as library path - and rhttpproxy service started successfully

I did it just to try but then reverted vcenter server back to my current version as worried to apply this as workaround into production but its definitely seems vcenter installer didn't update

c:\program files\vmware\vcenter server\openSSL folder contents and rhttpoxy failed to load and dumps

may be later I will try to apply this and upgrade my prod vcenter after some investigation

We were in the process of upgrading our ESXi 5.1 to 5.5 U3 and before we were upgrading the firmware on our IBM System x3650 M4 servers using the IBM BOMC. Doing so, it upgraded the RAID controller firmware to version 23.31.0-0023.

After the upgrade, the host booted but the local datastore didn't mount and gave an error when trying to mount it. We were also unable to delete it. The RAID configuration showed no errors. It was a RAID1 composed of 2 HDD and 1 Hot Spare. Easy enough right.

We contacted VMware and they suspected something was wrong with the storage on this server. Everything was working fine before we upgraded the firmwares.

VMware recommended we rebuilt the RAID configuration and try to do a clean install of ESXi 5.5 U3 using the Lenovo custom image.. It fails.

I even tried to install 6.0 U2 using the Lenovo custom image.

The DSA, IMM2 and UEFI versions running are shown below.

This is the first time this has ever happened to us and we are at lost and praying for ideas.

Anyone's help would be welcomed.

Hello.

If you have a Windows-based Syslog server and want that syslog directory being created with the host name instead of IP-address  you must do this:

1. Go to Advanced settings and clear Syslog.global.logHost option.

2. Then go to Configuration-->DNS and Routing-->Host Identification-->Domain and type you domain name here.

3. Then repeat actions from this kb: Configuring syslog on ESXi (2003322) | VMware KB

I thought I'd give my two cents here as well. I have had a customer with the same problem and we just wrote a small script that created links to the ip address folders and the link itself is the hostname. kind of like the symbolic link you have on linux or esxi (/vmfs/volumes/).

If anyone is interested in this approach I'm sure I can find the script somewhere in our archive.

I just wanted to contribute here that I've had issues with lower/uppercase characters in the past as well (see: Custom HPE ESXi 6.0 U2 (April 2016) breaks PXEboot with Kickstart Approach )

I think it would be great if the esxi isos were coded with Rock Ridge/Joliet to make this easier in the future.

Thanks for the feedback!  I agree, and I have filed a bug report to request that we add Rock Ridge/Joliet to the images.  (I'd hoped it would have been as simple as adding a command-line option or two to mkisofs/genisoimage here, but it doesn't seem that straightforward to fix, sadly.  We'll see.)

Cheers,

--

Darius

Needing to upgrade a Vcenter 5.5 (installed on Windows Server) to 6.5.  I would like to just upgrade the Vcenter in place.  That part seems easy.  This also has VMware View tied to it.  Will this break?  I have several 5.5 hosts that we are also migrating away from.  I 3 new hosts with 6.5 installed, but as you know my current Vcenter will not manage them until the upgrade.  Can I upgrade to 6.5 manage current 5.5 and 6.5 hosts, do the migration and then down the old hosts?

First, the key item is that vCenter doesn't care about Horizon View and isn't even aware of it. View is just making API calls to vCenter to run tasks, the focus is not on vCenter but Horizon View. The roadblock people typically hit when upgrading the vCenter with Horizon View is the hostname. If you are upgrading and keeping the hostname, you can pull this off with little pain.

1. First, you need to verify your version of View is compatible with vSphere 6.5: VMware Product Interoperability Matrices
   1. For instance, version 6.x is not.
2. Then, if you are changing the certificate or CA, that the connection server and composer server trust the CA.
3. Finally, you can keep view running during the upgrade. Best to just shutdown composer, and disable provisioning on all pools.

Worse case, you may have to remove and re-add the vCenter server in View Admin. Congrats you avoided the worst which is dealing with a new vCenter hostname and updating all your pools to point to it.

ProTip - PowerCLI for View is excellent if you needed to mass update the pools.