Hot on the heels on Pure Storage’s recent announcement on Virtual Volume (VVol) support, I wanted to take a closer look at their VVol implementation for myself. Thanks to the support team over at Pure, they were able to very quickly update our lab array to the latest release that has support for VVols. Once this upgrade was complete (which was all done remotely), I wanted to go ahead and register the VASA provider with my vCenter server. You can read more about the role of VASA here. I wanted to step through the process manually, rather than use the web client plugin which has an automated mechanism (the plugin is probably the best approach if you are a Pure customer though). However, I did get tripped up with configuring the VASA provider manually, and I thought I’d share this here in case you had the same issue.

So let’s start with a closer look at my Pure array. There were 3 interfaces, 2 controller interfaces and 1 virtual interface. All are tagged as management, but it is the virtual interface that we use to connect to the array to manage it. The network connections look something like this:

Naturally, I assumed (and you know what they say about ass-u-me) that the VASA Provider would be on the same management interface that we use to connect to the array. So I went ahead, and used this IP of vir0 to try to register the VP (VASA Provider) on my vSphere web client. The URL to use for Pure VPs is https://x.x.x.x:8084. You also need to provide administrative login credentials to the array when registering the provider. When I did this, but use the vir0 ip address above, I hit the following error (whilst this also appears on the UI, I caught this from the sps.log file which is in /storage/log/vmware/vmware-sps on the vCenter appliance):

2018-01-30T08:32:47.348Z [pool-14-thread-1] DEBUG opId= com.vmware.vim.storage.common.util.SimpleTimeCounter \ - TIMER STARTED: CertificateAuthority : VMCA getCertificate() 2018-01-30T08:32:47.349Z [pool-14-thread-1] DEBUG opId= com.vmware.vim.sms.provider.vasa.cert.CertificateAuthority \ - [getCAsignedCertificate] notBefore time - Mon Jan 29 08:32:47 GMT 2018, notAfter time - Wed Jan 30 08:32:47 GMT 2019 2018-01-30T08:32:47.358Z [pool-14-thread-1] ERROR opId= com.vmware.vim.sms.provider.vasa.cert.VmcaClientHandler \ - Exception in invocation of getCertificateForHost java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.vmware.vim.sms.provider.vasa.cert.VmcaClientHandler.invokeMethod(VmcaClientHandler.java:43) at com.vmware.vim.sms.provider.vasa.cert.VmcaClientHandler.invoke(VmcaClientHandler.java:31) at com.sun.proxy.$Proxy88.getCertificateForHost(Unknown Source) at com.vmware.vim.sms.provider.vasa.cert.CertificateAuthority.getCAsignedCertificate(CertificateAuthority.java:117) at com.vmware.vim.sms.provider.vasa.cert.CertificateManagerImpl.getCAsignedCertificate(CertificateManagerImpl.java:306) at com.vmware.vim.sms.provider.vasa.VasaProviderImpl.provisionCertificate(VasaProviderImpl.java:493) at com.vmware.vim.sms.provider.vasa.version.Version3Strategy.provisionCASignedCertificate(Version3Strategy.java:107) at com.vmware.vim.sms.provider.vasa.VasaProviderImpl.init(VasaProviderImpl.java:1024) at com.vmware.vim.sms.provider.ProviderFactory.createVasaProvider(ProviderFactory.java:215) at com.vmware.vim.sms.provider.ProviderFactory.createProvider(ProviderFactory.java:159) at com.vmware.vim.sms.StorageManagerImpl.registerProviderInt(StorageManagerImpl.java:536) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.vmware.vim.sms.task.JobHandler.run(JobHandler.java:70) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: com.vmware.certificate.VMCAException: VMCA_ERROR_SAN_IPADDR_INVALID at com.vmware.certificate.VMCAAdapter2.THROW_IF_NEEDED(VMCAAdapter2.java:361) at com.vmware.certificate.VMCAAdapter2.VMCAGetSignedCertificateForHost(VMCAAdapter2.java:455) at com.vmware.certificate.VMCAClient.getCertificateForHost(VMCAClient.java:341) at com.vmware.certificate.VMCAClient.getCertificateForHost(VMCAClient.java:308) at com.vmware.vim.sms.provider.vasa.cert.SmsVmcaClientImpl.getCertificateForHost(SmsVmcaClientImpl.java:107) ... 25 more 2018-01-30T08:32:47.359Z [pool-14-thread-1] DEBUG opId= com.vmware.vim.sms.provider.vasa.cert.SmsVmcaClientImpl \ - Initializing VmcaClient.... 2018-01-30T08:32:47.369Z [pool-14-thread-1] ERROR opId= com.vmware.vim.sms.provider.vasa.cert.CertificateAuthority \ - Failed to get a VMCA signed certificate for CSR. Error : 70069 Message : VMCA_ERROR_SAN_IPADDR_INVALID

So the invalid IP address was a bit of a clue. What I should have been doing is registering the IP addresses on the controllers, e.g. https://<IP of ct0.eth0>:8084 and https://<IP of ct1.eth0>:8084. In my case, these were IP addresses 246 and 247. Once I picked the controller IP addresses, I was able to register the VASA provider successfully.

And now I’m ready to go ahead with my Protocol Endpoint discovery, the setup of my Storage Container/Virtual Volume Datastore and deploying my VMs as a bunch of virtual volumes. If you are also starting out with this, check out these useful docs from Pure.