B&R RAM usage in large virtual environments

[dep212]

I'm using the free version of B&R (great product btw!) to move VMs between vCenters that live on separate networks, but I've run into something that may just be a consequence of our environment, so I wanted to see if anyone else had seen this... Between the two vCenters that I'm moving VMs to/from, we have over 6000 VMs, and it seems like this causes B&R to take forever to enumerate the contents of a datacenter (4-5 minutes) or "Check the possibility of migration" (20 minutes or more), and have the Veeam.Backup.Shell process take up anywhere from 1.5 to 4 GB of RAM. I use this tool because it gives me better info if something goes wrong than VMWare Converter, but Converter takes a fraction of the time to pull up lists of VMs and actually start moving bits. Is this a side effect of the size and scope of our virtualization infrastructure, or am I missing something that could make things snappier?

Thanks for any hints or tips!

Derek

[Vitaliy S.]

Hi Derek,

What is the hardware configuration of the machine where you've installed Veeam B&R Free? Are both vCenter Servers located on the local network with Veeam B&R? Can you please clarify how exactly do you migrate your VMs using Veeam Backup Free? Are you using VeeamZIP for that?

The initial enumeration might indeed take some time (depends on the size of your VI), so for large VIs it might be expected. On a side note, why not to use Veeam B&R full version to migrate your VMs from one vCenter Server to another, in this case you will be able to use migration and replication jobs for that and will not need to VeeamZIP your VMs all the time?

Thanks!

[dep212]

Vitaliy,

Thanks for the response. The machine I'm running B&R on is a VM running Windows Server 2008 R2, 2xCPU, 6 GB RAM. I have to connect to a VPN to access one of the two vCenters, but the other is on the same network as the B&R server. I migrate by finding the VM in question and right-click and use the Quick Migration wizard to select the destination host and datastore. I don't really have a need to set up jobs as these migrations are typically one-off situations where a copy of a dev box is needed in production to demo new features to a client, so there aren't any recurring aspects to these migrations.

If the delay was just the initial enumeration, I wouldn't have thought about it, but it's the huge delay between selecting the destination host and storage, and being able to click finish to start the migration...

[Vitaliy S.]

I have to connect to a VPN to access one of the two vCenters, but the other is on the same network as the B&R server.

Is the secondary vCenter Server located over the WAN link by any chance?

If the delay was just the initial enumeration, I wouldn't have thought about it, but it's the huge delay between selecting the destination host and storage, and being able to click finish to start the migration...

So you see the issue only when choosing destination targets, right? Just trying to get as much details as possible.

[dep212]

Is the secondary vCenter Server located over the WAN link by any chance?

The typical source is on the same network and the typical destination is over the WAN link, but there have been cases where this is reversed.

So you see the issue only when choosing destination targets, right? Just trying to get as much details as possible.

Actually the time of the biggest delay, and also the highest CPU and RAM usage is during the next to last step after the destination host, container, and datastore have been selected, when a dialog box that says "Checking the possibility of migration". The CPU usually runs at 50% and RAM gradually goes up to anywhere between 2.5GB to 4 GB until the dialog disappears, and I can then click Finish to start the actual migration. This step takes at least 15 minutes and has taken as much as 30 minutes to complete.

[foggy]

Delay could be indeed caused by the environment size as the whole object hierarchy seems to be loaded at the stage of checking migration possibility. You could open a case to let our engineers look at your logs and define the exact operation causing such a delay. We've just tried to reproduce this internally and can see the loading hierarchy operation in the log - while not taking so much due to the lab size, it could probably do so in the environment of your size (plus taking WAN link into account).