答案是：可以组成集群（Cluster），但无法直接实现自动化的 HA（高可用）功能。
这是一个非常关键的技术瓶颈。在 Proxmox VE (PVE) 中，HA 的核心前提是 “数据共享”。如果节点 A 挂了，节点 B 必须能拿到节点 A 上的虚拟机磁盘数据。
你的 VPS 使用的是 LVM 或 独立 EXT4 分区，这属于“本地非复制存储”。以下是深度解析及解决方案：
1. 为什么“不同格式的本地磁盘”做不了 HA？
- 数据孤岛：LVM 卷或 EXT4 文件夹里的磁盘镜像（
.raw或.qcow2文件）只存在于该物理服务器的硬盘上。 - 同步缺失：PVE 自带的实时 HA 复制功能（Replication）是专为 ZFS 设计的。LVM 和 EXT4 不支持这种每分钟一次的增量块级同步。
- 结论：如果你强行开启 HA，当节点 A 宕机时，节点 B 虽然收到了重启虚拟机的指令，但它一看自己的硬盘：“诶？虚拟机的磁盘文件不在这儿啊！” 于是启动失败，HA 宣告无效。
2. 跨格式/跨区域实现 HA 的 3 种折中方案
既然你目前是 LVM 和 EXT4 混搭，且有 150ms 延迟，你可以通过以下方式曲线救国：
方案 A：使用 GlusterFS (分布式文件系统) —— 适合 EXT4/LVM
你可以在所有节点的 EXT4 分区上创建一个大文件，然后把这些文件组建成一个 GlusterFS 卷。
- 做法：在 PVE 存储里添加 GlusterFS。
- 优点：它不挑底层格式，LVM 还是 EXT4 都能跑。
- 致命伤：150ms 的延迟会毁掉它。GlusterFS 是强一致性同步，150ms 的延迟意味着你虚拟机里写一个 1KB 的文件，都要等远端节点确认，你的虚拟机系统会卡得像幻灯片。
方案 B：放弃本地格式，改用虚拟 ZFS (推荐)
这是在 VPS 环境下最稳妥的做法：
- 做法：在现有的 LVM 或 EXT4 分区上，创建一个巨大的文件（比如
zfs.img），然后将其挂载为环回设备，并在上面建立 ZFS 池。 - 结果：这样你的 PVE 就以为自己拥有了 ZFS 存储，从而开启 ZFS Replication 功能。
- 优点：支持异步同步，能完美克服 150ms 的高延迟。
方案 C：利用 Proxmox Backup Server (PBS) 异地恢复
如果你不追求“自动瞬间切换”，而是“数据不丢”：
- 做法：在 8C 节点或第三方节点搭建一个 PBS。
- 流程：所有节点定时向 PBS 备份。如果 A 挂了，你手动在 B 上点“从备份恢复”。
- 优点：最稳定，不挑磁盘格式，不挑网络延迟。
3. 加入集群时的注意事项
即使不做 HA，不同格式的节点组成集群也有意义（统一管理），但要注意：
| 差异点 | 处理建议 |
|---|---|
| 存储 ID 必须一致 | 虽然底层一个是 LVM 一个是 EXT4，但在 PVE 存储设置里，它们的 ID 必须都叫 local-data (举例)。否则 VM 迁移时会找不到路径。 |
| 磁盘镜像格式 | EXT4 通常存 .qcow2，LVM 通常存 .raw。迁移时 PVE 会尝试转换格式，这会消耗大量 CPU 并在跨地域传输时非常缓慢。 |
| ISO 镜像库 | 建议在所有节点上创建一个同名的目录（如 /var/lib/vz），用于存放安装系统的 ISO，否则安装时会报错。 |
4. 总结与建议
如果你一定要在这堆机器上实现 HA：
最省事的办法是重装系统或调整分区，将所有 VPS 的空余空间都统一划为 ZFS。只有存储格式统一为 ZFS，你才能利用 PVE 的异步复制机制，跨越 150ms 的公网延迟实现真正的自动故障转移。