crossed up disk ids on sql 2005 active/active/active cluster

[ellie]

Hello,

I have to deal with crossed disk ids after SQL 2005 SP2 was installed on one
of newely added shared disks.
on node A and B I have:
disk 13 - T drive
disk 14 - V drive
disk 15 - W drive

but on node C same 3 disks got different ids because of usb drive ( gone now )
disk 14 - T drive
disk 15 - V drive
disk 16 - W drive

Rescan did not fix the disk id . How to fix this? Any help will be greatly
appreciated.

Thanks,

[Justin Rich]

Im fairly sure SQL doesnt care about the disk numbers. It just cares about
the drive letters (check your cluster resources). Provided your T is the
same on all nodes its not a problem.

"ellie" <el...@discussions.microsoft.com> wrote in message
news:86096324-2A1C-423C...@microsoft.com...

[ellie]

I thought it is a must to have same disk ids for a LUN presented to cluster
nodes because MS clustering service controls a shared disk using disk id
(signature)

would presenting and unpresenting the 3 disks on node c fix disk ids or they
are "reserved" and cannot be changed?

[Justin Rich]

the disk signatures and disk id's are not the same thing. however, if you'd
like to change it you'll need to remove the LUNs from the system (change
zoning or whatever) and then reboot the box. once the box is back online you
can present the disks and they'll pick up new id's picking up where the last
one left off. I did this the other day and the ids changed but i wouldnt say
this is 100% going to work.

again the disk IDs and signature are not the same thing and the IDs shouldnt
matter.

if you had a problem with the signature you'd get an event 1034 with source
ClusDisk
http://support.microsoft.com/kb/243195

based on the info you've provided it sounds like some of the resources are
not configured correctly.

can you list out all of your resource groups and what resources are in them?

Justin

"ellie" <el...@discussions.microsoft.com> wrote in message

news:F1599A17-93A8-4176...@microsoft.com...

[ellie]

hello,

the new resource groups are:

prg273 SQL virtual machine ( fails over and back without any errors )

SQL Data Disk V
SQL Data Disk W
SQL IP Address 1 (prg273)
SQL Network Name (prg273)
SQL Server (INST07)
SQL Server Agent (INST07)
SQL Server Fulltext (INST07)

prg274 SQL Virtual Machine

SQL Data Disk T ( presented and owned by all nodes)

I can move t drive to all 3 nodes.

No errors or warnings in syslog. Rescan does work fine and produces no errors

BUT the disk IDs are crossed up

on node A and B I have:
disk 13 - T drive
disk 14 - V drive
disk 15 - W drive
>
but on node C same 3 disks got different ids because of usb drive ( gone
now )
disk 14 - T drive
disk 15 - V drive
disk 16 - W drive

And next reboot of node C might change disk ids and/or disk signatures
because we removed the usb drive

How to proceed to make sure after a reboot the shared disks will be still
controlled ok by MSCS?

[Russ Kaufmann]

"Justin Rich" <jric...@yahoo.spam> wrote in message
news:97FFE84F-2CA9-4157...@microsoft.com...

> Im fairly sure SQL doesnt care about the disk numbers. It just cares about
> the drive letters (check your cluster resources). Provided your T is the
> same on all nodes its not a problem.

You are absolutely right. SQL only cares about the drive letters or the
mount points being the same between the nodes.

--
Russ Kaufmann
MVP, MCT, MCITP x7, MCTS x9, MCSE x4, CTT+
ClusterHelp.com, a Microsoft Gold Certified Partner

Email:ru...@clusterhelp.com
http://www.clusterhelp.com
Blog: http://msmvps.com/clusterhelp

[Justin]

what do you mean T is owned by all nodes?

please list out all old and new resource groups and what resources are in
them.

open command prompt on a node and type in cluster resource
it will list out all resource names and what group they are part of. If the
resource name isnt obvious as to what it is please provide the resource
type.

I still think it has something to do with how the cluster is setup and not
the disk ID/sig's

also, as far as the ID's you can modify it with the system online. the only
way I could do it was to remove the disks while the system is on (remove
them from the zone) and then reboot the servers and then assign the disks to
the servers again once they have been rebooted and are online... but again,
this is going to work 100% of the time

Justin

"ellie" <el...@discussions.microsoft.com> wrote in message

news:4E143B8C-C610-4CC8...@microsoft.com...