Veeam Backup & Replication and vCloud Director

[bfarmil]

Hi,

Is anyone out there using Veeam Backup & Replication (VBR) on a cluster that has vCloud Director (vCD) managing it? We have been running vCloud Director for about 4 months now and though it provides a nice environment for managing the provisioning of customer virtual machines (we run a VM hosting business) the integration with third party applications is very problematic. VBR does a great job of backing up all our VM's both vSphere and vCD provisioned but the fun starts when restoring data from the backups.

The Virtual Lab environment and SureBackup is causing me no end of problems. As all our VM's use Distributed Virtual Switches (DVS) and in a lot of cases VMXNET3 virtual network adapters we seems to have picked technologies that cause problems. If I create a lab environment and try to "restore" a VM into the LAB that has a VMXNET3 adapater VBR seems to automatically preserve the MAC address of the NIC which I understand is to ensure that it keeps the IP details thanks to a Server 2008R2 "feature" Microsoft let through testing. The problem is vCenter sees i'm trying to power up a VM with a conflicting MAC (even though they are on different vSwitches, port groups and sometimes even hosts) and does not allow the vNic to "connect" during boot. This causes services to fail on start up due to a lack of network. I can mitigate this by manually connecting each vNIC after the boot process has started but this means my Surebackup testing cannot be automated.

Does anyone know of a way to tell vCenter to allow the VM to attach the vNIC even though it has the same MAC as an existing VM?

Oh and before you say "why not change the vNIC to be an e1000 or VMXNET2 adapter", i've tried that. It seems vCloud Director likes to interogate new VMs as they appear in the cluster and though i'm not 100% sure that is the cause of the problem any VM that is attached with one of those adapaters generates an "Ethernet0 failed to initialize" error on start up in the lab and boots without the vNIC "connected". In my attempt to try and exclude vCloud Director as a possible cause i've discovered that because my VM's are attached to a DVS when I restore them to a lab on a non-DVS capable ESX server they are created without any vNIC at all.

I'd be interested to hear if anyone has had similar problems or has some idea what could be done to resolve this. I've also logged a ticket with Veeam [ID#5108797] if support are reading this.

Thanks.

[Gostev]

Hi Bryce, I believe our VMXNET3 issue workaround logic can be disabled through a registry hack, if this can help you. Thanks.

[dkvello]

I have exactly the same problem. VMxnet3 vNics are automatically disconnected during a Surebackup Job, causing the Job to fail an stop.
I can, however, manually enable them. But this is NOT how I expect this to work.

[Vitaliy S.]

Hi Dag, if you are using vCloud Director and your VMs are being disconnected due to a preserve MAC logic (due to VMXNET3 issue workaround), feel free to contact our support team for a registry key that disables VMXNET3 workaround (MAC address preservation). Thanks.