Losing Datastores

Tolahouse · Sun Jun 13, 2010 5:03 am

I have seen mention of this referring to ESX 3.5 however I am running ESX 4 and all referrences are to snapshots - these are not snapshots but actual volumes.

A major reason why my environment cannot go into production is that on reboot of any of my hosts I totally lose connection to the datastores on Starwind 5.2
Via vCenter I cannot do anything at all, I have to drop down to the actual host and then re-add the LUNS to the storage that way.

Is there a setting in Starwind or ESX that I'm missing to make the LUNS persistent across reboots?

Thanks

howesh · Sun Jun 13, 2010 10:52 pm

I am having the same issue. Every time I reboot my ESX4 hosts, I have to reconnect 8 luns. When there is a VMware patch, I have to reconnect 24 luns to get working again. It never happen in Starwind 4 only in Starwind 5. Any help would be greatly appreciated. I cannot connect them within the VCenter, I have to connect directly to the hosts.

Mon Jun 14, 2010 9:35 am

Do you guys happen to have StarWind logs from unsuccessful attempts to connect to it? If not please grab ones and send us to support@starwindsoftware.com so we could take a look why we refuse to allow ESX to re-connect (if the problem is on our side rather then ESX configuration). Thanks!

Mon Jun 14, 2010 10:04 am

Please update your StarWind to the most recent 5.3.5 version. Also please install all ESX updates.

tulsaconnect · Thu Jun 24, 2010 3:39 pm

So are you saying that this is a know issue that is fixed in 5.3.5?

I didn't see anything in the 5.3.5 release notes about it.

Thu Jun 24, 2010 3:53 pm

You really need to upgrade to the most recent version ALWAYS. W/o checking what's on the fixes list.

tulsaconnect wrote:So are you saying that this is a know issue that is fixed in 5.3.5?

I didn't see anything in the 5.3.5 release notes about it.

tulsaconnect · Thu Jun 24, 2010 4:16 pm

Sorry to disagree, but if you've been doing I.T. work for any length of time, you know that "upgrading for the sake of upgrading" is bad habit to get in to.

Do you always apply the latest Microsoft hotfix or service pack the day it comes out, too?

Thu Jun 24, 2010 4:28 pm

Yes.

tulsaconnect wrote:Sorry to disagree, but if you've been doing I.T. work for any length of time, you know that "upgrading for the sake of upgrading" is bad habit to get in to.

Do you always apply the latest Microsoft hotfix or service pack the day it comes out, too?

tulsaconnect · Thu Jun 24, 2010 4:49 pm

Umm I see.

That is kind of, well, scary.

Good luck with that!

Thu Jun 24, 2010 5:02 pm

The whole idea of Windows-based HA is "keep clients connected with zero-downtime at the time system storage nodes upgrade".

tulsaconnect wrote:Umm I see.

That is kind of, well, scary.

Good luck with that!

tulsaconnect · Thu Jun 24, 2010 5:07 pm

I think you misunderstand my point -- I was saying that it isn't necessarily a "best practice" to apply patches/fixes from a software vendor (not specifically StarWind) the moment they come out, especially if what you have running is running just fine. The old saying "If it ain't broke, don't fix it" comes to mind. Doing so may actually CAUSE a problem -- for instance, many Microsoft "fixes" over the years have caused more problems than they solved, and had to be backed-out of a system to get it back up and running correctly.

Thu Jun 24, 2010 7:17 pm

It was really you who "generalized" the topic. I was talking about StarWind initially. In our case YES, it's critical to install all of the updates we release. OK, it's *recommended* to do so.

tulsaconnect wrote:I think you misunderstand my point -- I was saying that it isn't necessarily a "best practice" to apply patches/fixes from a software vendor (not specifically StarWind) the moment they come out, especially if what you have running is running just fine. The old saying "If it ain't broke, don't fix it" comes to mind. Doing so may actually CAUSE a problem -- for instance, many Microsoft "fixes" over the years have caused more problems than they solved, and had to be backed-out of a system to get it back up and running correctly.

tulsaconnect · Thu Jun 24, 2010 7:23 pm

I understand your point. But, I've been watching these forums long enough to know that StarWind is not immune to this problem either -- that is, a new update/patch/version has introduced problems that did not exist beforehand. So, that is why my policy is always very conservative, and why I always examine the release notes of a new update to see if it is worth the time, effort, and the potential for "oops, the upgrade didn't go smoothly!" types of issues.

Don't get me wrong -- I am a big StarWind fan, but when I see posts that say things like "Upgrade to the latest release" without a "because this specific issue was a known issue, and is fixed in this release", I get a bit nervous.

Fri Jun 25, 2010 2:22 pm

OK, valuable opinion. Accepted!

tulsaconnect wrote:I understand your point. But, I've been watching these forums long enough to know that StarWind is not immune to this problem either -- that is, a new update/patch/version has introduced problems that did not exist beforehand. So, that is why my policy is always very conservative, and why I always examine the release notes of a new update to see if it is worth the time, effort, and the potential for "oops, the upgrade didn't go smoothly!" types of issues.

Don't get me wrong -- I am a big StarWind fan, but when I see posts that say things like "Upgrade to the latest release" without a "because this specific issue was a known issue, and is fixed in this release", I get a bit nervous.

darrellchapman · Mon Aug 23, 2010 8:46 pm

I don't mean to beat a dead horse but I agree with tulsaconnect as well. Updates, regardless of who they are from, should not be applied simply because they are available. Our whole vSphere network is reliant on our two StarWind HA unlimited nodes. I take the security and stability of these two boxes very, very seriously. These machines, for the most part, have no Internet access and I will only update them only if the software addresses a vulnerability or issue I've been having. We've had 60 employees sitting twirling their thumbs for two days because of a StarWind node issue before and that should NEVER happen.