VC 2.5 / ESX 3.5 VMotion Slow Migrate

[dsammich]

Anyone....

I am posting this message to attempt to try and find a reason for the above....

This is a brand new install, There are two high end IBM x3650 servers running. Each server has 4 physical CPU's that are dual core (8 procs per box). Each box also has 34GB of Ram all connected to a Cisco 6509 switch with the gigabit line cards (so everything is gigabit). There are 4 gigbit network cards in each box as well

At this time, I have only one virtual machine running. When I attempt to move the VM from one box to the other, the process starts, goes to 10% sits for about 45 seconds, then chugs to 30, 55, 66, 75, etc then hit 90% completed.

When it hits 90% I lose connectivity to the VM (I am pinging and begin to get timeouts) and I lose connectivity for around 6-10 pings which is around 15 seconds or so. The completed process jumps to around 94%, hangs there, i then get connectivity back and then around 15 seconds or so it finally completes.

I have done a variety of tests from changing vlans, checking duplex settings, and now I have a x-over cable connecting the two servers to where the Vmotion traffic is set on each server, dedciated with a virtual switch which is dedicated to the nic that I have x'd over. I still am having the same performace issue!

Oh...one more thing...this is the latest builds from the site as well...both ESX and VC are both Dec 07...

Anyone have any ideas??

[mike_laspina]

What is your storage configuration?

[dsammich]

It's an IBM SAN, but storage doesn't matter as Vmotion does nothing with the LUN.

[mike_laspina]

It may not change the data but it does have to transition to the target server LUN path. So it does play a important roll.

[mike_laspina]

Please post the results of

esxcfg-info -n

esxcfg-info -s

[dsammich]

-

---

Everyone,

I wanted to post this reply to guide someone else so they are racking their brain trying to find this and to let Mike know he was headed in the correct direction. The problem was a SAN problem, but not where you would think.

The issue of the slow response was because of the host type setting under the IBM Storage Manager Client. When configuring the hosts that will be accessing a LUN IBM recommends configuring the host setting to linux cluster (which is labeled something like linxclu) under the storage manager client. So when you configure your host ports to be able to map the LUN to the host, just make sure you use that setting for ESX.

I also was looking the log files: /var/log/kernel and /var/log/messages. If you use the trail /var/log/kernel it will update the console with real time view of the kernel logging. There I saw where I was getting errors on the fiber channel side and confirmed this.

Those that are familiar with IBM, I also noticed that the LUN was changing the preferred path from the "B" controller to the "A" controller just as I would start a vmotion process. I found out that this may have had something to do with the storage adapter settings being set at fixed or MRU (most recently used).

Mike, thanks for heading me in the right direction!

This case is solved!