麒麟系统通常无法直接修改系统 UUID，因为该标识由 BIOS/UEFI 固件提供，并通过内核以只读方式暴露给系统；如果强行篡改，往往会导致软件授权失效，甚至触发安全模块拦截。真正可以安全调整的，一般是硬盘分区或文件系统 UUID，例如可使用 tune2fs -U random /dev/sdb1 来重新生成分区 UUID。
在 CentOS 系统里，systemd 并不会生成或管理所谓的“系统 UUID”。大家常说的“系统 UUID”，通常实际上是指主板 SMBIOS 中的系统标识符（System UUID）。它与文件系统 UUID、网卡 UUID 以及 machine-id 都不是同一个概念。这个值由 BIOS/UEFI 固件提供，主要用于在硬件层面唯一标识一台物理服务器，或一个虚拟机实例。
怎么查询主板 BIOS 提供的 System UUID
要查看系统 UUID，直接读取 DMI 信息通常是最准确、最常用的方法：
运行 sudo dmidecode -s system-uuid，输出示例：4C4C4544-004B-5210-804E-B7C04F4D3430
- 必须使用
root权限，否则dmidecode可能报错、无权限读取，或直接返回空结果 - 在物理服务器上，这个值由主板 BIOS 写入；在 KVM、Xen、VMware 等虚拟化环境中，则通常由 hypervisor 模拟生成
- 部分精简镜像或云厂商定制版 CentOS 可能禁用了
dmidecode，或屏蔽了 DMI 数据，此时命令可能执行失败，或者返回Not Set
为什么用 blkid 或 lsblk 查不到“系统 UUID”
blkid 和 lsblk -f 只能查看块设备（例如 /dev/sda1）对应的文件系统 UUID，例如：/dev/sda1: UUID="a1b2c3d4-..." TYPE="ext4"
- 这里显示的是文件系统在格式化时生成的 UUID，与主板或系统硬件身份无直接关系
- 同一块硬盘在重装系统、重新格式化后，这类 UUID 往往会变化；但 DMI 中的主板 System UUID 一般保持不变，除非执行了 BIOS 重置，或虚拟机克隆后没有重新生成新的 UUID
- 把
/etc/machine-id误认为系统 UUID，是 Linux 和 CentOS 使用中的常见误区——它只是 systemd 用于本地服务识别的标识，可以重新生成，并不具备硬件唯一性
克隆虚拟机后 System UUID 相同怎么办
在 VMware、VirtualBox 等平台中，克隆虚拟机时默认可能继续沿用原有 UUID，这很容易导致监控系统、License 授权校验，或集群节点识别发生冲突。
- VMware：先关机，再编辑
.vmx文件，添加或修改uuid.bios = "564d...xxxx..."，然后重新开机 - KVM：可通过
virsh edit编辑虚拟机配置，在... - 不要试图直接用
uuidgen替换 DMI 中的值——Linux 内核本身并不提供写入 System UUID 的接口，若强行伪造，通常需要修改固件或调整启动参数，风险较高，也不建议在线上环境使用
如果你确实需要“系统级唯一标识”，首先要分清楚自己需要的是 BIOS 层面的硬件身份，还是 OS 层面的服务身份。两者在用途、来源以及生命周期上都完全不同，不能混为一谈。
