Solved: Re: VMWare vCenter Upgrade 6.7 (18831049) to 7.0U3... - Page 2

MKey90 · ‎11-30-2021

Hello,

we are trying to Upgrade our vCenter 6.7 (18831049) to vCenter 7.0U3a.

Stage 1 in the Migration Process is working normally.

Stage 2 fails with the following Error:

Internal error occurs during Export of VMware vSphere Update Manager.
Error from the Support Bundle Logfile - "Export_com.vmware.vcIntegrity_..."
- 2021-11-29T14:25:50.586Z ERROR __main__ Upgrade Phase 'vcIntegrity:Export' failed. Exception: list index out of range
  Traceback (most recent call last):
  File "/tmp/vmware-upgrade-temp-dirBpwKTL4VL0/tmpFXZ1iaTIKD/payload/componentPhaseLauncher.py", line 461, in main
  executionResult = systemExtension(exeContext)
  File "/tmp/vmware-upgrade-temp-dirBpwKTL4VL0/tmpFXZ1iaTIKD/libs/sdk/extensions.py", line 94, in __call__
  result = self.extension(*args)
  File "/tmp/vmware-upgrade-temp-dirBpwKTL4VL0/tmpFXZ1iaTIKD/libs/sdk/extensions.py", line 110, in _func
  return func(*args)
  File "/tmp/vmware-upgrade-temp-dirBpwKTL4VL0/tmpFXZ1iaTIKD/payload/component-scripts/vcIntegrity/__init__.py", line 50, in doExport
  return vcIntegrity_upgrade.exportData(context)
  File "/tmp/vmware-upgrade-temp-dirBpwKTL4VL0/tmpFXZ1iaTIKD/payload/component-scripts/vcIntegrity/vcIntegrity_upgrade.py", line 379, in exportData
  exportDataLin(context)
  File "/tmp/vmware-upgrade-temp-dirBpwKTL4VL0/tmpFXZ1iaTIKD/payload/component-scripts/vcIntegrity/vcIntegrity_upgrade.py", line 357, in exportDataLin
  vumDBPassword = vumDBPasswordElem[0].text
  IndexError: list index out of range

What i tried so far:

Update our vCenter 6.7 (18831049) to 7.0 U2d -> same error

Resetting the Update Manager Database (KB2147284) -> same error

Does anyone have any more ideas on what else I could try?

best regards

McFly_IT · ‎01-24-2022

Same boat here, same exact versions.

Glad I found this post! I tried 3 different versions.

Waiting...

rgb99 · ‎01-27-2022

Crap, I also ran into this when trying to upgrade from 6.7 U3p to 7.0 U2d. All we can do is wait. I believe the new release of 7.0 Update 3 is a couple of weeks away -- we'll see!

ChadMarkley · ‎01-27-2022

I keep hoping with each update I get via email from this thread is someone saying the new release of Vcenter has been released! lol STILL WAITINGGGGGG

rgb99 · ‎01-27-2022

Just subscribe to https://kb.vmware.com/s/article/2143838 and you should get notified when it updates.

tomwerf · ‎01-28-2022

@rgb99thanks for the tip! (the link is without the comma) https://kb.vmware.com/s/article/2143838

The first thing I did every morning is check the VMWare site if there is a new vCenter 7 version available.

Still waiting....

DM_80 · ‎01-28-2022

Updates:

vCenter 7.0 U3c can be downloaded here
ESXi 7.0 U3c can be downloaded here

This is reflected in Security Advisory VMSA-2021-0028 for Log4j

Release Notes can be found here.

Note that KB2143838 has not yet been updated to include the vCenter 7.0 U3c release

Good luck upgrading to all of you!

mastamme · ‎01-30-2022

vCenter 7U3c is now supportet to upgrade from 6.7U3p https://kb.vmware.com/s/article/67077?lang=en_us

McFly_IT · ‎02-01-2022

Thank you, I wasn't paying attention.

woohoo!

Has anyone tried it yet?

MKey90 · ‎02-01-2022

I updated my two vCenters with the 7.0U3c Patch - worked without problems.

tomwerf · ‎02-01-2022

Yes, I did the upgrade yesterday. Works like a charm! I'm so happy right now!

Only thing, during the upgrade, Stage 2, step 3, there was not enough diskspace for the Export of the data on /
I used the /storage/core as export directory.

ChadMarkley · ‎02-04-2022

It worked like a champ!! I am having an issue now where my vcenter 7 appliance is using up 2TB of space!! But the largest volumes have barely any data in it. I did find an article that shows me how to "shrink" them, but it seems kinda janky. Anyone else seeing this? Oh, and I did select the "tiny" option during the migration/upgrade. Here is the output of my df -h command

I looked at a couple of other similar sized V7 clusters we also support and jotted down the average sizes of these same folders. Really out of whack. I did open a case with support and they sent me the sizing table. According to the upgrade table the tiny size COULD be as large as 2TB or even 4TB. But with this client, it makes no sense. I am going to make a new forum post so others can follow this specific issue and the hopeful resolution

Orddie1 · ‎03-24-2022

Running into the same issue.

The current Vcenter is 6.7 build 19300125 released 02-08-22

I tried to upgrade to 7.0.1c build 17327517 released 12-17-20

I understood the findings to say ignore the year, look at month and date and as long as the release you are moving to was done after the release you are currently on, the upgrade should work.

I'm getting the same error.

rgb99 · ‎03-31-2022

"ignore the year"?! No, if the current version is newer by release date, including the year is more recent than the version you are trying to upgrade to, again, by release date, then it is not possible.

