Bug 1600248

Description of problem:
Before Migration, Source Host should ping the Destination Host using the MTU value which is set for the migration Network. If the ping hangs, the migration should fail.

Version-Release number of selected component (if applicable):


How reproducible:
I am unable to as i do not have a switch setup. The customer has however reproduced this.

Steps to Reproduce:
The customer used the below steps,

1. Setup a switch which is configured to use Jumbo frames but does not successfully do it.
2. Ping the Destination Host using the MTU value corresponding to the Jumbo Frames

Actual results:
The Ping hangs, thereby the migration is stuck at 0%.

Expected results:
The Ping should timeout if it get's hung and the migration should fail


Additional info:

When a migration is initiated, the Source Host should ping the Destination Host using the MTU value which is set for the migration Network. If the ping hangs, the migration should fail.

I Believe we do ping but that seems to be a normal ping2 (please correct me if am wrong here). I see the below message on the Source Host when migration is initiated,

~~~~~~

2018-06-27 18:00:04,537+0530 INFO  (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call Host.ping2 succeeded in 0.00 seconds (__init__:573)

~~~~~~

I Had a case where the Migration Network was set to use 9000 MTU, The switch did support it, However we soon found out that it was failing to forward packets at that MTU value. The Migration was stuck at 0%

When we tried to ping the destination Host using that MTU value set for the migration network using the below command, It did not return anything, simply got hung.

# ping -M do -s 9000 <IP of Destination Host>

I believe normal pings were working.

This proved that the switch was not forwarding frames at that value, even though  it should have.

Once we reduced the MTU on the switch back to 1500 (Default) the migration worked as expected.

My ask here is that why do we not ping using the MTU value set for the network before the migration is started?.
Or is the Host.ping2 using the MTU value set for that network?.

If the ping does Hang like this, then it should be timed out and logged and the migration should fail rather than migration getting stuck at 0%

For example,

If the MTU for the migration is set at 9000 then before the migration is initiated from the source host, we should ping the destination Host using the MTU set for that network, probably something like,

# ping -M do -s <MTU For the Network> <IP of Destination Host>

Based on the above, if the ping times out then the migration should fail rather than getting hung at 0%

Let me know if something is missing here or if something is needed.

Regards,
Siddhant Rao