Please tar up the Results directory and attach back to this thread
You can also try the following in the meantime and let me know results.
From PrimecCient Linux terminal:
1. ping client0
2. ping IP_ADDR_OF_CLIENT0
3. STAF client0 ping ping
4. STAF IP_ADDR_OF_CLIENT0 ping ping
From Client0 Linux terminal:
5. ping PrimeClient
6. ping IP_ADDR_OF_PRIMECLIENT
7. STAF PrimeClient ping ping
8. STAF IP_ADDR_OF_PRIMECLIENT ping ping
Also, did you check the following from Page 83 of VMmark3 User Manual:
STAF Complains About Trust Level
If STAF complains that systems are at trust level 3, this suggests that the trust level settings in the STAF.cfgfile are not being correctly processed. To correct this, make sure each STAF.cfg file contains the following:
trust machine 192.168.*.* level 5
(substituting the first three octets of the network to which the machines are connected).
STAF is Unable to Connect to a Particular Server
If STAF is unable to connect to a particular server, this might be due to one of the following causes:
- Acommunicationorconfigurationproblem.From a terminal window on the client, type:staf alias ping ping(where alias is the alias in the client’s hosts file (for example, DS3WebA0)).The proper response is PONG.
- DissimilarversionsofSTAFareinstalled.Make sure all clients and all workload virtual machines are running the same version of STAF.
I noted that the "PrimeClient" entry was not in the host file on the Client0 VM. It has been added.
I have tested, this all worked without issue (I had only tested staf command from the PrimeClient, which had worked prior).
I believe I found your issue from that zip file. In the VMmark.properties file you have the following:
Deploy/DeployVMinfo = Client0:10.16.102.200,Standby0:10.16.102.219,DS3WebA0:10.16.102.201,DS3WebB0:10.16.102.202,DS3WebC0:10.16.102.203,DS3DB0:10.16.102.204,AuctionWebA0:10.16.102.213,AuctionWebB0:10.16.102.213,AuctionAppA0:10.16.102.215,AuctionAppB0:10.16.102.216,AuctionDB0:10.16.102.218,AuctionMSQ0:10.16.102.212,AuctionLB0:10.16.102.211,AuctionNoSQL0:10.16.102.217,ElasticWebA0:10.16.102.206,ElasticWebB0:10.16.102.207,ElasticAppA0:10.16.102.208,ElasticAppB0:10.16.102.209,ElasticDB0:10.16.102.210
Deploy/DeployVMinfo is for the names of the VMs that are created during the deploy Infrastructure workload NOT meant for provisioning. I believe the benchmark is trying to recreate / overwrite Client0.
Change the line to this and retry.
Deploy/DeployVMinfo = DeployVM1:10.16.102.245, DeployVM1:10.16.102.246, DeployVM2:10.16.102.247,DeployVM2:10.16.102.248,DeployVM3:10.16.102.249
DeployVMinfo corrections alleviated the STAF issues described. Latest issue is failing Weathervane QOS (see attached Score_1*.txt file).
The issue is with the QOS and Weathervane workload. This is usually due to the response times from the storage. This benchmark is mostly run on all flash storage. I know you are using your production storage in the production configuration. You can try kicking the benchmark in off hours and it might pass (less load on storage environment). Also, you can try the following in the mean time.
In, VMmark3.properties make these changes:
TurboMode = true (To shorten the run from 3 hours)
InfrastructureList = (To run only the workloads and no deploy, vmotions, svmotions, or xvmotion)