GetFCPTargetMapping - multiple LUs mapped from multiple storage sub-systems

[S***@gmail.com]

I'm attempting to use GetFCPTargetMapping (http://msdn2.microsoft.com/
en-us/library/ms806849.aspx) against an HBA which can see multiple LUs
from multiple sub-systems. I had expected that all LUs regardless of
the sub-system would be listed, however I only get back the LUs from
the first connected sub-system. I've been reading and re-reading the
documentation, but to no avail. There appears no way to include or
move onto the 'next' sub-system.

Has anyone out there any experience of using the method, either
through the WMI extensions or direct to the drivers. I'm begining to
think this may be an MS error, but need to find a suitable way to
prove if it is!

All coding is currently in VB.Net 2005 using strongly types classes
(mgmtclassgen).

Sush

[Gerry Hickman]

Hi,

Post by S***@gmail.com
I'm attempting to use GetFCPTargetMapping (http://msdn2.microsoft.com/
en-us/library/ms806849.aspx) against an HBA which can see multiple LUs
from multiple sub-systems.

Yikes, are we talking LVM (Logical Volume Manager) style technology
here, fibre connected JBODs arranged into logical volumes with redundancy?

Yikes #2, are you seriously considering putting Microsoft software in
charge of this??

I spent a short time with Microsoft's interfaces to enterprise storage
management and found it to be buggy, but there was no point reporting
it, as they'd need the exact same racks of equipment as me to even see
the problem and they can't even fix the basics like StdRegProv and MSI
so what are the chances of them knowing how to fix this (if it's even
broken!)

Have you considered Linux? They appear to have an excellent
understanding of block-level storage and NTFS, and the beauty of it is
that they have forums with experts who are happy to debug right down to
individual sectors, plus you have the source code.

The problem I find with the Microsoft WMI providers, is that you can't
debug into the source code, so when you suspect a bug, it takes days to
confirm it and even after you have confirmed it, you can't fix it, and
you can't get Microsoft to fix it either, so it just stays broken.

I found at least one bug in the Vista SCSI WMI enumeration, works fine
on Win2k on same box, but no point reporting it unless they've got the
same HBA and disk config as me.

[S***@gmail.com]

Post by Gerry Hickman
Yikes, are we talking LVM (Logical Volume Manager) style technology
here, fibre connected JBODs arranged into logical volumes with redundancy?

Not really, the SAN disk is managed elsewhere - with other software -
this is just an exercise in centralised/consolidated reporting.

Post by Gerry Hickman
Yikes #2, are you seriously considering putting Microsoft software in
charge of this??

Again, not really. The Microsoft software isn't in charge of anything,
this is just one potential source of data that is to be cross
validated against others. I've seen the results from plenty of
commercial tools and know not to rely on a single data source! If the
WMI extensions can't be persuaded to talk correctly, then I'll
probably go back to hitting the HBAAPI directly for this particular
data feed (currently re-writing some modules and thought I'd try it
this way as it seems a little more 'elegant' - hence the question)

Post by Gerry Hickman
Have you considered Linux? They appear to have an excellent
understanding of block-level storage and NTFS, and the beauty of it is
that they have forums with experts who are happy to debug right down to
individual sectors, plus you have the source code.

I'm currently reviewing sourcing the data from some Windows servers.
In due course I'll also be doing the same thing on some Linux
servers ...

Post by Gerry Hickman
The problem I find with the Microsoft WMI providers, is that you can't
debug into the source code, so when you suspect a bug, it takes days to
confirm it and even after you have confirmed it, you can't fix it, and
you can't get Microsoft to fix it either, so it just stays broken.

Prior to this, I've found WMI to be pretty good, just needed to work
around various missing/corrupted fields. but in a farm of around 800
servers I guess that is to be expected. In this case, MS are coding to
fit a standard interface to a number of third party drivers. As I've
found when validating the HBAAPI against various suppliers and
differing drivers levels, the third party 'bits' are of variable
quality.

Post by Gerry Hickman
I found at least one bug in the Vista SCSI WMI enumeration, works fine
on Win2k on same box, but no point reporting it unless they've got the
same HBA and disk config as me.

Always worth reporting it even if you can't expect a fix. At some
point if multiple people report it, then you might get the critical
mass that does drive a fix.

Cheers,

Sush