Use VADP_VM_NAME=HOST_XYZ in application info in settings of virtual client to use name of the vm (case sensitive) instead of hostname/fqdn for VADP backup.
We have already tried that, but the problem is that we have to assign a "client name" for the resource and that name will be checked against DNS. E.g. in Virtual Center we have a machine called "Foo" Which is not defined in any DNS-servers. This gives us "create failed: Name foo is not a valid hostname". So from what I can see; to be able to get the client defined in Networker in the first place it needs a valid hostname. As we have a multitude of different clients and networks this can be a real challenge to us. And to be clear, I really do understand why this is important for "thick" client backups. But it really doesn't make sense in a virtual environment, where those clients are given to us from Virtual Center...
Another thread resurrection, but has there been any progress in this regard? I too have a need to backup VMs that may be powered off or behind firewalls that will not allow me to resolve names.
I'm using the legacy VADP method, not the VBA (VMware Backup Appliance).
I already use hosts file for clients in the DMZ. This is cumbersome at best, unwieldy most of the time and error prone sometimes. To maintain a hosts file across several storage nodes doesn't quite feel like it's soon the year 2015.
Also, it doesn't address the issue of powered off VMs, they still need to answer ICMP requests I've found. I'd rather not concoct some elaborate scheme with dummy IP addresses.
otmanix
52 Posts
1
February 13th, 2012 00:00
Use VADP_VM_NAME=HOST_XYZ in application info in settings of virtual client to use name of the vm (case sensitive) instead of hostname/fqdn for VADP backup.
Kind regards,
Otmanix
otmanix
52 Posts
0
February 13th, 2012 01:00
You're right, the client definition itself is also checked by DNS or /etc/hosts...
Hmm, I don't see a solution for your problem then. I would also be interested if there's a solution without name resolution
runerh
2 Posts
0
February 13th, 2012 01:00
We have already tried that, but the problem is that we have to assign a "client name" for the resource and that name will be checked against DNS. E.g. in Virtual Center we have a machine called "Foo" Which is not defined in any DNS-servers. This gives us "create failed: Name foo is not a valid hostname". So from what I can see; to be able to get the client defined in Networker in the first place it needs a valid hostname. As we have a multitude of different clients and networks this can be a real challenge to us. And to be clear, I really do understand why this is important for "thick" client backups. But it really doesn't make sense in a virtual environment, where those clients are given to us from Virtual Center...
seb_pythoud
3 Posts
0
February 21st, 2014 00:00
Hello RuneRH.
I'm working in similar environnement (hosting center) and I totally agree that for VM backup, DNS resolution is totally useless.
Did you find any solution to backup VM wich are unreachable from LAN or DNS perspective ?
Thank you.
Seb
sechm
1 Rookie
•
79 Posts
0
December 4th, 2014 03:00
Another thread resurrection, but has there been any progress in this regard? I too have a need to backup VMs that may be powered off or behind firewalls that will not allow me to resolve names.
I'm using the legacy VADP method, not the VBA (VMware Backup Appliance).
Running NetWorker 8.1.1.9.
ble1
4 Operator
•
14.4K Posts
0
December 4th, 2014 04:00
You can use hosts table.
ble1
4 Operator
•
14.4K Posts
0
December 4th, 2014 04:00
That's why for DMZ I always have dedicated backup solution
offline VMs is separate topic and there is thread for it already.
sechm
1 Rookie
•
79 Posts
0
December 4th, 2014 04:00
I already use hosts file for clients in the DMZ. This is cumbersome at best, unwieldy most of the time and error prone sometimes. To maintain a hosts file across several storage nodes doesn't quite feel like it's soon the year 2015.
Also, it doesn't address the issue of powered off VMs, they still need to answer ICMP requests I've found. I'd rather not concoct some elaborate scheme with dummy IP addresses.