Struggling with SureBackup IP addressing

[howartp]

Hi.

I've been playing with SureBackup on and off, and spent a good while on it tonight. The script tests are working, but the ping tests are failing with "No destination network for IP address 192.168.5.11" which is the DC I'm trying to test. (The App Group just has both DCs in it, nothing else)

My live VMs are VMware, on production network "VLAN5_LIVE", all in 192.168.5.*

My B&R 9u1 server is 192.168.5.17

My DR VMware host is 192.168.4.117 with a VLAN5_LIVE network configured on it. This is working with a regular Win7 VM, accessing production network normally.

Because everything is on 192.168.5.* I am using the Basic single-host network option.

Code: Select all

Lab name: VRTX4 Virtual Lab June16
ESX name: 192.168.4.117
Datastore: VRTX_Store

Appliance: 
Name: VRTX4_Virtual_Lab_June16
Pool name: VRTX4 Virtual Lab June16

Production network name:VLAN5_LIVE
IP: 192.168.5.120
Subnet mask: 255.255.255.0
Default gateway: 192.168.5.254

DNS:
Preferred: 192.168.5.11
Alternate: 192.168.5.12

Network configuration type: basic single-host
　
Network options:
Isolated network: VRTX4 Virtual Lab June16 VLAN5_LIVE
Masquerade IP: 192.168.254.0
Appliance IP: 192.168.1.1
DHCP: enabled

Network mapping:
VLAN5_LIVE --> VRTX4 Virtual Lab June16 VLAN5_LIVE

I can see in the logs that SureBackup is creating the route (and it then does route print showing it pointing to 192.168.5.17):

Code: Select all

route.exe add 192.168.254.0 mask 255.255.255.0 192.168.5.120

Can anyone suggest what's up?

Peter

[alanbolte]

Looks like Basic Single Host is picking up the wrong default gateway (192.168.1.1 instead of 192.168.5.254). Switch to Advanced Single Host to change the setting.

[howartp]

Thanks for your reply.

Isn't it typical that after I posted last night, I managed to get it working - at least to a point.

I have discovered one bug in the SureBackup process, and it's possible my problem is linked to it.

After I posted, I completely deleted my Lab and SureBackup job and started again with exactly the same settings and it worked ok this time.

I noticed earlier on that I had initially created my production networks on the DR host with different names to the production networks on the VMs, so part way through my testing, I renamed the production network, edited the VLab and selected the new network on the Proxy tab. However this doesn't update the network map settings on the final screen of the VLab. In basic mode, despite me telling the VLab to use a new Production Network, it was still mapping the old production network to the isolated network.

The way around this was to set it to Advanced mode, make some changes, go Next then Previous and change it back to Basic Mode - this asked me if I'd like to reset the network settings, after which it did another "detecting networks..." process and subsequently showed me the correct mapping.

If a user makes changes to the production network settings in a VLab, is it possible for the VLab wizard to redetect its networks when in Basic mode?

However, I suspect it still hadn't updated everything completely because when I deleted this VLab and recreated it with the same settings, in Advanced mode, as I'd tried at various points through the day, it worked ok first time.

Now... I told you in my first post that everything was all on 192.168.5.* which was correct for the VMs I was testing with. However some of my VMs are on 192.168.4.* which I need in the same AppGroup as the DCs. I've added a 192.168.4.* entry to the isolated networks in my advanced lab (a copy thereof) to see what happens, but the job is now failing with "failed to power on in time" or something like that.

I'm just running it now and watching it, because I'm not sure if it's a mapping issue (ie it isn't getting an IP response in time because I've got some mapping wrong) or whether it is literally the timeout that needs extending - it's currently at 10 minutes which should be sufficient for most of my VMs!

I'll report back.