VMware Cloud Community
conradsia
Hot Shot
Hot Shot

Unable to see multi-path info for datastores

This is an interesting one, I have two seperate sets of HP DL380's running fully patched 3.0.1 with VC 2.0.2. When I right click a datastore and click properties no path information is available and when I click manage paths I get this error:

\----


Error

\----


Specified argument was out of the range of valid values.

Parameter name: index

It also happened to me with a set of IBM 366's using esx 3.0.1 and VC 2.0.1, when I upgraded to 2.0.2 and patched ESX it went away. These same sets of 380's have some 580's in seperate clusters being manged by the same VC server that don't have this problem so I am ruling it out as a VC issue.

I don't think expect anyone to have an answer (an answer would be nice though) but has anyone else seen this? I'll probably open a ticket on it soon and see what VMware has to say.

Reply
0 Kudos
13 Replies
conradsia
Hot Shot
Hot Shot

I left the properties screen open for like 5 minutes and then it populated. It still is a problem I think, anytime I close and re-open VC this happens, not to all of them just certain ones. And this is the first time it has actually shown up, just as I go to complain it decides to work Smiley Happy

Message was edited by:

conradsia

Reply
0 Kudos
conradsia
Hot Shot
Hot Shot

Ok, I spoke too soon. Now the issue has moved to the 580's. No path info, same error.

Reply
0 Kudos
mfredericks
Enthusiast
Enthusiast

I am seeing this as well. I have VC 2.0.1 and ESX 3.0.1. I recently added an extent to a datastore and it seems like it might be funky since then. Maybe it was happening before the extent. Before everyone starts yelling, I know extents are not great. I am not using it for production machines but rather a datastore that backups go to. I have BL460c and BL45 blades. Seems to be happening on just about all of my systems but it did come right up on ONE of the BL45's. I use esxCharter and esXpress, not sure if these are impacting anything. These products are also in use on the one server that is reporting path/extent info right away.

Reply
0 Kudos
mfredericks
Enthusiast
Enthusiast

Still seeing this issue. I have done some more investigating. In one cluster I have two servers. I can see the multipath/extents on one server but not the other. If, on the server that I can't see the info, I do a "rescan for new storage devices" then I can see the info. However, now that I can see it on that server, I can no longer see it on the other. I am doing this all in virtual center. I found that if I connect directly to the server with the VI client then the info is fine.

So, what's going on in virtual center? I restarted the VC service and this was no help. I rebooted the entire VC server, no help.

Anyone have any ideas?

conradsia
Hot Shot
Hot Shot

Hi,

I see the same exact issue, Scan on one cluster and they disappear on the other cluster, or sometimes just scan on one server and they will disappear on all of the others. But like you said they do show up properly when you point the vc client to a single host or when you run esxcfg-mpath -l.

I am going to re-open an earlier ticket I had opened with vmware support. They wouldn't help me solve it since it was running a MSDE database. I upgraded the VC to 2.0.2 and installed a SQL DB so now I should get some help.

Wait, the initial server I was having the issue with was fixed when I did an upgrade of the VC server, installed all of the patches and moved the DB off of MSDE to a full SQL instance. However, the issue has occured twice since then on fresh builds of HP 580 and 380 clusters running fully patches 3.0.1 servers and VC 2.0.2 with a full SQL instance and not msde.

Reply
0 Kudos
hollam
Contributor
Contributor

Hi All,

We've just got this error after upgrading from ESX 3.01/VC 2.01 to ESX 3.02/VC 2.02. I've found a way to get the information back (well it works for us). I've yet to find out how long it remains...

\- On ONE Host, go to Configuration Tab > Storage > Refresh

\- You should now be able to see all LUN info on all hosts now

What we've seen is the same as everyone else, when talking to the VI Server, it affects all hosts (we even had one LUN that worked properly across all hosts from some reason), but when talking direct to the host via the client, it's all fine. So obviously some VI Server confusion going on here.

Hope this helps somebody. We even built a completely clean VI 2.02 server, migrated our hosts & cluster, only to find the problem reappeared Smiley Sad

Cheers!

Reply
0 Kudos
hollam
Contributor
Contributor

Hi All,

Spoke too soon naturally, the problem is back. Definitely a VC server issue in my book. A refresh keeps it a bay for a short while. A rescan makes no difference. Almost seems like a refresh on one host brings it back on others. Maybe VC is getting hung up on a particular host for some reason. It only occurred after the clustering we're pretty sure...

We're logging a support call with HP/VMWare to get it looked at. Will keep you posted if we find anything.

Cheers!

conradsia
Hot Shot
Hot Shot

"some people say" that it may just be an issue with fetching info from the database. Connections timing out or just taking a long time to retrieve the info from an overgrown DB.

Reply
0 Kudos
unixmonster
Contributor
Contributor

I am seeing this issue as well and have for quite some time. I am able to get around it by performing a rescan on the iSCSI vmhba40 under the "Storage Adapters" section. It is very much a pain to see this happen all the time. I just recently upgraded to VC 2.0.2 in hopes that would help alleviate the problems, but it has not.

Reply
0 Kudos
mfredericks
Enthusiast
Enthusiast

Hi All,

I kind of forgot about this issue since it just stopped happening at one point. I recently upgraded everything to 2.0.2/3.0.2, and in the process shrunk my virtual center database down by removing old counters. I had a gigantic virtual center DB since I had by counter logging level set to maximum (per recommendation of a vendor). I stopped virtual center service and truncated the history by issuing the command "TRUNCATE TABLE VPX_HIST_STAT". Again, I think the combination of reducing the VC DB size and upgrading to 2.0.2/3.0.2 helped this.

Mike

Reply
0 Kudos
vmfanboy
Contributor
Contributor

Hi all,

We have the exact same issue here (ESX 3.5.0update1-VC 2.5update1 AND ESX 3.5.0, VC 2.5) and I don't think it's a database issue because we have a small lab for vmware that is a few month old and there is only 3 ESX, 1 VC and 4 VM in it... and we have this issue. We have 2 others setup 1 VC and 4 ESX and the other VC has 9 ESX that also experiencing this problem...

Any help would be appreciate

Thanks

Dan

Reply
0 Kudos
sheetsb
Enthusiast
Enthusiast

I called support with the same issue. Some nodes of the clusters could see the various paths to the storage and other could not. Then it would change and those that were able to see it couldn't and vice versa. I got an admission that this is a known bug in VC and will be fixed in an upcoming release. No specifics. By the way, if you connect directly to the host using the VC client, at least in my case, all the path data was visible.

Bill S.

Reply
0 Kudos
vmfanboy
Contributor
Contributor

Hi Bill,

Thanks for your answer and yes connecting directly to the ESX with the VI client (or using esxcfg-mpath in the COS) seems to be working fine. But for the "fixe" we might have to wait a while since this tread is a year old... Smiley Sad

Dan

Reply
0 Kudos