"Invalid configuration for device '0'" after failover

[janz]

We are currently evaluating Veeam. Our configuration will be rather small in the light of most VMware deployments. We will have two servers and we plan to use one as fallback server for the other in case of an emergency. To achive this most of the guests are replicated between the hosts.

After I configured replication and let it run for a few times, I tested the failover scenario with two different Windows 2008 server (one SP2, the other R2). The replicas seemed to start without a problem, but were unreachable. After inspection I discovered that the virtual NIC wasn't connected and forcing a connect resulted in an "Invalid configuration for device '0'" error . The only way I have found to fix this is:

1: Remove the NIC from the guest (using Virtual Machine Properties)
2: Add the NIC again but uncheck connect at power on (the guest will hang if you forget this)
3: Start the guest and wait until the login prompt
4: Force connection
5: It works

The funny thing is that it will not only work, but the newly added NIC will even have the settings of the original one.

BTW, the reason that I found this so quickly was that the same thing happened when I tried to run a VM that I moved from an ESXi host on an ESX host. And then, I didn't find this solution so soon .

Ideas anyone?

Jan

[Gostev]

Jan, what ESX versions are you replicating between?

[janz]

Jan, what ESX versions are you replicating between?

First one remark. I am a novice with ESX just as much as for veeam, so bear with me (and also my English isn't perfect).

Both ESX servers are 4.0.
* Client states 4.0.0 Build 162856
* vCenter Server 4.0.0 Build 162856
* ESX, 4.0.0, 171294

Hardware
* Dell PE R710
* 2 x E5520 @ 2.27GHz
* 32GB

Thire is one more thing that I am going to try and that is to just:
1. Stop a VM
2. Copy the image to the other datastore using the datastore browser.
3. Start the VM there

I am starting to get the idea this is a VMware problem.

Jan

[Gostev]

OK, in that case this is not the problem I have suspected. Please send all logs from Help | Support information and problem description to support@veeam.com to open support case, and our support will assist you in troubleshooting. This behavior is definitely not expected.

[janz]

OK, in that case this is not the problem I have suspected. Please send all logs from Help | Support information and problem description to support@veeam.com to open support case, and our support will assist you in troubleshooting. This behavior is definitely not expected.

Hello Anton,

thanks for taking this serious. I did as you asked, but it seems my 19MB attachment isn't accepted. I tried to bring it down to 10, still not accepted. I have now cleaned out the entire directory and rebooted (so the initialization log files, if there are any, will be recreated). Then I wil perform another replication and another failover. Log info about initial Replication will however not be available anymore. If this is needed, I could start all over, but this would take a bit longer.

Jan

[Gostev]

Jan, our support can provide you with FTP site to upload logs to.

[Jan2]

A common cause of the NIC failing to connect when a VM is migrated is the VLAN name. If the VLAN for the adapter on each host is not named and spelled identically, the NIC will not automatically reconnect.

[janz]

A common cause of the NIC failing to connect when a VM is migrated is the VLAN name. If the VLAN for the adapter on each host is not named and spelled identically, the NIC will not automatically reconnect.

Thanks for thinking with me, but this can't be the cause. I don't use VLANs. Veeam support is currently also trying to help me, but I am suspecting it is mainly a VMware issue. It seems that VM's created on ESXi don't behave the same as VM's created on an ESX host.

If I failover a VM created on ESX, the only problem is that I need to manually connect the virtual adapter to the proper virtual switch. I consider this acceptable. If I try this with a VM that was originally created on ESXi, I must do quite a bit more (as described in my original post).

Jan