在铲除已有的系统环境重新安装CentOS时，可能会出现无法识别到可用磁盘，导致安装中断。出现这种情况的原因可能是因为这些磁盘分区中包含了特殊的BIOS RAID元数据，一旦原配置丢失或损坏，即便该盘实际上已不在RAID组中，也无法被操作系统调用，这种状态为“Fake RAID”状态。
对于CentOS 6，安装程序会给出如下提示信息：
Disk sd* contains BIOS RAID metadata, but is not part of any recognized BIOS RAID sets. Ignoring disk sd*
对于CentOS 7，安装程序会直接忽略该类磁盘，无法识别成可用磁盘。
NetApp ONTAP支持通过SSL方式提供Web访问或API接入管理控制台。在磁盘阵列首次初始化完毕后，系统会自动生成一张有效期1年的自签名证书供SSL访问用。在过期后，该证书并不会被自动续签，可能导致Web浏览器访问受阻或第三方应用（如：OnCommand Unified Manager）通信异常。此时，可以手动签发一张时效更长的新证书，来替换过期证书。
0. SSH登陆相应的磁盘阵列。
1. 进入高级权限模式：
当Nutanix集群中某一节点的CVM遇到操作系统故障无法启动时，可以尝试通过救援镜像恢复CVM服务，而无需重刷整个节点。
风险说明：CVM作为节点存储控制器，异常的恢复操作可能导致所在节点上的数据不可用或元数据损坏。如果无法确定是否能通过该方式恢复CVM，建议将该节点强制踢出集群再重新加回。踢出集群的步骤请参阅：https://portal.nutanix.com/kb/2379
以下操作基于AOS 5.5+ESXi 6/6.5环境。所涉及的相关CVM配置项请根据实际情况修改。示例如下：
Dell XC系列服务器板载的Satadom卡为放置ESXi等虚拟化操作系统核心的存储所用。部分旧版的固件可能导致在主机重启后Satadom不可访问，从而导致无法进入系统。此时需要考虑升级固件，预防Satadom读写故障。
1. 确认当前Satadom固件版本：在ESXi中执行如下命令：
$ esxcli storage core device list| grep -A4 Path
返回结果如下：
MySQL在5.5版本后引入了更高级的InnoDB表处理引擎，其支持以表为单位创建独立的表空间文件。但是在5.5版本中，该特性默认为未启用；或者低版本升级上来的数据库，表引擎从MyISAM转换为了InnoDB，其表空间依旧为共享类型。
随着表数据量的不断增长，这张共享的表空间大小也会随之变大。有别于独立表空间文件，共享表空间文件并不能通过OPTIMIZE TABLE方式进行释放，所以当物理空间不足时，需要通过一次完整的导出导入操作来降低高水位，释放物理空间。同时，建议一并进行表空间类型切换，方便后续维护管理。
MySQL表空间文件（一般为ibdata1）占用过多的物理空间，但实际表的数据大小已经小于表空间所分配的大小，表空间占用无法得到释放。且经查，数据库的表空间使用类型为“共享”。