Host-based backup of Microsoft Hyper-V VMs.
Post Reply
Norsak
Novice
Posts: 3
Liked: never
Joined: Jul 26, 2016 1:57 pm
Full Name: Norsak
Contact:

Issues migrating to Dedicated Backup Network

Post by Norsak »

I wish to offload my Hyper-V backups to a dedicated network/switch.

Here is a simplified diagram of my network:

Image

- Backups where originally talking to HV1 using the LAN IP 192.168.10.9
- Then I added the dedicated backup network
- I added (in veeam) a new Hyper-V Server with IP 10.66.66.10
- I created A replacement backup job targeting VMs on IP 10.66.66.10

Every thing seemed fine, except that I still saw heavy load on the 192.168.10.x network when backups where targeting the Hyper-V host on 10.66.66.10

For trouble-shooting purposes I disconnected the 192.168.10.35 interface on the Veeam server.
This creates the following error when re-scanning the 10.66.66.10 host:
Image
So veeam isn't willing to talk to HV1 using only the 10.66.66.10 interface.
Maybe this is because whatever veeam service/agent got installed on HV1, was installed using 192.168.10.9

How do I fix this? How do I migrate all backup traffic to the 10.66.66.10 interface?
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Issues migrating to Dedicated Backup Network

Post by foggy »

You seem to do everything correct. Might be a routing issue, I recommend contacting support for verification.
nefes
Veeam Software
Posts: 643
Liked: 162 times
Joined: Dec 10, 2012 8:44 am
Full Name: Nikita Efes
Contact:

Re: Issues migrating to Dedicated Backup Network

Post by nefes »

Could you please check in name resolution of HV1 on backup server? It should be resolved into 10.66.66.10, not 192.168.10.9.
Norsak
Novice
Posts: 3
Liked: never
Joined: Jul 26, 2016 1:57 pm
Full Name: Norsak
Contact:

Re: Issues migrating to Dedicated Backup Network

Post by Norsak »

Could you please check in name resolution of HV1 on backup server? It should be resolved into 10.66.66.10, not 192.168.10.9
That's actually good advice.
I updated the hosts files on both BACKUP and HV1 so that they resolve each other's hostname and FQDN on a 10.66.66.x IP address.

After restarting the BACKUP server this allowed for jobs to succeed.
----------------------------------------------------------------------------------

But there are still issues.
If I disable the 192.168.10.35 interface on the BACKUP server, then I can successfully run most jobs. Since the ONLY way it can talk to HV! is over the 10.66.66.x network, I do not get any traffic issues on the 192.168.10.x network.
But if I leave the 192.168.10.35 interface enabled on the BACKUP server, then I can see traffic issues on the 192.168.10.x network when i run backup jobs.

Because of these issues, my current strategy is to remove the 192.168.10.35 interface, to enforce complete physical isolation. Then give the 10.66.66.x network internet access.
It's not perfect (BACKUP would not have access to a domain controller), but it's where I think this is headed.
nefes
Veeam Software
Posts: 643
Liked: 162 times
Joined: Dec 10, 2012 8:44 am
Full Name: Nikita Efes
Contact:

Re: Issues migrating to Dedicated Backup Network

Post by nefes »

Norsak wrote: But if I leave the 192.168.10.35 interface enabled on the BACKUP server, then I can see traffic issues on the 192.168.10.x network when i run backup jobs.

Because of these issues, my current strategy is to remove the 192.168.10.35 interface, to enforce complete physical isolation. Then give the 10.66.66.x network internet access.
It's not perfect (BACKUP would not have access to a domain controller), but it's where I think this is headed.
The question is, what traffic is it.
Could you please describe your configuration a little bit deeper:
1. What repository and where do you use? Traffic between host and repository can go through both networks, so you may want to utilize Preferred Networks feature to make it go through backup network (if all components have access to it).
2. Do you use guest processing? If so, and guests are connected to production network only, guest interaction traffic will go through production network anyway. However this traffic should not be intensive, so it is better to stay with it because of benefits from VSS and other guest processing bonuses.
You may also want to utilize Guest Interaction proxy and put it on some internal network of HV1. It will require additional configuration, but that way interaction will go through non-production networks.
Post Reply

Who is online

Users browsing this forum: No registered users and 18 guests