Windows 2008 R2 Very Slow to Boot from SAN

Unanswered Question
Mar 18th, 2010
User Badges:

I have installed Windows 2008 R2 on a blade in a boot from SAN configuration. I loaded the Cisco Palo FCOE drivers during the install and it went through without a hitch.


After the install the reboots are painfully slow, like 15 minutes. After boot up performance is great and there are no issues. I have tried changing the FC Adpater Policy from Windows to default and even to VMware but it doesn't make a difference.


Anyone know if there is a solution to this slow boot time?


by the way I have an ESX 4 blade running with boot from SAN and it boots normally.


I have checked FC zoneing and Navisphere and can't figure out why it takes so long to boot.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
stechamb Fri, 03/19/2010 - 11:31
User Badges:
  • Bronze, 100 points or more

Jeremy,


(a) what array are you using?  Clariion?

(b) have you disabled quiet boot in the BIOS?  I haven't done this with Palo but if you can (like you can with Menlo) you might learn something useful

(c) there used to be a bug for Emulex adapters, I can check if there's anything related...

JEREMY WALDROP Fri, 03/19/2010 - 11:50
User Badges:

Steve, it is a Clariion CX4-120. I have disabled the quiet boot and I can see the Palo FC HBA driver load and it displayes the boot LUN, after that it goes to a black screen and sits there for around 15 minutes and then boots into Windows.


I am on firmware 1.1(1j), I could try to update but I haven't had a chance to try that yet.


thanks

stechamb Fri, 03/19/2010 - 12:49
User Badges:
  • Bronze, 100 points or more

I have heard of issues with the Clariion if the primary boot LUN is being accessed by the "wrong" storage processor, but I think this might be a long shot in your case though worth checking - if you can check on the clariion which SP pWWN is "owning" the boot LUN, you might check the boot policy and HBA settings to check the primary target is the owning SP.


It's friday night now for me so unlikely to find anything until next week - unless someone else pops along with an answer...

JEREMY WALDROP Fri, 03/19/2010 - 13:12
User Badges:

I checked all of that already, also when I did the initial install I only presented one path to the LUN. The slow boot started happening immediately after the install when only one path was presented to the blade.


I then presented all four paths and it still booted very slow. I even played with the Clariion failover modes changing it from 1 to 4 but nothing has any affect on the boot time.

Robert Burns Fri, 03/19/2010 - 15:05
User Badges:
  • Cisco Employee,

Jeremy,


When you registered your host on the Clariion, what "Initiator Type" did you use?


Robert

frazier24 Wed, 04/14/2010 - 13:55
User Badges:

Hey Steve,


I am experiencing the same issues, but with a different storage vendor.  We have 2008R2 with Palo, booting from SAN via MDS 9124s into a dual-head/filer NetApp 3140.  We're easily expeirencing 10+ minute boot from SAN.  Now, we have 2 x ESX4 with Palo, booting from SAN via the same infrastructure and NetApp filers, and they are booting just fine.  Any ideas other then the below?  Both Jeremy and I seem to have something in common..  Server 2008R2, Palo and boot from SAN.


Thanks


Lee

holbech Sun, 05/09/2010 - 01:30
User Badges:

Cheers Steve, Lee and others,


I'm seeing exacly the same issue on my UCS setup with palo. We use NetApp storage. ESX boot fine, but win2k8 takes forever.


Did any of you find a solution on this ?


Thanks


Claus Holbech

Jeremy Waldrop Sun, 05/09/2010 - 03:38
User Badges:
  • Silver, 250 points or more

No, I never found a resolution to this issue. Anyone at Cisco know what this could be?

frazier24 Tue, 05/11/2010 - 07:26
User Badges:

I had to open a case with TAC..  Bug ID CSCtg01880 is the issue..  a summary below.  Fix is end of May.


Symptom:

SAN Boot using Palo CNA for Window2008 takes 15~30 minutes everytime it boot.

Conditions:

This is due to incorrect bit set in FC frame.

Workaround:

User need to wait longer for OS to come up. Once OS comes up there will be no service impact.


Jeremy Waldrop Wed, 06/16/2010 - 04:15
User Badges:
  • Silver, 250 points or more

Firmware 1.3 fixes this issue, boot time went from 20 minutes to less than 3.

Actions

This Discussion