-
- Novice
- Posts: 6
- Liked: never
- Joined: Jul 20, 2017 10:24 pm
- Full Name: Chris Kuperstein
- Contact:
Feature Request - Specify NFC Target IP
We have a front-facing vCenter installation that has hosts added via IP and not through FQDNs and DNS A records. Our management and provisioning networks connected on these hosts are not segregated on different vmware TCP/IP stacks so by default when a restore job attempts to transfer to the first IP available in the default TCP/IP routing stack.
For example:
Host A - (192.x.x.1)
Nic1 - 192.x network 1 GbE (management) Default TCP/IP Stack
Nic2 - 172.x network 10 GbE (management, vmotion, provisioning) Default TCP/IP Stack
When starting the restore job, it will take the first IP in the stack and use that as the resolved target for the NFC datastore transfer over port 902. since that vnic is not tagged for provisioning, ESX firewall/routing fails and doesn't return a protocol response on that interface, so veeam times out and the restore job fails when opening the NFC tunnel to the datastore on the host.
We also use Quest RR on the other half of our DR setup. We can plug in what IP we want to use for backup traffic, so we don't really have to worry about the vCenter SOAP Web API to provide all the information.
The current "workaround" is to migrate all your VMs off of a host, Create some DNS A records for it, point it to your DNS servers and change the hostname to reflect those records and reconfigure your entire networking setup on the host so you can re-add it to vCenter. ONLY THEN can you go to your Veeam VBR and add an entry to the hosts file that redirects the hostname/FQDN to the desired IP, in this case the 172.xx 10 GbE address.
This isn't very helpful for us since the vCenter we are using for this is public-facing. It makes it incredibly difficult having to reconfigure all of our hosts just so that Veeam will play nice with it and behave as intended.
For example:
Host A - (192.x.x.1)
Nic1 - 192.x network 1 GbE (management) Default TCP/IP Stack
Nic2 - 172.x network 10 GbE (management, vmotion, provisioning) Default TCP/IP Stack
When starting the restore job, it will take the first IP in the stack and use that as the resolved target for the NFC datastore transfer over port 902. since that vnic is not tagged for provisioning, ESX firewall/routing fails and doesn't return a protocol response on that interface, so veeam times out and the restore job fails when opening the NFC tunnel to the datastore on the host.
We also use Quest RR on the other half of our DR setup. We can plug in what IP we want to use for backup traffic, so we don't really have to worry about the vCenter SOAP Web API to provide all the information.
The current "workaround" is to migrate all your VMs off of a host, Create some DNS A records for it, point it to your DNS servers and change the hostname to reflect those records and reconfigure your entire networking setup on the host so you can re-add it to vCenter. ONLY THEN can you go to your Veeam VBR and add an entry to the hosts file that redirects the hostname/FQDN to the desired IP, in this case the 172.xx 10 GbE address.
This isn't very helpful for us since the vCenter we are using for this is public-facing. It makes it incredibly difficult having to reconfigure all of our hosts just so that Veeam will play nice with it and behave as intended.
-
- VP, Product Management
- Posts: 6749
- Liked: 1408 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: Feature Request - Specify NFC Target IP
Hi Chris, I understand you point from technical side.
Veeam always uses the ESXi host entry within vcenter to get an IP address or DNS FQDN to connect to the ESXi host for NFC sessions.
When the ESXi host was added by IP, we use the IP. If the hosts where added by FQDN, we use DNS to identify the IP address to work with it. DNS system can be used to point Veeam to the right Management IP.
As this approach is not a good way to point Veeam to the correct interface, there is a running feature request that add our preferred network entry selection process into the esxi host IP selection. DNS or vcenter give ESXi management IP. We connect to the IP address and read out the list of management IPs and use the one that is in the preferred network rule.
Please let me add that VMware requirement is anyway to allow DNS reslution for ESXi hosts. https://pubs.vmware.com/vsphere-51/inde ... EA8B7.html
Overall not ideal in your situation, but we will take your feedback in considerations at the above feature request. Thank you.
Veeam always uses the ESXi host entry within vcenter to get an IP address or DNS FQDN to connect to the ESXi host for NFC sessions.
When the ESXi host was added by IP, we use the IP. If the hosts where added by FQDN, we use DNS to identify the IP address to work with it. DNS system can be used to point Veeam to the right Management IP.
As this approach is not a good way to point Veeam to the correct interface, there is a running feature request that add our preferred network entry selection process into the esxi host IP selection. DNS or vcenter give ESXi management IP. We connect to the IP address and read out the list of management IPs and use the one that is in the preferred network rule.
Please let me add that VMware requirement is anyway to allow DNS reslution for ESXi hosts. https://pubs.vmware.com/vsphere-51/inde ... EA8B7.html
Overall not ideal in your situation, but we will take your feedback in considerations at the above feature request. Thank you.
-
- Novice
- Posts: 6
- Liked: never
- Joined: Jul 20, 2017 10:24 pm
- Full Name: Chris Kuperstein
- Contact:
Re: Feature Request - Specify NFC Target IP
The issue is we can't select the proper management IP for initiating the NFC connection.
ESX-Host1:
192.x.x.1 (1GbE)
172.x.x.1 (10GbE)
The host is added to vCenter by the 192.x address, but all of our production traffic needs to go across the 172.x network. Veeam grabs the 192.x IP, but doesn't let me specify the correct 172.x address.
ESX-Host1:
192.x.x.1 (1GbE)
172.x.x.1 (10GbE)
The host is added to vCenter by the 192.x address, but all of our production traffic needs to go across the 172.x network. Veeam grabs the 192.x IP, but doesn't let me specify the correct 172.x address.
-
- VP, Product Management
- Posts: 6749
- Liked: 1408 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: Feature Request - Specify NFC Target IP
I see your point here. Thank you for this input.
At the moment the only workaround is to add the Hosts by name and use name resolution within the Veeam Proxy and Backup Server to point to the 172.x network.
At the moment the only workaround is to add the Hosts by name and use name resolution within the Veeam Proxy and Backup Server to point to the 172.x network.
-
- Service Provider
- Posts: 111
- Liked: 21 times
- Joined: Dec 22, 2011 9:12 am
- Full Name: Marcel
- Location: Lucerne, Switzerland
- Contact:
Re: Feature Request - Specify NFC Target IP
Please consider this as a feature request and +1.
We have our vCenter and Hosts in Network A. Our Veeam server/proxy is in network B.
Every ESX Hosts has an additional management interface and IP in network B.
The idea was to bypass the Firewall/Router for Veeam traffic, but yeah....
We have our vCenter and Hosts in Network A. Our Veeam server/proxy is in network B.
Every ESX Hosts has an additional management interface and IP in network B.
The idea was to bypass the Firewall/Router for Veeam traffic, but yeah....
-
- VP, Product Management
- Posts: 6749
- Liked: 1408 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: Feature Request - Specify NFC Target IP
Marcel, if you had added the Hosts by name or FQDN to VMware, you can create for example host or FQDN entries in the hosts file of the Veeam Servers for the other interfaces... that way the traffic goes to the correct interfaces.
Who is online
Users browsing this forum: No registered users and 138 guests