03-31-2015 06:41 AM
Hello! I have a problem with the list in the host properties-->Clients menu. I am not seeing my VMs there and I can't tell easily without resorting to a report what Netbackup version the VM is running. Is there a work around apart from generating a report with OpsCenter? I would really like to see ALL my clients in that list...
Thanks!
Solved! Go to Solution.
03-31-2015 08:40 AM
Host Properties client list only gets updated when the client is added in the policy type as
MS-Windows/Standard/NDMP/MS-Exchange/Lotus Notes, etc.
Where NetBackup client is installed on the clients. From Host Properties Client list we can change/set the parameters like timeouts/Logging/Firewall/Servers(Media Server/Additional Server).
In cases where server is not reachable or NDMP client it will show status as "Cannot connect on socket".
03-31-2015 07:07 AM
They clients are added to host properties when they are added to a policy. A VM from a query based policy will most likely not show here as they are technically no in the policy, but from the resulting query. Also, a VM client does not necessarily have a NetBackup client installed.
03-31-2015 07:22 AM
Well, that's not very useful. There should be a way to see the VMs in that list... Maybe Netbackup should generate the list everytime you access it? Or maybe a button to refresh or generate it again?
03-31-2015 07:25 AM
Create a policy with no backup selection and no schedules and put the VM hosts in that policy
The VM's will then show up in host properties.
03-31-2015 07:32 AM
Also, I manually select my VMs to add to my policy, if that changes anything.
03-31-2015 08:40 AM
Host Properties client list only gets updated when the client is added in the policy type as
MS-Windows/Standard/NDMP/MS-Exchange/Lotus Notes, etc.
Where NetBackup client is installed on the clients. From Host Properties Client list we can change/set the parameters like timeouts/Logging/Firewall/Servers(Media Server/Additional Server).
In cases where server is not reachable or NDMP client it will show status as "Cannot connect on socket".
03-31-2015 08:41 AM
No it does not.
Consider this: VMware clients can be agent less, would it be a good idea to list them under host properties then ?
03-31-2015 11:40 AM
I just tested it and it didn't work. I created a new policy (VMWare type) and added a couple of VMs. Even after a restart of my console they aren't showing up in host properties. Some command or button to regenerate the list would fix the problem.
03-31-2015 11:46 AM
Maybe you could create a windows or a standard policy with those clients in it/them, and have the policy deactivated...
04-09-2015 07:12 AM
If its a VMWare of HyperV policy, the backup clients usually don't have the client software installed. As such, those backup clients won't appear in the Clients subsection of Host Properties.
04-09-2015 07:17 AM
Whatever the reason, what I'm saying is that it should appear there, to have a global list to reference. Also, ontherocks' post is not a solution, just saying... Just close this thread without solution as there doesn't seem to be a workaround or a way to have it the way I would like.
Thanks.
04-09-2015 03:51 PM
When you suggest that VM names should show up in the list of clients - it's not that simple... what if the VMware policy client selection list is based upon VM GUID, or VM display name - and not VM host name - and even if it was based on VM hostname, sometimes the VM hostname does not match the DNS name for normal 'NetBackup Client' comms - let alone matching the 'client_name' within NetBackup Client within the guest OS.
And what if you use VIPs? You want NetBackup to continually keep track of populating a list of 'potential' clients - as and when VMs are created/renamed/re-registered etc? Even if the VM does not actually have NetBackup Client installed within the guest OS? Doesn't seem practical to me - for any backup application.
mnolan's post re having an de-activated policy containing the DNS (or hosts file) names or 'NetBackup Client' names of the VMs is the way that I've always done it in sites without a good 'administrative connect' between NetBackup Client name and VM display name or VM host name.
What I've always found is that in inherently untidy (poorly managed) sites, a VM name does not always easily tie up with a NetBackup Client name - in fact, in my experience, it is actually quite dificult to get VMware admins to implement 'day to day management' best practices of keeping the two names aligned. Thus, the NetBackup Admin console does not do this for you/us/anyone.
In the past, we, as backup admins, enforced a policy of ensuring that VM display name always matched the NetBackup Client name by refusing to add a VM to backup policies unless the names did match. It seems brutal, but it's not, it forces VM admins to be tidy. No name match = no backup. No exceptions tolerated. Ever. And we wrote custom scripts to report on any deviation of this policy. And so, we were thus able to have a de-activated backup policy containing a list of 'correct' names of VMs.
(...think ahead, when the pressure is on to do a file restore... big headaches without a name match).
VM admins don't necessarily care what backup admins want. You force them to care, by refusing to do what they want, unless they do what you want.
04-09-2015 04:17 PM
Some other tips re enforcing VM display names...
- must start with an alpha character (i.e. cannot start with a digit or ',' or '-', or '_')
- must not contain spaces
- must not contain any non-alpha-numeric character plus '.' and/or '-' and/or '_' (i.e. no other punctuation characters)
- and probably best - for visual purposes to enforce a 'casing' (uppercase/lowercase) rule of some sort - whatever best suits the site(s) / domain(s).
- and apply the same naming 'rule set' across the board, across the entire estate - i.e. to DNS names, host file entries, VM display names, actual server 'hostname's (and thus VM 'hostname') and of course to the NetBackup Client 'client_name'. Anything less than this is messy, and confusing - and confusion is quite typically a precursor to mistakes - and some mistakes lead to down time - and the same mistake, and/or other mistakes, can lead to data-loss.
04-10-2015 06:27 AM
Thanks for the answers, sdo. The problem is that the team we have for the VM stuff is basically one guy and he can be a pain to deal with sometimes. Thanks everyone for the answers, even though it's not what I wanted to hear, hehe.