VIMAPI in Virtual Lab

[artecu]

Hi All.

Looking through my logs to deduce why one Lab wizard works while the next fails I noiced the following lines:

[28.02.2013 13:52:05] <98> Info [VimApi] QueryNetworkHint, nsRef: "networkSystem-50228", devices: "<null>"
[28.02.2013 13:52:07] <98> Info [VimApi] QueryNetworkHint, nsRef: "networkSystem-50228", devices: "<null>"
[28.02.2013 13:52:08] <98> Info Subnet_10.1.122 subnet: 139.230.0.0

The working wizard looks like this:

[28.02.2013 13:50:21] <82> Info [VimApi] QueryNetworkHint, nsRef: "networkSystem-81077", devices: "<null>"
[28.02.2013 13:50:24] <82> Info [VimApi] QueryNetworkHint, nsRef: "networkSystem-81077", devices: "<null>"
[28.02.2013 13:50:24] <82> Info Subnet_10.1.122 subnet: 10.0.0.0

Can anyone explain how this API operates please?
I am running with Veeam BR 6.5.0.128- (just patched it to try and resolve this issue)

[foggy]

Andrew, I do not see much difference between those two log excerpts aside from some networking stuff. Always better contact support for assistance in reading debug logs, probably these are not the right lines to look at while investigating your issue. Btw, what is the failure reason given in the session log in Veeam B&R console?

[rbrambley]

It appears that the IP address is the same but the subnets are different. The working subnet is 10.0.0.0 and the problem subnet is 139.230.0.0 That may be a good place to start ...

[artecu]

Hi. Thanks for the advice. I was hoping this was something simple but will log a call as advised..
FYI
The Lab wizard is run twice pointing to two different hosts within a common vcentre.
I pick the host, then the datastore, then select a static IP address of 10.1.122.211 every time (sometimes I leave the "Production network" as is-- it defaults to a different subnet for each host) . Also I select a DNS server (the same each time on 139.230 subnet).
I then select "Advanced" and Next
The message "resolving network settings" appears and then I get:
(if production network setting left as is- default)" Unable to automatically choose masquerade network address for non private network address '139.230.0.0. Production network name :'subnet_10.31.127" followed by "unable to resolve network settings"
Selecting certain hosts will let me go to the next stage in the wizard without this error, some wizard runs error every time (with or without the "masquerade" error depending on whether or not I change the "production network setting").
I have run through this process twenty or thirty times trying to figure out what Veeam is "resolving". Perhaps I have and issue with my dvswitch setup...I was hoping to get a better understanding from the forum users.
Is the "production network' setting only used for DHCP?

Thanks again

[rbrambley]

A vlab is a standard vswitch with a veeam "firewall" VM creating the isolated environment to run the VMs in. Some call the VM a "proxy". This VM is automatically added to the ESX host you choose to host the vlab on. The wizard needs you to configure the network settings both on the external and internal side of the firewall/proxy vlab VM.

The external side of the vlab is in your production, and, more imprtantly, it needs to be able to communicate with the Veeam GUI server. So, be sure to configure the external interface correctly on a subnet that has a route to the Veeam server. Make sure it uses DNS that can resolve Veeam too, etc.

I know Veeam tries to give you default settings, but it sounds to me that Veeam is picking the wrong settings for you? Over ride those with what will work in your production.

The masquerade settings can be left at the defaults once you get your internal and external vLab interfaces configured correctly. This is the network used to allow the Veeam server and others to pass through the vLab firewall and work with the VMs inside the vLab.

VLabs can be a tough concept to understand at first. These forums are a tough venue to try to visualize and explain how a vlab works. It's really best covered with a whiteboard or product demo. Maybe our Veeam University lesson on vlabs will help you. It's a narrated how to demo, walks through the setup, and is less then 2 mins long. Check it out here:

http://www.veeam.com/university/vlabcrt.swf

While at Veeam University check out all the other how to videos for our various features as well.

Otherwise, Veeam Support can help too. The vlab wizard might have a problem with public ip subnets designed for and normally reserved for the internet. The majority of our customers stick with 10. x.x.x, 172.16.x.x, and 192.168.x.x subnets designed for private networks. Support can tell you if this is the case. I honestly do not know.

[rbrambley]

The Rickatron's Veeam blog post that covers (and is similarly titled) Five Important Points on Vlabs might help you too:

http://www.veeam.com/blog/five-importan ... on-v5.html

[foggy]

The message "resolving network settings" appears and then I get:
(if production network setting left as is- default)" Unable to automatically choose masquerade network address for non private network address '139.230.0.0. Production network name :'subnet_10.31.127" followed by "unable to resolve network settings"

Looks to be typical for environments with non-private networks.

[artecu]

Hi

"I pick the host, then the datastore, then select a static IP address of 10.1.122.211 every time "
I have had many labs working in the past, so I am conversant with the process. What I was interested to learn from these posts is what Veeam does when it invokes the VIMAPI as that may provide a clue as to what is going wrong here.

The only public IP mentioned in the wizard fields is the DNS, but I have tried using a private IP DNS...same result.
I went to log a job with support and was going through the wizard again to write down the issue again and....For some reason its now working! (today at least).
It must be some sort of underlying timeout/overloading issue. Are there any prerequisites to running the Wizard such as making sure there is no activity (backups/restores etc) going on at the time?

Thanks for your input.

[artecu]

Final Update.
I spoke to our Vmware Guru onsite and asked if anything had changed over the weekend (as the labs started working Monday).
Apparently the Vsphere dvSwitch for the vcentre in question had its version updated in line with our recent vsphere version upgrade.
This is IMHO probably a big factor in solving this particular issue.
If you are having these types of problems in your Environment may I suggest that you jump into vSphere Client, select Networking and then "your name_dvswitch" and then Summary Tab. Check that all is weel with regard to VMware version in the "General" pane.
Good luck