Giving up: Cannot see anything in Disk Management

Initiator (iSCSI, FCoE, AoE, iSER and NVMe over Fabrics), iSCSI accelerator and RAM disk

Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)

Post Reply
cdevidal
Posts: 7
Joined: Sat Aug 02, 2008 11:07 pm

Sun Aug 03, 2008 10:05 pm

Summary: Even though two AoE vblade targets show up in StarPort, nothing is seen in Disk Management. I even created a RAM drive and it doesn't show up.


I have a serious problem for which I need a SAN. It's 6:40p on a Sunday afternoon and I really need to get this thing working, so I'm giving up on StarPort and downloading the Openfiler 2.3 ISO, with its built-in iSCSI target. I will use the Microsoft iSCSI initiator.

I'm only giving you this information so you can troubleshoot and prevent frustrated customers.


Details:
StarPort: Professional 3.6 Build 0x20080410
Initiator 1 with the problem: Windows 2003 Enterprise with latest patches, updates, drivers and firmware (fresh install)
Initiator 2 working fine: Windows 2003 Standard
Target: vblade-18 on CentOS 5.2

I ran three vblades going to three different partitions, none of which is larger than 2TB. At first I could only mount one vblade at a time on the first initiator server; after I rebooted it I could no longer see any vblades in Disk Management.

I rebooted, uninstalled/reinstalled StarPort, same problem. I actually had this problem yesterday, and when I reformatted and reinstalled Windows last night the problem went away for a while, until I tried to mount the second vblade and the problems began.

Even if I install a RAM drive, nothing shows up.

I see nothing unusual in the Event Viewer.

And again, the second server attached to the same SAN works fine.

In case it matters, the broken server is multipath-aware; that is, it has 2 SCSI cards connected to an external array and if one of the two cards or ports on the array fails it will switch over automatically. Don't know if that affects StarPort. That's about the only unusual thing about this server; otherwise it is normal. I'm not going to go through the trouble of uninstalling Multipath and trying it again, would take a while and I'm very tired. Must move on.
Last edited by cdevidal on Mon Aug 04, 2008 5:54 am, edited 1 time in total.
-- Chris de Vidal

You're a good person? Yeah, right ;-)
Prove it: TenThousandDollarOffer.com
cdevidal
Posts: 7
Joined: Sat Aug 02, 2008 11:07 pm

Mon Aug 04, 2008 5:54 am

Update: iSCSI was way too CPU-intensive for the target, so I'm back to StarPort. Working like a dream now.

That HP Multipath software must be buggy, but there isn't a newer version so I'll just have to pass on it and hope we don't lose a SCSI card. Bummer that we paid extra for the functionality...
-- Chris de Vidal

You're a good person? Yeah, right ;-)
Prove it: TenThousandDollarOffer.com
aaron (staff)
Posts: 70
Joined: Fri Jan 11, 2008 6:13 am
Location: BVI

Mon Aug 04, 2008 5:20 pm

Summary: StarPort was not the one to blame. Nice to know this!

On your place I'd go for iSCSI but commercial target. Modern NICs do offload TCP in such a perfect way you should not see any slowdown b/c of the extra TCP and IP stacks processing. So using CoRAID shelves + StarPort makes sense (b/c of CoRAID & RDS support). Using freeware and unsupported vblade + StarPort... Probably not!
Regards,
Aaron Korfer

Sales & Support
Rocket Division Software
Post Reply