problem with Virtual Lab

[pizang]

I have problem with setting up a virtual lab in Veeam Backup 5.02 Enterprise. The problem starts on Networking page. System is not able to use Basic settings. The error is "Unable to automatically choose masqarade network address for non-private network address 99.99.0.0." It shows 16bit addres although we use 24 (let's say 99.99.99.0/24).

I choose Advanced and the problem appears "Unable to resolve network settings for "Virtual Lab 1 Virtual Machine Network". I set up an ip 99.99.99.254 (router address in physical network) and masquarade is 99.99.99.D and dhcp is enabled.

Set up is successful.

When I try to run a job it fails and the error is: 4/7/2011 1:11:08 PM Getting virtual lab configuration 4/7/2011 1:21:58 PM Fail Starting virtual lab routing engine Timed out waiting for proxy appliance to respond. Possible causes: 1. Appliance is configured to run on different network than backup server. 2. Appliance is configured to obtain IP address automatically, but DHCP server is not available. 4/7/2011 1:21:58 PM Fail

Any ideas? I opened a case in Veeam support but no answer for 3 working days (pretty disappointed).

[Alexey D.]

Hello,

The problem is because you're using network addresses which do not belong to private space (not 10.X.X.X, 172.16.X.X - 172.31.X.X, 192.168.X.X). Do you have any reasons on doing this?

[pizang]

Yes - my servers has IP from that space (public). And my default gateway has also address from public space. Is that the only problem?

[Alexey D.]

Actually, it's not recommended to use public IPs for such purposes. Don't you want your virtual lab to be visible on public networks? I think you wouldn't want this because of security reasons.

In theory, manual configuration is possible with your set-up and it's better to go through it with our support, not across the forum. Could you please tell your case number - I will check the status and ping support?

[pizang]

The public range was here before I came and it is not easy to change it if you have 40 servers. We are not visible outside because of masquerade.

Veeam support contacted me just after I started that topic. We are set up for a webex session tomorrow morning. I will update that page after we figure out what was wrong.

[Alexey D.]

Got it. Please keep us updated.

[pizang]

OK, everything is ok - it was my fault. The problem was in masquerade address. It on a vNIC connection settings and looks like (99.99.99.D). I thought it should be a IP from production network for masquerading internal vlab network. The additional problem was that it deleted route to production network (after failed backup veeam cleans up your backup server) and I was not able to ping virtual appliance. The solution was to enter some private range address that is not used in my organization.

It was my fault but I think that documentation has to be updated to clear the virtual alb concept.

Many thanks for Veeam support for helping me out. It took some time due to my complex addressing.

[Alexey D.]

Glad you found the solution!
Using public addresses for virtual lab is quite a rare case, but thanks for your point about more explicit information to be in User Guide.

[pizang]

Using public address was not a problem. The problem was using production network range address for masquerading. It should be completely different address not used in the network so it does not conflict with a current setup - Veaam automatically set up a route to that range (DG for that range will be virtual appliance).

[wakatashi]

[merged]

Running Veeam B&R 6.1.0.181 (64-bit) with vSphere 5.0.

We'd like to use Surebackup to verify backups with a VM running Windows Small Business Server 2011. The production network is 10.2.0.x, with a non-standard subnet mask of 255.255.255.0 (for historical reasons).

An Application Group has been set up containing just one VM, which runs Windows Small Business Server.

A Virtual Lab has been set up with the "Advanced" networking configuration. The Proxy Appliance IP address is set to 10.2.0.254 (same as default gateway in production network), and mask 255.255.255.0. Masquerade network address is set to 10.255.C.D. DHCP service is disabled on the adapter since DHCP is performed by the VM. No static IP address mapping is set up.

When a Surebackup job is run, the error "Timed out waiting for proxy appliance to respond" is logged. If I look at the console of the Virtual Lab VM in vSphere, I see the same error repeated multiple times, all the way up the screen: "pcnet32 0000:00:10.0: eth0: Bus master arbitration failure, status 9cf3".

Have removed the Virtual Lab entirely and recreated with a different name, but the problem persists.

Any suggestions as to what I might try, please?

[panaceklbc]

I have the same problem. I have a distributed switch. I created a standard switch, virtual lab PC booted without any problems. This is not the solution, the manufacturer's fault.

[BigGeorge]

Hi all,
I've the same problem: I've setup one virtual lab in advanced mode (because the basic mode configuration don't work).
When I try to run one SecureBackup job the job sleep on "starting virtual lab route engine": I see on the Proxy-VM system console the message:

Code: Select all

pcnet32 0000:00:10.0: eth0: Bus master arbitration failure, status 9cf3

any help?

thank you
BigGeorge

[Vitaliy S.]

Giorgio, please contact our support team for further logs reviews, as it is hard to say what is going wrong while just looking at this error message.

[McClane]

Hi,

I have the same problem with no network connectivity to the proxy appliance which throws this bus master error. Just one customer who has this problem so far.
Case ID is 5214004.

[wahrheit2004]

Hi,

you are not alone.... For me it is Ticker #5216113

I am running
vCenter Server 5.1
ESXi Hosts 5.0.0 build 768111 with teamed nics on vmkernel switch (Mgmt IP of VMWare ESXi).

The best guess at the moment is the network adapter type in vlab VM.
The are marked as "flexible" and not "e1000" or "e1000e".
We assume that the problem seems to be here.

[McClane]

I got an updated driver package and a config change from support. But that did not help. After I restarted the ESX host which runs the lab it worked again. I do not understand why because there were no other problems with a dozen mixed Linux and Windows VMs.

[wahrheit2004]

Hi folks,

here a little update. Veeam support was supporting me by webex session.
We deleted the vlab and created a new one.
For the new vlab they provided a special .iso image of the vlab that supports up to 1000nics and E1000 nic type.
After vlab creation go use vShpere Client to proerties of VM, delete the network cards (type = flexible) and add new ones (type = E1000) with same settings.

Attention, if you use Veeam to change your vlab properities (Add a new nic, etc) again all nics are type=flexible.

[wahrheit2004]

Hi all,

I am now running several Surebackup jobs in different Networks without any Issue on new .iso and E1000 vNics.
My ESXi is 5.0.0, build 768111 (currently latest patchlevel).

@McClane:
Remember to change the vlab_VM by vShere Client and REMOVE all nics (type=flexible).
Apply with ok, than add ney (type = E1000) and check that you have the correct networks associated.
Good luck!

[gbaya]

I have the same problem

And some machines in the production network such as Smoothwal (Linux) firewall display same error and not work
"Bus master arbitration failure, status 9cf3" in two adapters eth0 and eth1.
Windows VM works fine and other linux machines works fine too.

When I change the production network by other network without physical adapter works fine too.

I guess that virtual lab definition, changes one or more parameters in Production network, because a VM that was working fine for months, now doesn't work.

Any idea of this?

Thanks in advance
Regards.
Gabriel.

[Vitaliy S.]

Hi Gabriel,

Please upgrade to the most recent version of Veeam B&R (v6.5), should resolve your issue.

Thanks!

[adrien]

Hi,

I have the same problem,

my production network is 190.27.11.x and i have the error "Bus master arbitration failure, status 9cf3".

How to configure virtual lab ?

[Vitaliy S.]

Adrien, what version of Veeam B&R are you using?

[adrien]

version 6.1.0.181

[Vitaliy S.]

Reading back through my response above, you need to upgrade to Veeam B&R v6.5 to resolve your issue.

[Butha]

Hi Everybody,

Also experiencing issue with Virtual Lab. Also using public IP range internal - and the same symptoms exist as already mentioned. You cannot ping the linux vm appliance from the veeam backup server - unless you login to the console of the linux vm and ping the backup server from there. The moment a ping replies - a route is somehow established and the routing engine starts. The 2nd part of my issue is around 2008 R2 servers. In general it seems not working too well - have loaded the required hotfixes (pre and post Sp1) to address the VMXnet3 issue and 169.x.x.x Ip's being assigned, and although the correct IP is now detected, a 2nd "unknown production network" on a 2nd NIC is now also detected. This causes an initial 50% fail, and eventually the ping to the correct IP on the first adapter also fails.

Have prematurely closed the first call - and requested a re-open, which isn't possible so back to the queue for a response. The local Veeam representative is trying his best to assist, but we are stuck at the moment.

I must say from my point a big selling feature of the product is at this point not living up to it's expectations.

[odge]

Hi All

I think in general people arent aware of the caveats of firstly a masqueraded scenario, and secondly how linux routers (thats what the virtual lab is), respond to ICMP routing replies.

I'm writing this to kind of say, "look, it does work pretty darn well", but I can remember when I first started using it 2 years ago, that it was quite a learning curve, know which settings do what. ("is that tickbox, and "Or", or an "and" etc), and given the time it takes for a surebackup job to initialize, in slower environments like our test lab, it can get frustrating when you are learning.

From a networking perspective:

Some things observed:
1) if you have other linux based routers (v2 or v3 kernels) in your routing network, be careful of ICMP Redirect packets emanating from them, it usually stops any packet routing from the Virtual LABs masqueraded network.
2) I would strongly suggest depending on your router, that if you want any host to be able to access the masq IPs, and dont feel like adding 1:1 static mappings, that you place the virtual lab off your current production subnet, and let normal router have a second IP on the subnet, with a static route for your masqueraded network pointing to the virtual Lab.

With regard to #2, Veeam adds a route to that specific PC, but who uses the Veeam PC anyway? I prefer working from my own PC over the network to my masq IP range, using SSH and MSTSC like I normally would to those very same production VMs

Quite frankly I love virtual labs, they are thing of beauty, especially for play around in by leaving it running! If only my backup repository had more more spindles!

Cheers guys, good luck with your tasks.

[erth111]

Hi folks,

here a little update. Veeam support was supporting me by webex session.
We deleted the vlab and created a new one.
For the new vlab they provided a special .iso image of the vlab that supports up to 1000nics and E1000 nic type.

Are you talking about Virtual Lab vNICs here? I would definitely need a vLab with that high of vNICs. By default Veeam says 3 is the maximum and after upgrading the vLab VM hardware it should be 10 but this is based on vsphere 5.x specs, not on Veeam's. Veeam support was unable to provide any maximum number of vNICs in vLab (Case # 00575792).

Cheers