I've configured an Application Group and a VirtualLab (using the Basic Network Settings).
The SureBackupJob starts the VM and the heartbeattest is ok, but the ping-test always fails.
If I connect to the restored vm using the console I can verify that all the services start and that the vm can ping itself, but the ping test of the SureBackupJob fails.
The configuration of my virtual-lab looks like this:
Lab name: Virtual Lab LRA-DEG auf ESX4
ESX name: esx4
Datastore: Vol020_NAS1
Appliance:
Name: Virtual_Lab_LRA-DEG_auf_ESX4
Pool name: Virtual Lab LRA-DEG auf ESX4
Folder name: Virtual Lab LRA-DEG auf ESX4
IP: <Obtain automatically>
DNS: <Obtain automatically> (10.32.30.182)
Network configuration type: Basic
Network options:
Isolated network: Virtual Lab LRA-DEG auf ESX4 LAN
Masquerade IP: 10.255.0.0
Appliance IP: 10.32.1.1
DHCP: enabled
Network mapping:
LAN --> Virtual Lab LRA-DEG auf ESX4 LAN
The VM I try to restore has the following ip settings:
Physikalische Adresse . . . . . . : 00-50-56-9C-32-4F
DHCP aktiviert . . . . . . . . . : Nein
IP-Adresse. . . . . . . . . . . . : 10.32.30.16
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 10.32.30.195
DNS-Server . . . . . . . . . . . : 10.32.30.4
10.32.30.17
10.32.30.7
I think there is a routing problem. I tried to check the ipsettings on the virtual appliance, but I don't no the necessary credentials.
How can I troubleshoot this problem ?
Greetings
Martin
-
- Enthusiast
- Posts: 35
- Liked: never
- Joined: Jun 25, 2009 6:55 pm
- Full Name: Martin Schedlbauer
- Contact:
-
- Enthusiast
- Posts: 35
- Liked: never
- Joined: Jun 25, 2009 6:55 pm
- Full Name: Martin Schedlbauer
- Contact:
Re: SureBackup problem
It works when I use the advanced configuration with the following settings:
Lab name: Virtual Lab LRA-DEG auf esx4
ESX name: esx4.lra-deg.local
Datastore: Vol020_NAS1
Appliance:
Name: Virtual_Lab_LRA-DEG_auf_esx4
Pool name: Virtual Lab LRA-DEG auf esx4
Folder name: Virtual Lab LRA-DEG auf esx4
IP: <Obtain automatically>
DNS: <Obtain automatically>
Network configuration type: Advanced
Network options:
Isolated network: Virtual Lab LRA-DEG auf esx4 LAN
Masquerade IP: 10.255.30.0
Appliance IP: 10.32.30.195
DHCP: disabled
The appliance ip usually has to be the gateway ip of the production network. In my case this is 10.32.30.195.
When I use the Basic-Configuration it sets the Appliance-IP to 10.32.1.1, which is not the gatewayip.
How does Basic-Configuration choose the Appliance-IP ?
Is this a bug ?
Kind regards,
Martin
Lab name: Virtual Lab LRA-DEG auf esx4
ESX name: esx4.lra-deg.local
Datastore: Vol020_NAS1
Appliance:
Name: Virtual_Lab_LRA-DEG_auf_esx4
Pool name: Virtual Lab LRA-DEG auf esx4
Folder name: Virtual Lab LRA-DEG auf esx4
IP: <Obtain automatically>
DNS: <Obtain automatically>
Network configuration type: Advanced
Network options:
Isolated network: Virtual Lab LRA-DEG auf esx4 LAN
Masquerade IP: 10.255.30.0
Appliance IP: 10.32.30.195
DHCP: disabled
The appliance ip usually has to be the gateway ip of the production network. In my case this is 10.32.30.195.
When I use the Basic-Configuration it sets the Appliance-IP to 10.32.1.1, which is not the gatewayip.
How does Basic-Configuration choose the Appliance-IP ?
Is this a bug ?
Kind regards,
Martin
Re: SureBackup problem
Hello Martin,
Let me explain what happened in your case. With basic settings your production network was resolved to use 10.255.0.0/16 as masquerade IP (255.255.0.0 subnet). However your VM to restore has 10.32.30.16/24 IP and resides on 255.255.255.0 subnet. According to these settings, when surebackup job tries to access your VM it pings 10.255.0.16 IP (instead of 10.255.30.16). The solution is to use advanced settings to edit virtual lab's vNIC settings and type in proper 255.255.255.0 subnet (for your case). Thus proper masquerade IP would be generated (10.255.30.0/24).
With basic settings, network configuration is taken from ESX host, corresponding vSwitch and for corresponding production network. Due to the fact that every environment is different, basic settings cannot handle all cases. Advanced settings is the remedy, and you successfully used it.
Thanks!
Let me explain what happened in your case. With basic settings your production network was resolved to use 10.255.0.0/16 as masquerade IP (255.255.0.0 subnet). However your VM to restore has 10.32.30.16/24 IP and resides on 255.255.255.0 subnet. According to these settings, when surebackup job tries to access your VM it pings 10.255.0.16 IP (instead of 10.255.30.16). The solution is to use advanced settings to edit virtual lab's vNIC settings and type in proper 255.255.255.0 subnet (for your case). Thus proper masquerade IP would be generated (10.255.30.0/24).
With basic settings, network configuration is taken from ESX host, corresponding vSwitch and for corresponding production network. Due to the fact that every environment is different, basic settings cannot handle all cases. Advanced settings is the remedy, and you successfully used it.
Thanks!
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: SureBackup problem
Basic configuration only works for most "classic" private network addressing schemes (as I like to say, those from "Networking for dummies" books). We assumed that customers who have more complex networks are smart enough to figure out advanced configuration option. Just like this happened in your case.
We do plan some basic autoconfiguration tweaking in 5.0.1 (at least to get rid of bugs), but it will probably never works ideally in every single environment.
We do plan some basic autoconfiguration tweaking in 5.0.1 (at least to get rid of bugs), but it will probably never works ideally in every single environment.
Who is online
Users browsing this forum: Bing [Bot], masahiro.takahashi, Semrush [Bot] and 62 guests