Storage VMotion NOT Transparent

[pperalta]

Hi Everybody,

Just wanted to see if anybody was exhibiting the same problems with Storage Vmotion as I or if this is expected. When I perform my Storage VMotions, I have a persistent ping going to the particular VM. At about 10%, I lose 1 PING reply, which is no big deal, but when I hit the 90% mark, I can lose upward of 10-15 PING replies (scattered, not consistent PING drops), which cause my RDP connection to drop. I've noticed, the bigger the VM, the more PINGs lost.

What do you guys experience?

Thanks for your time everybody,

Phil

[deceit]

Id love to help but have no idea how to even storage vmotion 😕

[runclear]

I have not experienced the issues you have described, and in my experience with using svmotion - its been 99.98% bullet proof.... i say 99.98% b/c the other day i was svmotioning one of our BES servers, and for whatever reason it lost its D:\ Drive during the process, so i had to do a quick recovery .... but other than that one incident no other issues.

What type of storage are you svmotioning from/to etc... is the I/O really high?

[pperalta]

Thanks for the reply.

Are you using a GUI or CLI to perform the SVMotion? I know when I use the GUI to perform the SVMotion, and you have your C: and 😧 drives separated, you may miss to move a secondary drive. I wonder if this is the case? If not, did you open a case with VMware to check logs? Coincidentally, I still have to one of our BES servers.

To answer your question, I am moving all my VMs off of our tier 1 storage (DMX) and onto our new tier 2 storage (XIV). The I/O is very low at this point since we just got the storage.

[mcsenerd]

I can't say that I've ever had any real issues with the dozens of Storage VMotions that we've performed. The only issues we've had have all been PEBKAC issues...

I'd need some more details before I could help you troubleshoot any...but in any case I'd suggest that this be brought with VMware Support as it is certainly not normal. There are just too many variables here though right now...what type of storage is involved? Are you doing VST? ...and many other questions...

[hmarcel]

Hi pperalta,

which firmware version are you using on your XIV, 10.0.1.a or 10.0.1.b and which ESX 3.5 update are you using , U3 or U4.

hmarcel

[pperalta]

HI hmarcel,

Just got confirmation from our SAN guy that we are using firmware version 10.0.1.a. Within our VM cluster, we actually have both updates (u3 and u4) on different ESX hosts. Are there known issues that I am not aware of in the version we are using?

Thanks for your help hmarcel,

Phil

[hmarcel]

Hi Phil,

i would suggest that you should try to upgrade to the 10.0.1.b firmware version. We saw on our XIV boxes some performance increase and a better behaviour for storage vmotions.

The 10.0.1.b firmware version is also better if you have more ESX servers and more than 10 to 12 VMFS's. With the "a" version it could be that by doing vmotions, (storage or vm's) that you will fall into timeout and finding delay's (starting up VM's) as you already mentioned.

There should also be a new firmware version coming soon improving again performance in an VMware environment.

Also stress your IBM or IBM reseller people to give you more updates on XIV/VMware development. We are currently working together with an IBM Storage competence center on XIV and Vmware.

The XIV is IMHO a good ESX box, easy to setup and fine for virtualization, hey and i am not working for IBM

Also the U4 update of ESX solved for us some issues with the disk driver depth queuing which works better now or at least works now.

Marcel

[RParker]

I lose 1 PING reply, which is no big deal, but when I hit the 90% mark, I can lose upward of 10-15 PING replies (scattered, not consistent PING drops), which cause my RDP connection to drop.

I see 2 potential problems. First your NIC's are they utilizing jumbo frames? Sharing bandwidth with other services on the network (i.e iSCSI / NFS, etc..). NIC's are segmented for vmotion and separate from other devices?

Second, GIG speeds from end to end to ESX hosts? Nic cards may be Gig, but the switch they are going through is it configured for Gig, and is it a true switch, like enterprise level? Do you have vMotion configured on the same vSwitch as your console, and no VM's on that same switch.

Any or all of these can cause these type of issues, and your RDP should not drop during vmotion. That means there is a lag or some network component causing the issue.

[hmarcel]

Hi Phil,

the 10/90% phenomena you see by loosing pings, we have had it also with 10.0.1.a. It seems that the vmotioned VM freeze up during the 10/90% state.

This works also better , at least for us with the 10.0.1b version on the XIV.

Marcel

[LucentOne]

We are running XIV 10.1.0.0 and do not have these issues.