Skip to main content
  • EN

SureBackup with Agents is a brand new V12 feature I already blogged about:

SureBackup with physical workloads - and some more gems | Veeam Community Resource Hub

Already using it in production environments, we now faced an issue with a job consisting of a DC and and Exchange server. Both are physical machines originally. For the DC everything worked fine in the SureBackup run. But the Exchange server failed with:

Error: Results: cannot detect IP address

This is right at the beginning of the testing process and even when I disable all checks.

Doing an Instant-Recovery manually with the Exchange, I could determined that the exchange VM - after the necessary P2V and intial boot - shows up an “unknown network adapter” in device manager. Installing the built-in Windows driver for the E1000 with a right-click directly brought up the interface. 

I guess SureBackup failed to do that automatically.

So question is, why does VBR do that correctly for the DC and fails for the Exchange.

We’ll try pre-installing tools onto the physical machine beforehand. If this also does not do the trick, we’ll open a case.

Did anyone face a similar issue already?

Thanks,

Michael

 

Any differences on the original physical servers? Like maybe one has real E1000 and the other has something else like Broadcom?

What OS?  I’d also be tempted to preload tools or at least the drives for the virtual hardware on the machine.  I’m surprised though with the E1000 that it was failing to load, though I wouldn't have been surprised if it was a VMXNET3.

What OS?  I’d also be tempted to preload tools or at least the drives for the virtual hardware on the machine.  I’m surprised though with the E1000 that it was failing to load, though I wouldn't have been surprised if it was a VMXNET3.

It’s Windows 2019 on both machines.

I guess that’s why it defaults to E1000: Windows has those on-board. 

Interestingly it immediately detects them once I update the driver from within device manager via the console. So IMHO it’s just this automatism that fails here for one of the machines.

Any differences on the original physical servers? Like maybe one has real E1000 and the other has something else like Broadcom?

Good question. I have to check with the customer and will follow up here.

Still as mentioned in my previous post: we’re already almost there. E1000 was chosen and P2V just failed to auto-load the driver for one of the machines. 

Any differences on the original physical servers? Like maybe one has real E1000 and the other has something else like Broadcom?

Good question. I have to check with the customer and will follow up here.

Still as mentioned in my previous post: we’re already almost there. E1000 was chosen and P2V just failed to auto-load the driver for one of the machines. 

 

I had the chance to check the source boxes. 

The system working as expected in P2V-SureBackup has a single HPE 1G ethernet adapter.

The one failing has multiple Broadcom NICs (also 1G) and … now comes the point … is combining those within a MS LACP multiplexor driver. So this might be the root cause. 

I would assume the P2V process does not cover the LACP trunk properly.

It should only be a small step though, as jumping into the VMs console and doing a driver rescan in device manager already does the job. E1000 was pre-selected already for the vNIC.

Used often surebackup, but not yet with agents 😂. Nice to know @Michael Melter ...

 

The one failing has multiple Broadcom NICs (also 1G) and … now comes the point … is combining those within a MS LACP multiplexor driver. So this might be the root cause. 

I would assume the P2V process does not cover the LACP trunk properly.

It should only be a small step though, as jumping into the VMs console and doing a driver rescan in device manager already does the job. E1000 was pre-selected already for the vNIC.

 

This sounds like something to open up with support to verify that this is the case and get it on their radar if it isn’t already.  Most of my bare-metal Windows boxes have NIC teaming enabled, but then again, most of those devices ARE the VBR server.  Still something to look into.

Any differences on the original physical servers? Like maybe one has real E1000 and the other has something else like Broadcom?

Good question. I have to check with the customer and will follow up here.

Still as mentioned in my previous post: we’re already almost there. E1000 was chosen and P2V just failed to auto-load the driver for one of the machines. 

 

I had the chance to check the source boxes. 

The system working as expected in P2V-SureBackup has a single HPE 1G ethernet adapter.

The one failing has multiple Broadcom NICs (also 1G) and … now comes the point … is combining those within a MS LACP multiplexor driver. So this might be the root cause. 

I would assume the P2V process does not cover the LACP trunk properly.

It should only be a small step though, as jumping into the VMs console and doing a driver rescan in device manager already does the job. E1000 was pre-selected already for the vNIC.

LACP is (as I know you already know, but also writing for other readers) a bit complex and also requires correct switch configuration. So a simple P2V without proper virtual switch configuration would not “just work”. Did you open a support case just to check what the expected behaviour is for your setup?

The support case is still open as the customer has other priorities at the moment. 

When I find some time, I may test this in a lab.

We would need to distinguish between switch independent teaming and LAG/LACP teaming. 

As @haslund says, for LAG/LACP we need the switch to be prepared. So we cannot expect it to "just work". For switch-independent teaming, however, it should work.

Comment


Terms & Conditions