I am creating the RHEV pseudo-client with the Customer.
We have noticed that during creating RHEV pseudo-client, Commvault uses port 80 (http) to comunicate with RHEV Manager.
Port 80 (http) is blocked by the firewall. They use only https (port 443) in the environment due to some safety restrictions.
Is any way to force Commvault (VSA) to use port 443 during creating RHEV pseudo-client?
Best answer by AplynxView original
@Kamil W ,
What version of Commvault FR and MR are you using here please?
The reason for asking is that some recent MR’s include a patch to resolve the configuration issue when Port 80 is blocked:
Maintenance Release 11.24.2
Maintenance Release 11.23.17
Maintenance Release 11.22.32
It’s definitely FR20. I’ll ask the Customer about version of Maintenance Release.
I’ll let you know ASAP.
CS is running 11.20.67
I cannot see any mention about the issue for FR20.
@Kamil W ,
I am checking this and will get back to you.
If your customer does not have any plans to move to the above stated versions, can you raise a case with Support? - We may be able to request this for back port to FR20.
Thanks & Kind Regards,
The Customer decided to upgrade CS to 11.22.45
I’ll let you know, how it goes ASAP.
@Kamil W , gentle follow up on this one. any word from your customer?
@Mike Struening !
Yes, I had a remote session with the Customer yesterday.
They upgraded CS to 11.24.7. However, once port 80 is blocked, backup of RHEV is not working.
It seems like port 80 is needed to initiate the connection, then Commvault is already using port 443 to backup the data. That’s what they see in the Firewall GUI.
Any ideas how to resolve this issue? They need to use port 443 (https) due to some safety policys.
With 24.7 installed, that would include hotfix 3030 (part of 24.2). If this is also installed on the proxy\access nodes for RHEV, when the initial denial happens on port 80 (http) a certificate should be generated either way and retried on port 443 (https). If 24.7 is on the proxies and we’re not seeing this behavior, please open a support incident for review.
Many thanks for your reply.
As I remember VSA is running 11.20.x.
Once the Customer updates VSA Proxy, I’ll let you know how it goes.
@Kamil W , following up to see if the customer has updated the proxy yet.
The customer has finally upgrated the proxy. Everything’s working as expected now.
Thank you for your help!
Sweet, thanks for the update!!
Good Morning Commvault Community,
The client encountered a similar problem but for the SP20 version. Do you have information, is there any fix for this version or do we need to contact CV support to write a new fix for SP20?
@Kamil created another thread for this.
A fix has been released, has been tested and works as described. OLVM communicated with commvault on port 443 after deploying this fix.
I don't know if I can share it and I don't know if it will be available in the official MR version, but if anyone needs it, they know where to find me ;)
Thanks for help