When creating vvol data store, the following problem occurred.
1. After creating the VVOL Data Store from the storage container (1500GB), the size is to be srinked to 0 byte.
2. Then, the created data store is to be marked as "disabled (inactivated)."
3. Also, the information of PE (Protocol Endpoint) is not displayed.
4. we have confirmed this occurs on both IP and DNS(FQDN).
[ESXi 6.5 vvold.log]
info vvold[9B08B70] [Originator@6876 sub=Default] VasaSession::GetEndPoint: with url https://<VASAProvider FQDN>:5989/vasa-providers.xml
warning vvold[9B08B70] [Originator@6876 sub=Default] VasaSession::GetEndPoint: failed to get endpoint, err=SSL Exception: Verification parameters:
--> PeerThumbprint: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
--> ExpectedPeerName: <VASAProvider FQDN>
--> The remote host certificate has these problems:
--> * Host name does not match the subject name(s) in certificate.
--> * Certificate with insecure version less than 3, using default
[ESXi 6.5 esxcli]
# esxcli storage vvol vasaprovider list
VP Name: <VASAProvider FQDN>
URL: https://<VASAProvider FQDN>:5989/vasa-providers.xml
Array Id: VmaxVVolVasaProvider:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Is Active: true
How do I avoid certificate errors?
Thank you and best regards,
Hello Ken, did you figure this one out? I'm experiencing the same problem right now on ESXi and vCenter 6.7 on a Nimble array. The Vvol container is successfully advertised to vCenter and I can connect it to the hosts, but then the connection fails and no protocol endpoints are displayed.
The certificate the SAN presents to vCenter appears to use FQDN, but the VASA provider is registered with IP address. I'm wondering if the mismatch is confusing the vvold service.
I manually re-registered the VASA provider URL with vCenter so everything was FQDN. Our DNS entry for the array works fine for vCenter and the hosts, but still no PE is displayed on any of the hosts and they cannot write to the Vvol datastore, nor retrieve its size.
CA certs have been refreshed on all the hosts... even tried deleting rui.crt from the root store and breaking the vCenter trust, then re-adding one of the hosts and re-generating both the host and vvol service SSL, and still nothing.
/sbin/generate-certificates && /etc/init.d/hostd restart && /etc/init.d/vpxa restart
We then verified port 8443 works via netcat and is reachable off the array by curl 'ing the XML out of the VASA URL from vCenter SSH and verifying its contents are the same as when hit in the browser, to rule out any in-flight network corruption.
Vvol service is allowed to go out of ESXi firewall.
NTP sync is also tight between the hosts, vCenter and the array.
It's getting difficult to identify what is left to check, except for maybe seeing an old PSC we had to decommission (verified no longer a replication partner) still being listed in the output of openssl s_client -connect <array_IP>:8443