VMware Cloud Community
MV92
Contributor
Contributor
‎03-29-2013 03:03 AM
Jump to solution

RHEL 5 P2V converter server helper static IP address problem

Hello!

I'm doing an internship where I have to set up a VMware environment with ESXi 5.1, and I have to P2V a couple of RHEL (5 and 6) servers.

So now I'm looking how the VMware vCenter Converter Standalone Client 5.0.1 works. I have already performed a couple of P2V's, successfully!

But it seems that everytime I want to do a P2V, I have to use another static IP address for the converter server helper 'cause otherwise the converter stalls at 1% and is trying to connect the converter server helper.

What I don't get is that I only do one P2V at a time, and so the IP addresses I use are reserved and not being used by any other machine.

Does anyone know what the problem is? Because if I have to perform a couple more P2V, I'm out of IP addresses I can use...

Thanks in advance!

0 Kudos
1 Solution

Accepted Solutions
ivivanov
Expert
Expert
‎04-01-2013 06:17 AM
Jump to solution

Hi,

We were able to identify the issue and it is not in Converter itself, but rather related to the physical infrastructure. The problem is in the ARP cache on the target network gateway. After the first conversion it has cached an ARP entry for the helper IP address. When you start the second conversion, the new VM that is created has a new network card with a new MAC address, but the gateway is not aware of this change and when Converter Server tries to connect to the helper, the gateway sends the IP packets to the wrong MAC address and eventually they are dropped. When the ARP cache on the gateway expires - the problem is fixed automatically (in our environment by default it was about 15 minutes, but it depends on the specifc hardware and configuration).

A possible workaround is to generate some network traffic from within the helper VM (e. g. a ping to the default gateway IP address) that would generate some ARP traffic and refresh the gateway ARP cache. Instructions how to logon to the helper VM are available at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1036746. Once you login you can ping anything (even an invalid target IP address does the job) and the conversion should proceed immediately.

HTH,

Ivan

__________
It is worse!

View solution in original post

0 Kudos
2 Replies
ivivanov
Expert
Expert
‎04-01-2013 06:17 AM
Jump to solution

Hi,

We were able to identify the issue and it is not in Converter itself, but rather related to the physical infrastructure. The problem is in the ARP cache on the target network gateway. After the first conversion it has cached an ARP entry for the helper IP address. When you start the second conversion, the new VM that is created has a new network card with a new MAC address, but the gateway is not aware of this change and when Converter Server tries to connect to the helper, the gateway sends the IP packets to the wrong MAC address and eventually they are dropped. When the ARP cache on the gateway expires - the problem is fixed automatically (in our environment by default it was about 15 minutes, but it depends on the specifc hardware and configuration).

A possible workaround is to generate some network traffic from within the helper VM (e. g. a ping to the default gateway IP address) that would generate some ARP traffic and refresh the gateway ARP cache. Instructions how to logon to the helper VM are available at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1036746. Once you login you can ping anything (even an invalid target IP address does the job) and the conversion should proceed immediately.

HTH,

Ivan

__________
It is worse!
0 Kudos
MV92
Contributor
Contributor
‎04-01-2013 07:13 AM
Jump to solution

Thank you! I'll give it a try tomorrow!

And it worked, thanks!

0 Kudos