While deploying a fresh image of HPE SimpliVity on a Cisco UCS machine, I came across a problem where the HPE SimpliVity Deployment Manager was not able to recognize the IP address of the machine as OmniStack host.
This article explains the cause and how to fix it.
I had performed a factory reset with the HPE SimpliVity 3.7.8 software bundle (latest version at moment of writing) on a Cisco UCS C240 M4 Rack Server . And continued with the HPE SimpliVity Deployment Manager as I am used to.
However, this time, after entering the IP address of the OmniStack host, it came back with some sort of “not recognized” error as shown below.
I made sure that there were no network issues, firmware was up to date and did a double check on the compatibility of the system together with the SimpliVity 3.7.8 software.
Everything seemed fine! So I decided it was time to do some log digging.
HPE SimpliVity Deployment Manager stores logs in C:\Users\%username%\AppData\Local\DeploymentManager
You can analyze the files “finddeployable.log” and “SvtDeploymentManager.txt” and troubleshoot what’s happening.
In my case, I noticed the following lines:
ERROR Simplivity.DM.ConfigurationController.Impl.OrchestratorOmniCubeDiscoveryService [LogError] – IP address not assigned to an HPE OmniStack host or not ready for deployment. Enter a unique IP address for an HPE OmniStack host and try again.
2019-05-06 11:43:25,955Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:169) – Checking OmniCube at 172.16.16.99
2019-05-06 11:43:26,680Z INFO Thread-1 [c.s.u.c.CryptoUtils] installProvider(CryptoUtils.java:124) – Installed BouncyCastle Security Provider v1.56
2019-05-06 11:43:27,096Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:237) – Connected to OmniCube at address: 172.16.16.99 port: 9292
2019-05-06 11:43:27,097Z INFO Thread-1 [c.s.d.f.FindDeployable]
2019-05-06 11:43:27,098Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:247) – Waiting to be Discovered
2019-05-06 11:43:27,099Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:252) – OEM: Cisco memory: 412317 Megs cpus sockets: 2 cores per: 8 – Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
2019-05-06 11:43:27,099Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:258) – Supported hypervisors:
2019-05-06 11:43:27,099Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:261) – type: HyperV version: 10.0.14393 build: 2580 info: HyperV Server 2016
2019-05-06 11:43:27,099Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:266) – Supported SVAs:
2019-05-06 11:43:27,099Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:269) – 184.108.40.206-release
2019-05-06 11:43:27,100Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:271) – Disks:
2019-05-06 11:43:27,102Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:274) – name: sda model: UCSC-MRAID12G size: 1198 Gigs
2019-05-06 11:43:27,102Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:274) – name: sdb model: UCSC-MRAID12G size: 14995 Gigs
2019-05-06 11:43:27,102Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:274) – name: sdc model: INTEL SSDSC2BB48 size: 480 Gigs
2019-05-06 11:43:27,103Z INFO Thread-1 [c.s.d.f.FindDeployable] getSystemInfo(FindDeployable.java:274) – name: sdd model: Hypervisor size: 64 Gigs
What I found strange, is that it did read the model, CPU and disk details. And that it connected. But for some reason it didn’t detect the system as OmniStack host.
Also; it only showed HyperV as a supported hypervisor. I don’t remember if this is default behavior, but it seemed off to me.
Trial and Error
I decided to reset the system to 3.7.7, maybe there was some sort of bug in 3.7.8 that was not announced yet. No luck here tho.
The next thing I wanted to try, was a reset to 3.7.0. A version that was shipped with the machine in the first place. And then upgrade to 3.7.8.
Before I could try this, I received feedback from my network that from SimpliVity 3.7.4, there is no longer a Cisco image shipped in the factory reset and Deployment Manager. The recommended approach here was to reset to 3.7.3 and upgrade onwards. I tried the 3.7.3 version but was still hitting the same issue. Resetting to a 3.7.0 image seemed to work.
This approach is only possible if you are creating a new federation. If you are joining an existing federation, you should contact HPE support as there are some XML tweaks required in the Deployment Manager and manually uploading the Cisco image to the SimpliVity installer using SCP.
Resetting the system to SimpliVity 3.7.0 and upgrading onwards seems like a valid solution! I think HPE should mention this approach in their release notes, as the systems are actually supported and mentioned on the release notes.
I am assuming that this issue is also valid for other “legacy” SimpliVity systems (Dell and Lenovo). If you have experience with this, please reply with a comment below.
Update 15th of June 2019:
I’ve hit this issue again with a Lenovo host running SimpliVity 3.7.6. After contacting HPE Support, the supplied another (better) workaround:
- SimpliVity node is running 3.7.1 or higher
- SimpliVity node is in Discovery mode (ready for deployment)
- Mount the SimpliVity 3.7.0 legacy image using iLO / iDRAC / IMM / CIMC
- Login using Troubleshooting > Shell or using SSH
- Execute su root
- Execute ./opt/svtdi/legacyTools/fetch_legacy
After running these steps, the ESXi image will be fetched from the mounted ISO and copied to the right folders. Restart your HPE Deployment Manager and see that the ESXi image is now identified and ready for deployment! You can use this to deploy a new federation, but also creating a new cluster in an existing federation (verified).