https://kb.vmware.com/s/article/67077 has all of the information you need to show what is possible.

Spoiler: You can only upgrade to 7.0U3c or 7.0U3d from vCenter Server 6.7.0 U3q (19300125).

cj0nes · ‎08-17-2022

I had a very similar experience to this too. Initially, I updated my existing VC to the latest available version of 6.7 (6.7.0.53000 with release date 7/12/22). Upon running through the first VC upgrade attempt to version 7.0.3.00500 (obtained via VMUG), released on 3/29/2022, I got to 50% on Stage 2 and waited. Nothing happened for the better part of 30 mins, so I ended up going to the new VC's console and there, it had a message "Upgrade export failed". Came across this article, which led me to the VC 6.7 to 7.0 upgrade matrix (thanks to @Quickpaw). Cross referencing the build numbers I was working with, 19832974 for the 6.7 VC and 19480866 for the 7.0 VC, this indeed was not a supported upgrade path.

I redeployed a 6.7 VC with version 6.7.0.52000, released 2/08/2022. On the second upgrade attempt using the same 7.0 version, I got further.

I did have some odd networking behavior at the same 50% Stage 2 step, not sure if to be expected or I was doing something wrong. Odd networking behavior number 1 : the VC would lose network connectivity during this step. I am running my VCs on a distributed port group that uses ephemeral binding, not sure if that contributed or not. From previous research on the initial issues with this whole situation, I came across this article. I enabled MAC Address Changes, but still had a loss in connectivity on the same step. I ended up having to disconnect the VC's NIC and reconnect it during this step. Not sure if it was the disconnect and reconnect alone or in combination with the MAC Address Change setting that allowed me to progress.

Near the end of the upgrade, I received a message saying that the VC's MAC address was changed to match the source VC's MAC address and I should manually change it to the MAC it already had. Odd networking behavior #2: I attempted to do that, but the ESXi Client yelled at me about "impermissible static ethernet address. It conflicts with VMware reserved MACs". Alrighty, so I put it back to automatic and it set itself to the exact MAC I was manually trying to set. It booted up and didn't have any network connectivity at all. The MAC inside the guest was different than what was set on the virtual NIC. I ended up having to boot the previous VC to reconfigure the NIC MAC address via vSphere. After this, the next boot of the new VC had matching MACs and I was able to connect.

My takeaways from this experience:

Don't assume that updating to the latest version of a product is best practice prior to upgrading between major versions (counter-intuitive if you ask me)
It's quite silly that this release date requirement isn't some sort of pre-check before upgrading
- Can confirm that a VC 6.7 with a release date older than VC 7.0 is able to be upgraded successfully, whereas the inverse fails
I might've been able to reconfigure the MAC from the new VC's VAMI, but I had already fixed it

Hopefully this is able to help anyone that may come across this bumpy upgrade experience.

cj0nes · ‎08-17-2022

I had a very similar experience to this too. Initially, I updated my existing VC to the latest available version of 6.7 (6.7.0.53000 with release date 7/12/22). Upon running through the first VC upgrade attempt to version 7.0.3.00500 (obtained via VMUG), released on 3/29/2022, I got to 50% on Stage 2 and waited. Nothing happened for the better part of 30 mins, so I ended up going to the new VC's console and there, it had a message "Upgrade export failed". Came across this post, which led me to the VC 6.7 to 7.0 upgrade matrix (thanks to @Quickpaw). Cross referencing the build numbers I was working with, 19832974 for the 6.7 VC and 19480866 for the 7.0 VC, this indeed was not a supported upgrade path.

I redeployed a 6.7 VC with version 6.7.0.52000, released 2/08/2022. On the second upgrade attempt using the same 7.0 version, I got further.

I did have some odd networking behavior at the same 50% Stage 2 step, not sure if to be expected or I was doing something wrong. Odd networking behavior number 1 : the VC would lose network connectivity during this step. I am running my VCs on a distributed port group that uses ephemeral binding, not sure if that contributed or not. From previous research on the initial issues with this whole situation, I came across this article. I enabled MAC Address Changes, but still had a loss in connectivity on the same step. I ended up having to disconnect the VC's NIC and reconnect it during this step. Not sure if it was the disconnect and reconnect alone or in combination with the MAC Address Change setting that allowed me to progress.

Near the end of the upgrade, I received a message saying that the VC's MAC address was changed to match the source VC's MAC address and I should manually change it to the MAC it already had. Odd networking behavior #2: I attempted to do that, but the ESXi Client yelled at me about "impermissible static ethernet address. It conflicts with VMware reserved MACs". Alrighty, so I put it back to automatic and it set itself to the exact MAC I was manually trying to set. It booted up and didn't have any network connectivity at all. The MAC inside the guest was different than what was set on the virtual NIC. I ended up having to boot the previous VC to reconfigure the NIC MAC address via vSphere. After this, the next boot of the new VC had matching MACs and I was able to connect.

My takeaways from this experience:

Don't assume that updating to the latest version of a product is best practice prior to upgrading between major versions (counter-intuitive if you ask me)
It's quite silly that this release date requirement isn't some sort of pre-check before upgrading
- Can confirm that a VC 6.7 with a release date older than a VC 7.0 build is able to be upgraded successfully, whereas the inverse fails
I might've been able to reconfigure the MAC from the new VC's VAMI, but I had already fixed it

Hopefully this is able to help anyone that may come across this bumpy upgrade experience.

All

VMWare vCenter Upgrade 6.7 (18831049) to 7.0U3a