VSAN 7 a capacity device showed degraded and it seems VSAN has automatically evacuated it. cool!
Compression & Dedup is not enabled by the way, so no worries there
But a new disk is on order and we are not sure if the option to "Remove Disk" needs to be selected on the existing one, and if so which migration mode?
I was under the impression that the disk removal in the GUI (or esxcli) is done to evacuate the disk.
But right now the disk shows evacuated and if I run a pre-check on the naa.<deviceguid> any of the modes selected, I see
"No objects will be directly affected by the operation"
Do I then remove the disk and then scan for the new one when it is inserted? and if so with "No Data Migration" or still the preferred "Full Data Migration"?
@goodrz You don't need to remove the disk to add the replacement one (unless Disk-Group already has the max 7 Capacity-tier devices. But yes you should remove that to clear the operation health disk alert in health - probably only "No Data Migration" will work, this is fine if all data has already been resynced elsewhere and data health check is green.
cheers thanks GSS advised the same I managed with Accessibility Mode as well as everything was evacuated. But I will need to Add the replace ment disk after it is physically switched c devices neeorrect? possibly a rescan on the storage device is needed as well
Run the command :::::::::: Disk CMMDS output with more Device information and capacity or SSD informaiton.
esxcli vsan storage list | grep -e CMMDS -e Device -e Capacity -e SSD | sed 'N;N;N;s/\n/ /g'
Device: naa.50000398a8090c11 Is SSD: false In CMMDS: true Is Capacity Tier: true
Device: naa.50000398a8090885 Is SSD: false In CMMDS: true Is Capacity Tier: true
Device: naa.50000398a8090f1d Is SSD: false In CMMDS: true Is Capacity Tier: true
Device: naa.50000398a8090ce5 Is SSD: false In CMMDS: true Is Capacity Tier: true
Device: naa.50000398a8091061 Is SSD: false In CMMDS: true Is Capacity Tier: true
Device: naa.58ce38ee2025d361 Is SSD: true In CMMDS: true Is Capacity Tier: false
Device: naa.58ce38ee2025cc81 Is SSD: true In CMMDS: true Is Capacity Tier: false
if the cmmds is true not false then , MM mode reboot should fix the problem.
you can also evacuate the disk group via cli and gui both.
run this command to find if the capacity drive is reporting hardware failure .
cat /var/log/vobd.log | grep -i "permanent\|transient\|reset"; cat /var/log/vmkernel.log | grep -i reset
if you permanent or reset error . then just reboot should fix it. with ensureAccessiblity .
if still persist then remove the disk and re-add it .
@Ray786 Yes, you will need to add the replacement device to the existing Disk-Group (as autoclaim feature was removed quite some time ago) - note that some disks/controllers don't support hot-add/hot-swap and/or don't support this as reliably as might expect, so do of course try rescan but if you note anything off (e.g. device doesn't get a path in NMP and doesn't show up or is not able to write the vSAN partitions during disk claim) then Maintenance Mode and cold-reboot may be needed.
@goodrz , Yes a new device should have a new naa assignment. That being said I had a customer show me something I have never seen before recently where devices had been swapped (confirmed with different serial numbers) and had same naa. - seemingly there is something different with some HPE servers where they generate these from the server slot or something to that effect.
hmm interesting. My swap out worked as expected but there was a time gap between removal of the dead device and the new device showing up even after rescan and refresh. I was concerned that I might need an MM and restart! but I waited 30 minutes then I clicked on claim ununsed disk it eventually showed up in there, so I cancelled and went into add disk and added it. job done. I had an Powercli excel output of all the devices prior to this to be sure and do a before and after
I waited 30 minutes, but it might have been there much earlier.
Thanks I guess that is my VSAN swap out virginity busted 🙂