Hi, thank you for attaching the results folder.
The reason you are seeing the SSL handshaking error is because the VMs' hosts files are not populated correctly.
Population of the hosts files occurs during the VMmark provisioning phase. It seems like provisioning may not have completed correctly for most of your VMmark VMs.
The VMs which had correct hosts files were DS3DB0, ElasticDB0, and PrimeClient, which are the VMs that passed in the VMmark3-STAX_Job_1_User-Parsed.log file:
20180618-10:03:18 Info GuestInfo Results : ElasticDB0 :: Passed : Errors 0 : ErrorMsgs none : Warnings 0 : WarningMsgs none
20180618-09:51:36 Info GuestInfo Results : DS3DB0 :: Passed : Errors 0 : ErrorMsgs none : Warnings 0 : WarningMsgs none
You'll need to delete and reprovision your VMmark tile. You can still keep DS3DB0, though, since it takes a while to initialize. In the VMmark User's Guide, see "Recreating Part of a Tile".
As to the STAX pop up, when are you receiving this error? Is it on every run, and when during the run does it appear? This is an unusual error. It might go away after you fix problem #1.
I tried reprovisioning the tile yesterday. The provisioning seemed like it initialized correctly. However, it was stuck at what looks like a perl script 12 hours later. I canceled and tried again to provision just AuctionAppA to see if that would finish, but it's been stuck at the same place for several hours. Any idea why it's getting hung up at this stage?
I'll attach the Vmark3.configuration file and the provisioning log.
The provisioning of all the VMmark VMs (besides the DS3DB initialization, which is initiated by VMmark provisioning) should happen in less than an hour.
You're right that the perl script executing on AuctionAppA0 seems to be hanging. This particular script should complete in just a few minutes at most. I don't know of a reason why this script would hang, especially because networking tests already passed on that VM. The only thing I see out of the ordinary is the use of '|' symbol in your network name which could potentially trip up some scripts.
I doubt that the rest of your VMs are initialized correctly either, as the first time you provisioned the tile, you said it hung at the AuctionAppA0 script so part of provisioning did not complete. I recommend deleting your existing VMs and redeploying all of them. Please upload the provisioning logs, like you did, if anything seems out of the ordinary.
In a correct provisioning, you should see at the end of the log something like:
I changed the network name to see if the provisioning would finish, but it's still hanging in the same spot. Is there anything else I could try? Or is there maybe a way to finish the provisioning manually?
To diagnose this problem, I'll need to see the provisioning logs from when you are provisioning all the VMs in the tile. I need to see whether it's hanging on just AuctionAppA0, or there could be a broader issue.
Thank you for providing the logs. The file AuctionAppA0-automation-output.txt, is that from the same provisioning run as the VMmark3-ProvisioningService.log or a different run? The timestamps are off.
One thing, in VMmark3.properties, make sure you change the field
ProvisioningDBsize = 1
back to its default
ProvisioningDBsize = 100
Or simply comment out the line.
We updated the lab vCenter to 6.5 and I tried provisioning again. I changed the DB size to 100GB and used a new ephemeral port group without the | symbol. But the provisioning process seems to be hanging in the same spot each time I try it.
vmmark3-output-65.zip 17.6 K
I can't see all of your network config, but I'm wondering if it may be too restrictive. I noticed your workload VMs (tile0) on 172.168.2.* are provisioned with subnet mask /23, yet your VC, prime client are on 172.168.1.* and 172.168.0.* Are all workload VMs able to ping the prime client and vice versa? And the prime client is clearly able to ping VC, as the provisioning process was able to start but not complete.