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

Hi,

Sushi.Pit@gmail.com wrote:

> 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.

-- 
Gerry Hickman (London UK)

On Jun 27, 11:02 pm, Gerry Hickman <gerry66...@newsgroup.nospam>
wrote:

> 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.


> 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)


> 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 ...


> 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.


> 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