Snapdrive 6.1 - Vmware ESX 3.5 - slow startup

[kris_boeckx]

Hi,

I've the following issue:

When I upgrade snapdrive 6.0.2 to snapdrive 6.1 in a vmware guest os (windows 2003), the vmware guest will boot very slow.

As I suspected snapdrive, I can see that it takes a lot of time to start the snapdrive service by restarting the snapdrive and looking in the event viewer.

When I did a deeper inspection, I may conclude that snapdrive wants to talk to our virtual center and that's where it goes wrong. This will take about 5 minutes or longer. (I saw this when I did a repair of snapdrive 6.1 software and at the part where the setup connects to vmware, the timeout was seen)

Is there a way to debug this and see what's going wrong ?

Greetings,

Boeckx Kris

Pidpa

[tapesh]

Hi Kris,

There may be some network congestion. You can simply try to login to VC from VI-client and see if it takes similar time or you can simply try login to VC using browser from VM.

Thanks,

Tapesh.

[kris_boeckx]

Hi,

Loging in from vi-client or webconsole works fine. So no issue here.

Greetings,

Kris Boeckx

Pipda

[radek_kubka]

Hi Kris,

Yep, we've hit this as well - some bells are ringing that SnapDrive service dependencies are responsible for the problem.

Don't remember from the top of my head what the cure is, but I think setting  SnapDrive service to "Automatic (Delayed Start)" solves the issue.

Regards,

Radek

[satishv · Accepted solution]

Hi Kris,

Setting the "Remote Access Connection Manager" RasMan service as automatic should solve this problem.

Thanks,

~Satish

[kris_boeckx]

Hi,

This is the solution, thanks for that.

Is there an explanation for this ?

autch, that was a short turn around the corner

I thought the problem was solved but with the virtual center support not enabled, it's obvious that this was working.

I renenabled the virtual center support in the snapdrive setup and still got the problem.

I opened a case with netapp support and will come back with the solution

Greetings,

Kris Boeckx

Pidpa

[satishv]

SnapDrive uses web service to communicate with Virtual Center.

Initial login call takes time as web service framework tries to start all

the dependant services.

This behavior is seen only in windows 2003 Guest OS and Esx credentials

is provided.

Thanks,

~Satish

[pidpanow]

Satish,

I could understand "Initial login call takes time" but if I restart only the snapdrive service, it also takes about 5 minutes to start the service.

Greetings,

Boeckx Kris

Pidpa

[satishv]

What do the logs tell you? At which point of service startup is it taking up time?

~Satish

[kris_boeckx]

Hi,

Maybe stupid question, what log do I look for ?

In the netapp install directory, there are several ".log" files and several ".dat" files.

When I restart the snapdrive service, I see that the ".dat" files are updated (date modified) but they are unreadable.

the ".log" files are not written to.

Greetings,

Boeckx Kris

Pidpa

[satishv]

Are you able to ping the VC/ESX name that you registered with SDW ?

If you are able to ping, Can you try a restart of the SDW service and report the results again?

Thanks,

~Satish

[kris_boeckx]

Hi Satish,

I'm able to ping the virtual center server.

During the restart of the snapdrive service, I'm also able to ping (-t) the virtual center server.

responce time is <1ms

Greetings,

Kris Boeckx

Pidpa

[kris_boeckx]

Hi,

Netapp support accepted this as a bug in snapdrive 6.1.It seems that snapdrive takes his time to list all vmware datastores. This is causing the delay in the service / server startup.

They are working on a fix and this fix will be include in the next release of snapdrive.

I don't know when this release will go public.

Greetings,

Kris

[thorsten_busch]

Hi there,

we have a similar case here. Can you post the bug number, please?

Thanks,

Thorsten

[kris_boeckx]

Hi,

The bug number is 378160. I don't think the bug info is public available but you can refere to it when you open a case.

I was told that this bug will be fixed in SD 6.2. A release date of SD 6.2 is not available yet.

For the moment I'm using SD 6.0.2 in production and will not upgrade to SD 6.1.

Greetings,

Boeckx Kris

Pidpa

[thorsten_busch]

Kris,

thanks a lot! I do not see the bug (bug does not exist or was created within the last 24hrs). However, I will use it for opening a case.

can you doublecheck the number? 378160?

Regards,

Thorsten

[kris_boeckx]

Hi,

The bug (burt) number that I got from the netapp engineer is 378160.

Greetings,

Boeckx Kris

Pidpa

[tapesh]

There are couple(burt365786 and burt378160) of issues causing this behavior. So see which issue is causing at your place. Anyhow both issue got fixed and will be available in next SDW release.

Thanks,

Tapesh.

[GregKorten]

I believe I might be experiencing this on in two separate vmware environments using Snapdrive 6.2... I have about 70 RDM luns with about 8 Datastores.  Multiple clusters esx clusters, multiple filers.  I cannot even install snapdrive anymore on a any new VMs... My existing VMs seem OK.  After putting in the credentials for SnapDrive I have waited 2 + hours before getting to the next prompt for the snapdrive service credentials...

If I install snapdrive and instead enter root credentials for the specific ESX host the install goes with out issue and finishes in a couple of minutes.. ( ofcourse if the server vmotions snapdrive brakes so this is only a way ot test)

[kris_boeckx]

Hi,

I think you should open a case with netapp support as I still see some issues like your's with SD 6.2P1 ... SR 6.3 is comming but I don't know if the nasty behavour will be solved ...

Open up a case and give us some feedback.

Greetings,

Kris Boeckx

[thomas_glodde]

there is SnapDrive 6.2D3 as well, it includes P1 fixes and fixes the VMotion breaks SD service issues as well ...