Simplivity 3.7.9 deployment manager test failure

[VA_Rich]

I am attempting to deploy a simplivity host to be the 2nd host in a federation and cluster.  Version of Simplivity is 3.7.9.  At the beginning of the Test Host Settings portion of Deployment Manager, I am getting an error:  Cluster Network Specification Retrieval.  Status: Failed.  Summary:  Failed to retrieve network specifications for cluster <our cluster name>.  

I have no idea what is causing this.  Has anyone else seen this?  Any ideas or suggestions as to how to remedy this error?  I really need to get this 2nd node deployed asap.  Thanks for any help and suggestions. 

[gustenar]

Do you have distributed switches only in that cluster? This will occur if there are no standard switches configured. 

[VA_Rich]

Actually, I don't have any distributed switches.  Only standard switches

[VA_Rich]

Looking through the deployment manager logs, I've found the following:

Previously Deployed Hosts
2019-12-10 17:40:56,541Z ERROR main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterHostsMTUConsistencyValidator: Previously Deployed Hosts is blocked by the following failed prerequisites:
2019-12-10 17:40:56,541Z ERROR main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterHostsMTUConsistencyValidator:  + Cluster Network Specification Retrieval
2019-12-10 17:40:56,546Z DEBUG main [c.s.d.v.NetworkPortAccessValidator] executeTestPlan(ValidationExecutor.java:37) - Previously Deployed Virtual Controllers
2019-12-10 17:40:56,547Z ERROR main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterOVCsMTUConsistencyValidator: Previously Deployed Virtual Controllers is blocked by the following failed prerequisites:
2019-12-10 17:40:56,548Z ERROR main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterOVCsMTUConsistencyValidator:  + Cluster Network Specification Retrieval
2019-12-10 17:40:56,554Z INFO  main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterMTUConsistencyValidationAggregator: Skipped MTU consistency test for previously deployed hosts and Virtual Controllers.
2019-12-10 17:40:56,557Z DEBUG main [c.s.d.v.NetworkPortAccessValidator] executeTestPlan(ValidationExecutor.java:37) - NIC Speed Consistency for Previously Deployed Hosts Test
2019-12-10 17:40:56,557Z ERROR main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterHostsNICConsistencyValidator: NIC Speed Consistency for Previously Deployed Hosts Test is blocked by the following failed prerequisites:
2019-12-10 17:40:56,557Z ERROR main [c.s.d.v.NetworkPortAccessValidator] logValidationSummary(AbstractValidator.java:365) - ClusterHostsNICConsistencyValidator:  + Cluster Network Specification Retrieval
2019-12-10 17:40:56,557Z DEBUG main [c.s.d.v.NetworkPortAccessValidator] executeTestPlan(ValidationAggregator.java:174) - Host 2M2931052Q

So it appears Deployment Manager is attempting to find the MTU of the previously deploy Simplivity host, but for some reason it cannot.  The message is stating blocked, but both hosts are on the same subnet and there are no firewalls, etc. between them.  Any ideas, etc.?

[gustenar]

I think the MTU test is not even starting because it can't retrieve the cluster's config. What NIC card is being used for the deployment? 

[VA_Rich]

We are using an HPE Eth 10/25 GB 2 port 640SFP28 adapter.  Simplivity version 3.7.9

[VA_Rich]

Sorry, I forgot to add the cluster has only one node deployed at this time.  The node I'm trying to deploy would be the 2nd node.  Don't think that makes a difference....

[VA_Rich]

And firmware version for the NICs is 14.23.8036

[policeman51]

I'm following this as well.

I'm working with the Deployment Team and we are running into the same issue on a single node deploying 3.7.6

[DaveOb]

Is the physical network consistent? 

You could try swapping the physical cables from the deployed node at the server side to the non deployed node.

Are you using a 25 or a 10  physical network.if so are the sfps the same.ie your using all 25gb sfps.Is there something like autonegotiate set on one switch and not on the other?

If you are confident that the physical network is the same then the tests can be bypassed but you will need to compare post deploy,

path names many change depending on version.

C:\Program Files (x86)\SimpliVity\DeploymentManager

Find and edit “Simplivity.DM.View.exe.config” XML file

Under “<appSettings>” find the following line

<add key=”PredeployValidationOverride” value=”False”/>

With:

<add key=”PredeployValidationOverride” value=”True”/>

[VA_Rich]

I finally figured it out.  I think you are correct; there is some network inconsistency with vlan assignment, etc.  However, what fixed it for me was removing a vmkernel port I had put in previously in the first host for vmotion.  I'm guessing there was some vlan assignment that wasn't made, however, to deploy the 2nd node, I didn't need the vmotion vmkernel port, so I deleted it and the deployment completed successfully.  Now, onto the next problem....  

[Broan]

We spent 24h in line with HPE without finding....

This saved our life.

Thanks 

[Stefano Colombo]

It happened to me with 5.0.

You saved my day

thanks

[mnfri]

Happen also with 5.2.
Saved the day (sure the week... maybe the entire month) during a time constraint rehaul/migration.

Thank a lot