04-21-2021 11:01 AM
Hello everyone,
Today, I added two additional disks to the empty slots in my three HXAF220c M5SX servers to expand the total HX storage space. We added the disks without shutting down the server. The disks are exactly the same as the disks currently located on the servers. I see additional disks on UCS Manager but HX Connect itself did not do the expansion. The capacity is still the same. I did decommission and recommission of one server but it is still the same condition.
Does anyone know if something extra needs to be done after adding disks to servers?
Best regards,
Milos
04-21-2021 11:24 AM - edited 04-22-2021 04:46 AM
As noted, you 'should' only need to uniformly install the disks on all nodes, in the same disk slots.
From CLI, run hxcli node list
Does the CLI show the right amount of disks?
Log into each node and run: sysmtool --ns disk --cmd list | grep -ia state
/dev/sdb (housekeeping drive) will be ignored by default, but the others should say 'CLAIMED' for state.
Am interested to see if it shows 'ignored' for the newly added disks.
Kirk...
04-22-2021 09:36 AM
Hello Kirk,
Thank you very much for your response. You're right, new disks are in a state of ignored on all servers.
sysmtool --ns disk --cmd list | grep -ia state
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: IGNORED
Runtime State: None
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: CLAIMED
Runtime State: None
Medium: SOLIDSTATE
State: IGNORED
Runtime State: None
Medium: SOLIDSTATE
State: IGNORED
Runtime State: None
Do you have any recommendation on what to do to change that?
Best regrds,
Milos
04-22-2021 05:10 PM - edited 04-22-2021 05:12 PM
Get the output of the disk slot mapping file:
cat /var/log/springpath/diskslotmap-v2.txt
The last couple of entries will probably be your new drives, and the right column will show the linux device name (i.e. /dev/sdi)
The far left column will show the disk slot (#8):
1..8:5000c50084e3354f:SEAGATE:ST1200MM0088:Z4002Z6J0000R625JL60:N0A4:SAS:10500:1144641:Active:/dev/sdi
Use the device name in command : fdisk -l /dev/sdi
If you see it listing some partition on it, then the drives may have had test/diagnostic partitions left on them, which will cause the 'ignore' status.
There is a command to clear the partition table off of them, but I would rather you call in to TAC and let them confirm this is the scenario you are hitting.
Kirk...
04-22-2021 11:34 PM - edited 04-22-2021 11:34 PM
Hi Kirk,
Thank you. Here is the command output for my new disks:
1..9:500a075129a51850:MICRON:Micron_5200_MTFDDAK960TDC_SED:203129A51850:D1MH027:SATA:SSD:915715:Active:/dev/sdk
1..10:500a075129a4b76b:MICRON:Micron_5200_MTFDDAK960TDC_SED:203129A4B76B:D1MH027:SATA:SSD:915715:Active:/dev/sdj
root@SpringpathControllerLFFE45B17P:~# fdisk -l /dev/sdk
Disk /dev/sdk: 894.3 GiB, 960197124096 bytes, 1875385008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
root@SpringpathControllerLFFE45B17P:~# fdisk -l /dev/sdj
Disk /dev/sdj: 894.3 GiB, 960197124096 bytes, 1875385008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
So, to solve this problem I neet to open a case with Cisco?
Best regards,
Milos
04-23-2021 04:45 AM - edited 04-23-2021 05:24 AM
Appears you have SED capable drives.
I would open a TAC case. I don't see any partitions listed on the drives, so it doesn't appear to be that issue.
Can you post a couple of other lines of working drives from the diskslotmap-v2.txt file?
Also, post the output from
lsscsi
lsblk -o PHY-SEC,LOG-SEC,kname
What HX version are you running?
Thanks,
Kirk...
04-24-2021 09:30 AM
Hi Kirk,
This command shows that the disks I added to the servers are MICRON 5200 and the existing disks in the servers are MICRON 5100:
cat /var/log/springpath/diskslotmap-v2.txt
1..1:5002538c408e37c1:Samsung:SAMSUNG_MZ7LM240HMHQ-00003:S3LKNX0JB04307:GXT51F3Q:SATA:SSD:228936:Active:/dev/sdb
1..2:5000c50030236ab3:MICRON:S650DC-800FIPS:ZAZ15DNB0000822150Z3:MB19:SAS:SSD:763097:Active:/dev/sdf
1..3:500a0751190517d8:MICRON:Micron_5100_MTFDDAK960TCB_SED:1739190517D8:D0MU049:SATA:SSD:915715:Active:/dev/sdd
1..4:500a0751190513ca:MICRON:Micron_5100_MTFDDAK960TCB_SED:1739190513CA:D0MU049:SATA:SSD:915715:Active:/dev/sde
1..5:500a075119058f5b:MICRON:Micron_5100_MTFDDAK960TCB_SED:173919058F5B:D0MU049:SATA:SSD:915715:Active:/dev/sdk
1..6:500a075119058f00:MICRON:Micron_5100_MTFDDAK960TCB_SED:173919058F00:D0MU049:SATA:SSD:915715:Active:/dev/sdh
1..7:500a075119058f49:MICRON:Micron_5100_MTFDDAK960TCB_SED:173919058F49:D0MU049:SATA:SSD:915715:Active:/dev/sdj
1..8:500a075119058fd6:MICRON:Micron_5100_MTFDDAK960TCB_SED:173919058FD6:D0MU049:SATA:SSD:915715:Active:/dev/sdg
1..9:500a075129a4d591:MICRON:Micron_5200_MTFDDAK960TDC_SED:203129A4D591:D1MH027:SATA:SSD:915715:Active:/dev/sdi
1..10:500a075129a5195a:MICRON:Micron_5200_MTFDDAK960TDC_SED:203129A5195A:D1MH027:SATA:SSD:915715:Active:/dev/sdc
I found / read somewhere that it is not good to mix 5200 disks with 5100 disks before 3.5. (2b) versions of hyperflex. I don't know if that's true so I took the disks out of the server yesterday and currently I can't give information for the above commands (
lsscsi
lsblk -o PHY-SEC,LOG-SEC,kname).
My version of hyperflex is 3.0 (1e). I am aware that I am on an older version of hyperflex.
Do you maybe know if the problem is a version of hyperflex or maybe disks?
Over the next week I plan to open a TAC case.
Thanks,
Milos
04-25-2021 04:39 AM - edited 04-25-2021 09:24 AM
Ah, mixing 5100,5200 models, can cause all kinds of trouble if you are not on 3.52b or above.
Once you get upgraded (hopefully to something newer like 4.02e), then adding the 5200 model drives, will happen without issue.
Probably fortunate that the drives didn't get fully added. See https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvk17250
Kirk...
04-26-2021 03:27 AM
Hi Kirk,
Thank you very much.
Yes, we were lucky :). We could have compromised the operation of hyperflex storage.
The plan is to upgrade the hyperflex to a higher version. When I do all that, I will come back here to write if the problem is solved, it may be helpful to someone who is in a similar situation as me :).
Regards,
Milos
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide