[Installation] Connect to Hyper-V cluster from different dom

[lukaszh]

I'm trying to set up environment where all Hyper-V hosts are in dedicated and separated domain. I'm using VMM.
1. When I try to add my Hyper-V cluster to Veeam Backup, it tries to connect to servers using short names: SERVERNAME, instead of SERVERNAME.domain.local
Veeam is in another domain so this way it's unable to properly resolve names.

2. My second attempt was to user VMM. I can connect to my VMM server and gather all data from it (it's in the same domain as Veeam server) but Veeam then tries to connect to my Hyper-V hosts (correctly with SERVERNAME.domain.local) but using the same account which I'm using to VMM so it's user without permission from different domain.

I would like to not create any trust relationships.

Is there any other way to accomplish this configuration?

[Mike Resseler]

Lukasz,

How did you add the cluster to Veeam Backup? Did you use the FQDN from the cluster (cluster.domain.local)?

Second, when you query the hyper-v hosts from the VBR server, are you getting the short names or the FQDN back?

[lukaszh]

Hi,

Everywhere I'm using FQDN names.
NETBIOS is disabled on all interfaces in the network.

I found a workaround by adding IP NETBIOS name pairs into my host file. This way adding Hyper-V cluster works.

[Mike Resseler]

Lukasz,

Thanks for letting us know. Good that you have found a workaround. Is that the host file on your B&R server?

Mike

[lukaszh]

Yes, it's hosts file on B&R server.

[Ctek]

Hi,

Thread revival, I just hit the same issue for a specific scenario, about a cross-domain replication.

Both environments have the proper firewalling, DNS conditional forwarding set, etc.

I have a VBR server in domain 1, named domain1.local, I want to replicate VMs in cluster.domain2.local. When I add the cluster configuration in veeam, it recognize the cluster and resolves it, but when on the next page it wants to deploy the agents, it does not resolve each hosts because it does not use the FQDN, just the short hostname which goes nowhere.

I was able to mitigate this temporarily by adding the servers in the domain1.local DNS server zone, and it works perfectly now, but I feel dirty by doing this.

Is there a reason why Veeam does not use FQDN across all cluster objects/nodes when it's set to use it when you specifically use it when adding the cluster in the first place?

Dan

[Jan1987]

Hello

I have the same problem and a Case open: 03027803

The problem seems to be that the cluster nodes are read only as a shortname and when the FailOver Cluster is in another Network/Domain. i think Veeam use the Get-ClusterNode command which only outputs the shortname. All Other Computers or Server works great with the AD scan.

Add a DNS entry to the AD from VBR Server is not a nice solution. the advantage of the AD query is that every new node is automatically detected and the agent can be installed.

is a solution planned for this problem?

Best Regards,
Jan Grimm

[wolfgang]

I have the same problem in our environment. I selected the Cluster object from another Domain and Veeam is not resolving the IP-Addresses of the Cluster-Members.
I'd be happy about any fix for that!

Regards
Wolfgang

[Mike Resseler]

Hi Wolfgang,

The previous poster had an issue with his DNS and needed to add CNAME's to the DNS server table. If this is not your case, then please create a support call also and post the case ID (and eventual outcome) here also

Thanks
Mike

[wolfgang]

Hi Mike,
I have not yet created a call because I thought that maybe the poster could tell me what was the solution in his case.

For me it sounds like the same problem:
Veeam server is in domain A, the servers and the cluster in domain B.
The cluster-object from domain B is added trough Active-Directory -> FQDN of the cluster is shown in the computers-list.
When rescanning the group, the resolval of the hostnames fails, because they are listed in their short variant which the veeam Server tries to resolve with his DNS in his own domain.
This will fail, because the Servers don't exist in domain A, where the veeam Server is located.

Sure I could add a CNAME in our DNS. But like the poster before me said I think, a better solution would be to also use the FQDN for Cluster-members because adding CNAME's wouldn't work for newly added servers in the AD automatically.

Regards
Wolfgang

[Mike Resseler]

Wolfgang,

I will talk to the DEV's to see what their thoughts are. In the meantime, I'm afraid the CNAME's is the only solution for now. Can you try to see if it works in your environment? It might also be a different issue and then we need to involve support

Cheers
Mike

[wolfgang]

Hi Mike,

adding a CNAME works for me, but it is really not a nice solution.
I think mechanism how veeam is adding the cluster nodes (while scanning) to the list should be tweaked. If they would be added with FQDN the problem wouldn't exist.

Regards
Wolfgang

[crgitsg]

Same issue for me.

Support advised that since the info is coming from Hyper-V this is not quite a Veeam issue. Case 04077900

I would argue that ultimately it would be better if dev used FQDNs.

For now I will modify the host file.

[crgitsg]

You can work around this by adding both domains to searched suffixes in the NIC config.

[dasfliege]

Is there also a workaround for the initial problem with VMM? We are not able to add a VMM server which manages Hyper-V hosts that are not in the same domain as the VMM.
B&R and VMM are in the same domain and connnection to VMM is working, but (some) of the the VMM managed Hyper-V hosts and clusters are in a different domain and therefore would need different connection credentials. Unfortunately the "add SCVMM" wizard only accepts one credential to connect to VMM and fails afterwards, when it tries to connect to the VMM managed hosts with the same credentials.

[foggy]

Could you please confirm that NOT ALL of the Hyper-V hosts under VMM are in a different domain? Provided there is at least one host from the same domain, SCVMM should be added fine and then you can specify the credentials for those from other domains explicitly (right-click the host > Properties).

[dasfliege]

Well. At the moment there are only hosts from another domain in the VMM, as it is a new VMM installation where we just migrated the DMZ hosts to. We'll migrate other hosts to it in the near future, so we may have to wait until this happened to be able to add the VMM. Would be nice if it would be possible to assign different credentials to different hosts or hostgroups in the wizard. If that isn't considered as a useful addition, it may would be better to just don't try to connect to the hosts during the wizard and instead just add the VMM instance.

[foggy]

That does sound reasonable - thanks for the feedback.

[rweis]

I've run across this problem in a big way - over 3000 VMs split between 2 domains running on Hyper-V. VBR is in Domain A, trying to add clusters/hosts in Domain B for replication set up. The Cluster is added using the FQDN but the hosts can't be connected to because the short names won't resolve. Adding CNAMES records is not a viable solution - that is a LOT of manual work, and any new hosts or clusters would require manually updating DNS. We tried adding reverse lookup zones, but they won't populate PTR records for the other domain. Under consideration is using Dnscmd recordadd http://technet.microsoft.com/en-us/libr ... px#BKMK_14, but again, this requires constant updating whenever clusters are created or hosts added to clusters, in two domains. Yes, creating trust between the domains would help greatly, but this isn't possible for the time being.

Is there a way to have the cluster return the FQDN of the nodes with a change to the Hyper-V/Cluster configuration?

The best solution would be to either have Veeam return the Hyper-V cluster node FQDN. Is there any way to do this?

[foggy]

Hi Randy, NetBIOS resolution is a requirement for Hyper-V environments.

[rweis]

If there are two untrusted domains, as in the description above, Veeam can resolve the NETBIOS name and make the connection to Hyper-V cluster hosts in the other domain?

[foggy]

Provided you've explicitly specified the credentials for the hosts, it should be able to connect.