Kickstart 仅支持安装时静态定义 LVM 结构，通过 part 和 logvol 指令预设 PV/VG/LV；扩容需部署后用 pvcreate/vgextend/lvextend 等命令完成，因 Kickstart 不感知运行时磁盘变更。
服务器系统安装时用 Kickstart 脚本自动配置 LVM，核心是把分区逻辑写进 ks.cfg 文件，让 Anaconda 安装程序在部署阶段直接创建 PV/VG/LV 结构；后续存储扩容则不在 Kickstart 阶段执行，而是通过部署后脚本或运维流程完成——因为 Kickstart 只管初始安装，不处理运行时的磁盘变更。
Kickstart 中定义 LVM 分区结构
Kickstart 不支持动态计算或条件判断，所以 LVM 的 VG 名称、LV 大小、文件系统类型等都得预先写死。关键语法是 part 和 logvol 指令：
-
part pv.01 --size=1 --grow：声明一个物理卷分区，从剩余空间中尽可能占满（--grow表示自动扩展） -
volgroup vg_data pv.01：将该 PV 加入名为vg_data的卷组 -
logvol / --vgname=vg_data --size=20480 --name=lv_root --fstype=xfs：在vg_data中创建 20GB 的根逻辑卷，格式化为 xfs -
logvol /home --vgname=vg_data --size=1 --grow --name=lv_home：让/home占用 VG 剩余全部空间 - 务必搭配
clearpart --all --initlabel清空目标磁盘，否则旧 LVM 元数据可能干扰新布局
为什么 Kickstart 不能做存储扩容
Kickstart 是一次性安装配置工具，只在系统首次启动前执行。它无法感知后续新增硬盘、也不运行在已安装系统的上下文中，因此以下操作不属于 Kickstart 职责范围：
- 识别并添加新硬盘（如
/dev/sdc）到现有 VG - 执行
pvcreate、vgextend、lvextend等命令 - 调用
xfs_growfs或resize2fs刷新文件系统
这些必须由部署后脚本、Ansible Playbook 或运维平台在系统上线后触发，且需确保目标 LV 已挂载、VG 有足够空闲 PE。
推荐的扩容落地方式
真正实用的扩容流程，应与 Kickstart 解耦，形成可复用、可验证的运维动作：
- 新增硬盘后，用
lsblk或fdisk -l确认设备路径（例如/dev/sdb） - 执行三步命令链：
pvcreate /dev/sdb && vgextend vg_data /dev/sdb && lvextend -l +100%FREE /dev/vg_data/lv_home - 根据文件系统类型选择刷新：
xfs_growfs /home（XFS）或resize2fs /dev/vg_data/lv_home（ext4） - 建议将上述步骤封装为 shell 脚本，并加入健康检查（如
vgs --noheadings -o vg_free vg_data判断是否真有空闲空间） - 若使用 Ansible，可用
lvol模块统一管理 LV 大小，比手动写命令更安全可控
注意事项与避坑点
LVM 自动化容易忽略底层约束，实际部署中需盯紧这几项：
- PE 大小影响精度：Kickstart 创建 VG 时若未指定
-s，默认为 4MB；若后续要扩非常小的 LV（如 5MB），会因非 PE 整数倍失败 - XFS 不支持缩容：Kickstart 若把
/设为 XFS + 固定大小，后期发现空间不足只能扩，不能减——设计阶段就该预留 buffer 或用--grow - Boot 分区不能放 LVM：
/boot必须是标准主分区（part /boot --fstype ext4 --size=1024），否则 GRUB 无法读取内核 - 快照功能虽好，但 Kickstart 不支持自动创建；如需备份能力，应在部署后脚本中补上
lvcreate -s步骤
