The Windows Proxy doesn’t have as many requirements as far as configuring it. It just needs to be 2012x64 or higher and can be designated as a proxy when the Virtual Server Agent is installed.
System Requirements for Virtual Server Agent with VMware (commvault.com)
The proxy needs to get to port 443 on the proxy and then 902 for the ESX hosts.
Thanks @Aplynx for the reply.
So when installing Commvault on the target ‘proxy’ windows VM, I need to select only ‘Virtual Server’ feature.
When doing so, it immediately also checks the VSS Provider and VSS Hardware Provider packages.
When the setup is complete, I see in the Commcell console logs/events that the installation was successfull and that also the FileSystem+FileSystemCore packages have been deployed.
I find it a bit strange, that this is not whether automatically checked while I selected ‘Virtual Server’, or that the online documentation does not explicitely mention this.
Have you noticed this also ?
Thanks @Aplynx for the reply.
So when installing Commvault on the target ‘proxy’ windows VM, I need to select only ‘Virtual Server’ feature.
When doing so, it immediately also checks the VSS Provider and VSS Hardware Provider packages.
When the setup is complete, I see in the Commcell console logs/events that the installation was successfull and that also the FileSystem+FileSystemCore packages have been deployed.
I find it a bit strange, that this is not whether automatically checked while I selected ‘Virtual Server’, or that the online documentation does not explicitely mention this.
Have you noticed this also ?
Hey @Laurent - FS agent is a pre-requisite to VSA install - so it gets picked and deployed in ‘restore only’ mode automatically. I’m a little rusty but I think Media Agent is also picked now, as it is required for live browse and intellisnap (I think it even auto-installs if required for older deployments).
There are some great VSA videos here which you may find helpful as well:
http://kb.commvault.com/?q=virtual&Has_Video=Yes
The proxy needs to get to port 443 on the vcenter and then 902 for the ESX hosts.
The proxy needs to get to port 443 on the vcenter and then 902 for the ESX hosts.
There is also a video for that
Hey @Laurent - FS agent is a pre-requisite to VSA install - so it gets picked and deployed in ‘restore only’ mode automatically. I’m a little rusty but I think Media Agent is also picked now, as it is required for live browse and intellisnap (I think it even auto-installs if required for older deployments).
There are some great VSA videos here which you may find helpful as well:
http://kb.commvault.com/?q=virtual&Has_Video=Yes
Thanks for the videos links. Unfortunately I found none detailing a windows proxy setup.
In training courses or documentation, situations are always simple
I followed the recommendation to deploy VSA on my to-be windows proxy VM, but MA was not deployed.
I tried then to perform a browse of the content of the VM to restore guest files, and the result is not what I expected :
- There are no option before browsing to force the Proxy for browsing, so the one that gets used is very WAN-distant from the MA+Proxy infrastructure we wish to restore, resulting in high WAN bandwidth usage on that location and “remote browsing”.. (even killing the Persistent Recovery job does not solve my issue, as a new Persistent Recovery job is automatically initiated to continue the task…
- When the WAN has been overloaded enough to allow me to browse the content of the VM, I can select the content I wish to restore, like c:\CVsources. Next, ‘Recover all selected’, and in the next screen I can select my windows client that has the Proxy role on it (FS agent is already installed), browse it OK. I then click the ‘Advanced’ button where I expect to explicitly select the MA + Proxy to use in the ‘Data Path’ tab. My linux MA is listed and I select it. As the source VM is a windows VM, I have to uncheck the ‘Use File Recovery Enabler for Linux’ to be able to access the ‘Use Proxy’ proxy list, but I don’t see my Windows server where I deployed the VSA role.
In the video about restorations, at the caveats parts, it has been mentionned that MA role had to be installed to perform a file-level restore from a VSA backup to my agent..
So now, I will deploy MA role on this windows VM that has the VSA role and I expect to act as a proxy for FS restore only.
So far, it looks like it’s quite painful to have a Linux MA+VSA protecting windows VMS, and have file-level recovery capacity of windows OS.. Much more than having Windows MA+VSA protecting the same+linux VMs, as the FREL is a package/embedded (if you allow me to express it this way)..
@Laurent , that is correct. With Live Browse, you are directly reading the file system structure, and Windows cannot read a Linux ext format. Installing the FREL allows you to browse that data live and then restore it. Normally, during a restore the Media agent is simply reading chunk files (in a Commvault format) and restoring the data. The Media Agent does not have to be able to actually open each file, use it, etc. It’s agnostic to what the file actually is because it’s just reading a chunk file on a library somewhere.
Update : I added the MA role to the existing roles of my to-be Windows Proxy VM.
Now, I am able to select this VM as the proxy in the advanced options of the browse/restore.
But when I initiate the restore, it starts then goes pending..
‘Error while reading pipeline buffer from MediaAgent linuxMA
Source : windowsProxyVM Process: VMWareSnapRestore’
Both MA and ProxyVM can ping each other, ip@ or FQDN.
I’m asking the security teams if anything would intercept/filter ports, but while they start working on this, maybe someone here has a better idea of what to check/change
BTW, thanks for all the assistance and feedback this community provides !
@Laurent any specific errors in the logs for that process?
@Mike Struening well, I tried to look for some but only found those in VMWareSnapRestore.log of the windowsProxyVM :
7316 4b8 04/06 16:46:59 3586938 CVArchive::FwdRstMsg() - Error Forwarding FSR_SNAP_SRC_PATH Message to FSRestoreHead: e80072745] 70x80072745:{CCvNetwork::SendXDRMessageInternal(5173)/linuxMA/linuxMA.europe.mycompany.group/SockIP(IPofLinuxMA)/IPofLinuxMA:60054/0 cvd(194267:54426700)} + {CSessionConnectionSocket::SendBytes(471)} + {CQiSocket::SendWithTimeOut(550)/W32.10053.(An established connection was aborted by the software in your host machine. (10053))}]
7316 1a70 04/06 16:46:59 3586938 CVArchive::ReadBuffer() - PL_PERF_COUNTERS (2, 343, 5290041)
7316 18cc 04/06 16:46:59 3586938 SdtNetLink::recvMsgPacket() - Received SDT_LINK_FIN packet.
7316 1cf8 04/06 16:46:59 3586938 FclRestore::RestoreSendHighWaterMark() - Sending High Water Mark
7316 4b8 04/06 16:46:59 3586938 FclRestore::sendMsgToRestoreHead() - Failed to forward restore message 402653311 FSR_SNAP_SRC_PATH
7316 4b8 04/06 16:46:59 3586938 VMWareSnapRestoreLib::OnMsgSnapSrcPath(143) - Failed to forward snap source path message to fsrestorehead, next retry will happen after 10 seconds. This is 1 of 18 attempts
7316 18cc 04/06 16:46:59 3586938 Closing all sockets.
7316 18cc 04/06 16:46:59 3586938 SdtNetLink::recvMsgPacket() - The other side has closed the network connection gracefully
7316 18cc 04/06 16:46:59 3586938 SdtBase::setLastErr: Setting last err s92]aThe other side has closed the network connection gracefully] RCId 0]
I guess that there’s something enormous mistake I made or forgot to do before my eyes but can’t find it, even taking a big break
I’ll get some additional eyes on this, see what we can turn out. Initial suspicion is (as you said) something on the network, perhaps a port not opened between one of the many moving parts, though I don’t want to ‘guess’
Spoke to a few people here who suggested opening a case with support. The possible causes are too numerous.
Once you do, update me with the case number so I can track it.
Thanks Mike, I understand. Will do tomorrow as it’s almost the end of my working day now.
My main concern is that I am not able to force the initial Persistent recovery job to be executed by my brand new WindowsProxyVM. Then as it’s executed by another member of my Commcell, what happens later can be related to that.
Ticket 210407-212 open for this case.
BTW, VMs are using vmxnet3 NICs, not E1000.
Great! I’ll monitor the incident updates.
Lost a day waiting to be called back.
Zoom to be performed tomorrow
Issue solved with the support.
- I had defined both linuxMA and WindowsProxy as Proxies of my VMWare client (to ensure no other MA/Proxy would be used to process any VM for this location)
- I also had defined both linuxMA and WindowsProxy as Proxies of each of my VM subclients from this VMWare client.
- With the support, we removed the linuxMA in the Proxy list of each windows VM subclient of this VMWare subclient. They also told me to align proxy setting with the VM OS : mention linux only proxy for a linux VM, or windows proxy for a windows VM.
- Ran a restore, it went fine. Ran backups, it went fine.
Thanks Support team (Ruchi Singh) and the community!
Awesome, thanks for sharing back here @Laurent !!