Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

"Internal error occurs during pre-upgrade checks"while upgrading to vCenter Server appliance 7.0 (78296)

Last Updated: 1/20/2021Categories: TroubleshootingTotal Views: 26205Language:
Chinese (Simplified)JapaneseEnglish

4 like this article

Subscribe to get an email
newsletter with new updates

4 people found this helpful Please provide article feedback:

Symptoms

Upgrading  vCenter Server Appliance 6.7 to 7.0 fails with the error:

Internal error occurs during pre-upgrade checks.Resolution:
Send upgrade logs files to GSS for further assistance.

In the /var/log/vmware/upgrade/upgrade-requirements.log, you see message similar to:

2020-02-12T05:31:10.22Z ERROR __main__ ERROR: Fatal error during upgrade REQUIREMENTS. For more details take a look at: /var/log/vmware/upgrade/requirements-upgrade-runner.log
Traceback (most recent call last):
File "bootstrap_scripts/run-preupgrade-checks.py", line 145, in main
commandFactory = getCommandFactory(upgradeParameters, execData, reporter)
File "/usr/lib/vmware/cis_upgrade_runner/bootstrap_scripts/upgrade_commands.py", line 4063, in getCommandFactory
factory = _getLinuxCommandFactory(upgradeParameters, settings, reporter)
File "/usr/lib/vmware/cis_upgrade_runner/bootstrap_scripts/upgrade_commands.py", line 3960, in _getLinuxCommandFactory
upgradeParameters['source-host-thumbprint'])
File "/usr/lib/vmware/cis_upgrade_runner/libs/sdk/transport/guestops.py", line 1600, in createGuestOpsOperationManager
vmAddress, guestUser, guestPassword, sslThumbprint)
File "/usr/lib/vmware/cis_upgrade_runner/libs/sdk/transport/guestops.py", line 234, in __init__
.FindByIp(None, self._vmAddress, True)
File "/usr/lib/vmware/cis_upgrade_runner/libs/pyVmomi.zip/pyVmomi/VmomiSupport.py", line 556, in <lambda>
self.f(*(self.args + (obj,) + args), **kwargs)
File "/usr/lib/vmware/cis_upgrade_runner/libs/pyVmomi.zip/pyVmomi/VmomiSupport.py", line 368, in _InvokeMethod
return self._stub.InvokeMethod(self, info, args)
File "/usr/lib/vmware/cis_upgrade_runner/libs/pyVmomi.zip/pyVmomi/SoapAdapter.py", line 1481, in InvokeMethod
raise obj # pylint: disable-msg=E0702
pyVmomi.VmomiSupport.vmodl.fault.SystemError: (vmodl.fault.SystemError) {
dynamicType = <unset>,
dynamicProperty = (vmodl.DynamicProperty) [],
msg = 'vim.fault.InvalidState',
faultCause = <unset>,
faultMessage = (vmodl.LocalizableMessage) [],
reason = 'Invalid fault'
}

2020-02-12T05:31:10.24Z INFO root Exiting with exit-code 1

In source hostd.log, you see message similar to:

2020-02-12T04:19:51.505Z info hostd[13947533] [Originator@6876 sub=Vimsvc.TaskManager opID=fb50909a user=root] Task Created : haTask--vim.SearchIndex.findByIp-54348
2020-02-12T04:19:51.514Z info hostd[13947442] [Originator@6876 sub=Default opID=fb50909a user=root] AdapterServer caught exception: N3Vim5Fault12InvalidState9ExceptionE(Fault cause: vim.fault.InvalidState
--> )
--> [context]zKq7AVICAgAAAJA0nQATaG9zdGQAAAy3NWxpYnZtYWNvcmUuc28AAJDIGwDwuBcBg/ViaG9zdGQAAUQhagHSIWoB0hK1AQfBZAFg2GQBVeVkARbpZIJ2LAEBbGlidmltLXR5cGVzLnNvAAE1C8IBLRTCALVNKACTUSgAyyw2Azt9AGxpYnB0aHJlYWQuc28uMAAEHZsObGliYy5zby42AA==[/context]
2020-02-12T04:19:51.518Z info hostd[13947442] [Originator@6876 sub=Vimsvc.TaskManager opID=fb50909a user=root] Task Completed : haTask--vim.SearchIndex.findByIp-54348 Status error
2020-02-12T04:19:51.518Z info hostd[13947442] [Originator@6876 sub=Solo.Vmomi opID=fb50909a user=root] Activation [N5Vmomi10ActivationE:0x000000836d711860] : Invoke done [findByIp] on [vim.SearchIndex:ha-searchindex]
2020-02-12T04:19:51.518Z verbose hostd[13947442] [Originator@6876 sub=Solo.Vmomi opID=fb50909a user=root] Arg datacenter:
--> (null)
2020-02-12T04:19:51.518Z verbose hostd[13947442] [Originator@6876 sub=Solo.Vmomi opID=fb50909a user=root] Arg ip:
--> "10.x.x.x"
2020-02-12T04:19:51.518Z verbose hostd[13947442] [Originator@6876 sub=Solo.Vmomi opID=fb50909a user=root] Arg vmSearch:
--> true
2020-02-12T04:19:51.518Z info hostd[13947442] [Originator@6876 sub=Solo.Vmomi opID=fb50909a user=root] Throw vim.fault.InvalidState
2020-02-12T04:19:51.518Z info hostd[13947442] [Originator@6876 sub=Solo.Vmomi opID=fb50909a user=root] Result:
-->(vim.fault.InvalidState) {
-->faultCause=(vmodl.MethodFault) null,
-->    faultMessage = <unset>
-->    msg = ""
--> }

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Cause

During upgrade prechecks, a call to the SearchIndex.findByIp VIM API might encounter an invalid VM during iteration. At this point, an error will occur and the call will fail before checking all VMs (usually this occurs when the invalid VM is traversed before the VM with the desired IP). This will fail upgrade prechecks.

Resolution

This is a known issue.

Currently, there is no resolution.

Workaround

To workaround this issue:

Make sure there are no VMs on the host which would cause the call to fail. Specifically:

Make sure there are no VMs that are in the process of being created/deleted from disk/added to the inventory/reloaded - such VMs may also raise the same error so wait until these operations are completed.

Determine if there are any invalid VMs by running the command:

vim-cmd vmsvc/getallvms

Example: a 'Skipping invalid VM' warning will be listed for all invalid VMs

Skipping invalid VM '241'
Vmid                    Name                                                             File                                                  Guest OS          Version

Examine the invalid VMs : VM's may be invalid due to issues with configuration, storage inaccessibility, missing disks/VMX files etc. If the issue cannot be remediated, make sure they do not interfere with the upgrade, unregister them from the host.

For example, using vim-cmd:

vim-cmd vmsvc/unregister 241

Execute the unregister command for each invalid VM.

Re-try the upgrade.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
「AMQP ブローカ接続のテスト：失敗 - ACCESS_REFUSED - 認証メカニズム PLAIN を使用したログインが拒否されました。詳細については、ブローカのログ ファイルを参照してください。(Test AMQP Broker Connection: Failed - ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.)」 (76149)

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vCenter Server Appliance

VMware vCenter Server

Related Versions:

VMware vCenter Server Appliance 6.7.x

VMware vCenter Server 7.0.x

Take Our Survey

Support Assistant