Why would replica job create new vNICs in destination?

[pkelly_sts]

I'm currently writing up a detailed plan for a platform migration project (move some VMs from old vsphere 4 infra to a new vSphere 6 infra) and whilst writing up some notes about spinning up a test VM on the old infra to trial processs with first, I remembered that when we had a recent host failure in this environment (which is why we're now deploying new hosts!) I had an issue with, I think, about 2 out of 5 VMs whereby after they had replicated they ended up with a "new" vNIC with no IP address so I had to manually re-IP them (which then raised the old "this IP is already configured on another NIC are you really sure?" type of errors.

In the haste at the time I forgot to raise the question with support as to why this would have happened and it's long ago enough that it would be difficult for me to raise a case now with meaningfull log files so I thought I'd fire the question in here in case anyone has any suggestions as to a possible cause?

[PTide]

Hi,

<...>about 2 out of 5 VMs whereby after they had replicated they ended up with a "new" vNIC with no IP address

Do you mean that replica VMs that initially had had one vNIC ended up having two vNIC instead of one? Were those VMs any different from others?

Thanks

[pkelly_sts]

No, after failover (or could have been this way simply as part of replication, i.e. before failover) I found that, for example, a vNIC didn't have teh static IP of the original source VM and when investigating the windows view of the network was "Local area network 2" as apposed to "Local area network" which implied it was given a replacement NIC.

There are a mix of 2003 & 2008 VMs but unfortunately I don't have notes from the time as to which ones exactly where affected.

[PTide]

Hi,

I found that, for example, a vNIC didn't have teh static IP of the original source VM and when investigating the windows view of the network was "Local area network 2" as apposed to "Local area network" which implied it was given a replacement NIC.

These two fact make me think that MAC address change took place during replication, yet I'm not sure about the reasons why that affected only some of the VMs. Have you tried to reproduce that?

Thanks

[pkelly_sts]

Unfortunately not, as you can imagine, in a real failover situation the focus is primarily on bringing back services.

However, as I said I'm currently finalising planning for migrating these VMs to new hosts/vcenter (this weekend) so will be doing plenty of testing in advance & will watch for this issue again and, if it occurss, I'll log a case though I'm going to be on very tight timescales to complete things if support aren't able to jump on it pretty quickly...

[alanbolte]

Sounds like this issue: https://www.veeam.com/kb1601

[pkelly_sts]

Thanks for the pointer Alan, it does look suspiciously similar however in my case we weren't actually re-ip'ing the VMs as we were simply replicating from host 1 to host 2 in the same site (we had no shared storage then, but that's what I'm in the process of deploying as we speak).

I completed some fresh replicas to the new infrastructure last night so will be having close look later today to see what's happening this time around.

[pkelly_sts]

Results of the first failover test (whilst remembering that we're not re-ip'ing, we're just migrating to new hosts) is that the NIC appears to be retained, i.e. for this particular VM the NIC is still listed internally as LAN #5, but it came up in DHCP mode.

So, the symptoms sound like the article describes, but we're NOT re-IPing them so are we really talking about the same issue?

[foggy]

I'd check whether all the affected VMs have VMXNET 3 adapter.