Start a Conversation

Unsolved

This post is more than 5 years old

K

4172

February 16th, 2016 12:00

Failed:Add SDS device ScaleIO-XXX to Storage Pool(Unknown ScaleIO error)

I'm trying to deploy ScaleIO 1.32.  I have 4 nodes, with each having 3 146 gig drives, booting for SD cards.   If I was doing production I would do bigger, but I wanted to do see what ScaleIO can do.  I was able to get 2 nodes to deploy correctly.  However on the other 2,  I see messages like

Failed: Add SDS Device ScaledIO-XXX to Storage Pool StoragePool1(Unknown ScaleIO error) 3 times for the two hosts.

Where can I did in the logs to figure out what went wrong?  or better yet what do I need to do to try to fix it?

February 16th, 2016 12:00

How are you doing the deployment? Manual? or using Installation Manager?

What is the Operating System on the SDS nodes?

Is this an ESXi environment? or Windows or Linux?

51 Posts

February 16th, 2016 13:00

My suspicion is that connectivity is the issue.

As it's ESXi, check out the diagnostic steps in https://support.emc.com/kb/466097.

If you don't have access to that, you can find the same steps in a similar forum post: Deploy Scale IO error Configure SDC driver on ESX.

February 16th, 2016 13:00

Installation Manager,

I think it some Linux that was delivered in the OVA if I understand the pieces of scaleIO

They are running on ESXi 5.5 environment.

ScaleIO version is 1.32

February 16th, 2016 14:00

If you were running the deployment wizard and you encountered the error "Failed: Add SDS Device ScaledIO-XXX to Storage Pool StoragePool1(Unknown ScaleIO error)" 3 times for the two hosts, you may use putty to connect to the ScaleIO virutal Machine with Primary MDM role and after login, you may run the command manually to add the device

scli --add_sds_device (--sds_id |--sds_name

|--sds_ip )--device_path

[--device_name ] ((--storage_pool_name )

|--storage_pool_id ) [--test_time] [Test Options]

Example

scli --mdm_ip 192.168.1.200 --add_sds_device

-–sds_ip 192.168.1.6 --device_path /dev/sdb

--device_name sd02

once you have added the devices manually then you can continue with the deployment wizard.

60 Posts

February 17th, 2016 00:00

You've mentioned that your system boots from SD card.

Where did you deploy the SVM, you have to have at least one local datastore?

February 17th, 2016 14:00

Network connectivity was there. 

I have a data and a management network, both are 10 gig. The data network is an isolated network.

I decided to do a rollback and retried it all.  It saw all 12 drives.  I wished I didn't do a fault set, as I can't create a volume right now.  Any ideas on how to remove that?

I cheated when I deployed SVM, I put in on a LUN. being I was concerned about disk space.  I couldn't use the remainder space on Cisco SD card for some reason.

Being I only have 12  146 gig drives to test with. 

Do you think I should just do 3 servers instead of 4?  This only test environment.

Each server will then have 4 drives.  I could then install esxi to 1 146 drives still have room for svc on that drive.  Then still have 3 drives left for sharing data.

Do I even need a fault set?

About how long should it take to deploy?  Should it be more like 1-2 hours or closer toward 8 for a small deployment.

Thanks

51 Posts

February 18th, 2016 14:00

I have no issues with any of that 4-server hardware/config for a test setup, except that the fault sets will unnecessarily complicate things with that few of nodes. Performance-wise, you're fine running only one 10gig data network as I doubt 4 disks will saturate it.  I do recommend, though, getting used to configuring multiple NICs/subnets for data networks, as you'd want to do that in production. In this case, it just amounts to allowing ScaleIO to use (read: adding SDS IPs on, and SDC NIC/vSwitch/vmknics on,)  the management subnet as well as the "data" one.

You could install ESX to one of the internal disks, and choose VMDK instead of RDM for disk device presentation to the SVM. I'd create as big of a vmdk as you can feasibly put on the ESX-installed disk, the fact that it's smaller than the other disks presented to ScaleIO is a non-issue.  Doing this would let you provide the 30ish GB free space needed to comfortably store and deploy the SVM from template, while still contributing the spindle to the storage pool.

Deploy takes a while, especially with VMDK as you zero it out during deploy. 8 hours, though, without VMDK... I wouldn't expect that.

No Events found!

Top