This post is more than 5 years old
6 Posts
0
4911
Clarify NetWorker VADP Proxy Host Requirements?
I am trying to prepare for VADP backups and need clarification on the VADP Proxy Server requirments listed in the NetWorker VMware Integration Guide. I am planning on using a physical storage node as the VADP Proxy.
NetWorker VMware Integration Guide states:
-
The VADP proxy server needs to be connected to the vCenter Server managing the ESX Server cluster. It also needs to be connected to the ESX Server system.
-
What does "needs to be connected to the vCenter Server" mean?
- What does "needs to be connected to the ESX Server system" mean?
-
Virtualization is configured within the NMC. Does that fill these requirements?
-
-
-
The VADP proxy host must have access to all LUNs on the ESX server that is hosting the virtual machines
-
I have multiple ESX servers (ESXi 4.1) that boot-from-SAN, all sharing multiple CLARiiON LUNs. Each ESX server has its own Unisphere storage group and all ESX shared LUNs are in each ESX server storage group.
-
Does this mean I have to add all the shared ESX LUNs to a storage group with the VADP Proxy Server?
-
-
Thanks.
Joe
evilensky
74 Posts
0
August 14th, 2011 20:00
Responding inline:
evilensky
74 Posts
1
August 14th, 2011 20:00
And to add my own $0.02: We're having great performance using a Virtual proxy and the HOTADD transport mode, but we are NFS and it makes more sense than the NBD mode.
JWeland
6 Posts
0
August 15th, 2011 12:00
Isn't there something inherently wrong and dangerous about giving a physical Windows host access to the shared ESX LUNs?
evilensky
74 Posts
0
August 15th, 2011 15:00
I too would like some more documentation on the behavior; when the windows SAN proxy host sees a disk, is it an unidentified device that only the VADP libraries can read from, or does Windows recognize it as a general purpose non-native file system?
But I don't think this classifies this enterprise-tested feature as "inherently" wrong.
Maybe *nix folks are just more used to a variety of filesystems....