Solved

Hypervisor update (ESXi)


Badge +7
Anyone have insight on this:

I went to the 1-click upgrade screen in prism. We have a dell cluster. So I went to the dell website and got the offline bundle from Dell:
VMware-ESXi-6.0.0.update01-3073146.x86_64-Dell_Customized-offline-bundle-A01.zip

then I went to Nutanix site to get the metadata file:
6.0.0-u1a-3073146.json

when I click on upload, I get the error:
The size of the file to be uploaded does not match the size in the metadata file. You might have chosen the wrong file.
Would I be correct in thinking that the Dell vibs are added to this offline bundle and that its size is most likely bigger than the standard ESXi offline bundle? If this is indeed right, how does one who has a dell cluster upgrade the hypervisor in "Onc-click" with the Dell supported offline bundle?


icon

Best answer by mgauch 27 February 2016, 04:52

There's a Dell A01 metadata file. I would try that and see if it works. As a last resort you can update the md5sum/size with the size/md5sum of the package you are using. That should not be necessary though.

The link below will take you to the metada files, the dell version is likely on page 2.
https://portal.nutanix.com/#/page/static/hypervisorDetails

Direct link to Dell metadata file:
https://s3.amazonaws.com/ntnx-portal/hypervisor/esx/4.5.2.1/dell/6.0.0-u1a-3073146-Dell-A01.json



Let me know if that works.

View original

5 replies

Badge +5
There's a Dell A01 metadata file. I would try that and see if it works. As a last resort you can update the md5sum/size with the size/md5sum of the package you are using. That should not be necessary though.

The link below will take you to the metada files, the dell version is likely on page 2.
https://portal.nutanix.com/#/page/static/hypervisorDetails

Direct link to Dell metadata file:
https://s3.amazonaws.com/ntnx-portal/hypervisor/esx/4.5.2.1/dell/6.0.0-u1a-3073146-Dell-A01.json



Let me know if that works.
Badge +7
Thank you for that info, it was most helpful.

I'm running into another issue, it looks like the upgrade requires DRS, we don't have the ent+ license, so "No DRS for you!", declares VMware. Is there a way around the lack of DRS to do the upgrade through the automatic mechanism, or do I need to do it old school and do a VIB install in ESXi?




Side Question: How does Acropolis handle this? If prism can move the AHV machines around for upgrade, can't prism utilize vMotion to auto-move them as well?
Userlevel 7
Badge +30
Yes, DRS fully automated mode is required, because we need VMW and vCenter to move things around, since vCenter is the element manager that controls CRUD operations.

AFAIK, DRS is not just in Ent+, its in Ent, and a few other versions as well.

That said, yes, you can drop to "old school" and do VIB, or you could do things with VUM, but you'd experience the same drama with VUM, given you dont have DRS licensing.

RE AHV question - Since AHV is fully managed by Prism, we can do whatever we want in there. Nutanix already has a resource scheduler and live migration for AHV, so this is just "invisible" when you have AHV. Super, super easy.


Badge +7
OK, thanks. We're on Standard licensing, I would love to have DRS, but we do not. Also I use the VCSA for vCenter, so VUM doesn't work either. Old-School install it is!
Badge +3
Sorry to bring this old topic up again.

IMHO it is understandable that VMware won't allow Nutanix to recreate features as DRS that funcion for VMware as "unique selling points" for way more expensive higher license levels (as "the Enterprise Plus Edition").

But maybe Nutanix could deliver some detailed bits of information describing the hypervisor upgrade process from Prism (after the offline bundle .zip has been uploaded and verified) if DRS is available:

  • how does Prism "talk" to vCenter to set the respective host to maintenance mode?
  • how does Prism "talk" to the CVMs to set it 1st to mainenance and then powering it off?
  • how does Prism "talk" to the ESXi-host to stage and install the offline bundle and restart the host?
  • how does Prism "talk" to the cluster and keep it from rebuilding data resiliency during the hypervisor upgrade process?

Reply