主机系统管理

仓库是一组软件包集合，可用于安装新软件，也是获取安全更新、错误修复和新功能的重要来源。

DNF 仓库定义在 /etc/yum.repos.d/ 目录下的 .repo 文件中。每个仓库通常包含 baseurl、enabled、gpgcheck、gpgkey 等字段。

PXVIRT 软件包通过梨儿方 PXVIRT 仓库发布。请在每个 Proxmox VE 节点上创建 /etc/yum.repos.d/pxvirt.repo：

也可以使用编辑器创建该文件：

配置完成后，刷新软件包元数据：

如果需要确认仓库是否已经启用，可以运行：

PXVIRT 的 openEuler 版本不使用 Proxmox 的独立 Ceph 仓库。 不要沿用 Proxmox 文档中的 enterprise、no-subscription 或 test Ceph 仓库地址。

如需安装或更新 Ceph 相关软件包，请使用已配置的 openEuler 基础仓库和 PXVIRT 仓库。 如果使用外部 Ceph 集群，只需要按存储章节配置客户端连接信息。

PXVIRT 仓库启用了 gpgcheck=1，DNF 会使用 gpgkey 指定的 GPG 公钥验证软件包签名。 如果密钥尚未导入，首次安装或更新软件包时，DNF 会提示导入该密钥。

也可以手动导入仓库密钥：

ßß ==== 常用命令示例 ß 以下命令可用于刷新软件包索引、查看可升级软件包，并检查 Proxmox VE 软件包版本：

安装所有可用更新：

本节适用于所有设备。更新后的微码通常包含在 BIOS/UEFI 更新中，并存储在主板上； 其他固件则存储在相应设备上。这种持久化方式对 CPU 尤其重要，因为它允许在启动时尽早按常规流程加载更新后的微码。

请向厂商确认可用的更新方法。

在 openEuler 中，可以通过 fwupd 软件包使用 LVFS 提供的固件更新。 如果系统未能自动识别 EFI 分区位置，可以在 /etc/fwupd/daemon.conf 中显式配置正确的挂载点，例如：

此方法将固件存储在 Proxmox VE 操作系统中；如果设备的 持久化固件版本较旧，则会将该固件传递给设备。 该方法受网络卡、显卡等设备支持，但不适用于依赖持久化固件的设备，例如主板和硬盘。

在 Proxmox VE 中，常见硬件所需的运行时固件由 openEuler 的 linux-firmware 软件包提供。因此，通过常规的 系统更新， 常见硬件所包含的固件会自动保持最新。

如需额外固件，请确认已经启用相应的 openEuler 软件源。

如果尝试安装额外固件软件包但发生冲突，DNF 将中止安装。特定固件也许可以通过其他方式获取。

微码更新用于修复已发现的安全漏洞和其他严重 CPU 缺陷。虽然 CPU 性能可能受到影响， 但已打补丁的微码通常仍然比由内核自行执行缓解措施的未打补丁微码具有更好的性能。 根据 CPU 类型不同，如果不有意让 CPU 运行在不安全状态，可能无法再达到存在缺陷的出厂状态下的性能结果。

要查看当前 CPU 漏洞及其缓解措施概览，请运行 lscpu。只有当 Proxmox VE 主机 保持最新、版本尚未 结束生命周期，并且自上次内核更新以来至少重启过一次时， 当前真实世界中已知的漏洞才会显示出来。

除了推荐通过 持久化 BIOS/UEFI 更新来更新微码之外， 还可以使用一种独立方式：早期 OS 微码更新。这种方式使用方便， 在主板厂商不再提供 BIOS/UEFI 更新时也很有帮助。无论使用哪种方法，应用微码更新都始终需要重启。

查看 CPU 漏洞和缓解状态概览：

查看当前正在运行的微码修订版：

Proxmox VE 不会将更改直接写入 /etc/network/interfaces。相反，系统会写入名为 /etc/network/interfaces.new 的临时文件，这样可以一次完成多项相关更改。这也允许在应用前确认更改是否正确，因为错误的网络配置可能导致节点无法访问。

当前设备名称使用以下命名约定：

这样更容易调试网络问题，因为设备名称能够体现设备类型。

可以根据当前网络组织方式和可用资源，选择 bridged、routed 或 masquerading 网络配置。

Bridge 类似于用软件实现的物理网络交换机。所有虚拟客户机可以共享一个 bridge，也可以创建多个 bridge 来隔离网络域。每台主机最多可以拥有 4094 个 bridge。

安装程序会创建一个名为 vmbr0 的 bridge，并将其连接到第一块 Ethernet 网卡。/etc/network/interfaces 中的对应配置可能如下：

虚拟机的行为就像直接连接到物理网络一样。反过来，网络会将每台虚拟机视为拥有自己的 MAC，即使所有这些虚拟机实际只通过一根网络线缆连接到网络。

大多数托管服务提供商不支持上述配置。出于安全原因，一旦检测到单个接口上存在多个 MAC 地址，它们就会禁用网络。

可以通过将所有流量经由单个接口“路由”来避免该问题。这可以确保所有网络数据包都使用同一个 MAC 地址。

常见场景是拥有一个公网 IP（本例假设为 198.51.100.5），并为虚拟机拥有一个额外 IP 段（203.0.113.16/28）。对于此类情况，建议使用以下配置：

Masquerading 允许只有私有 IP 地址的客户机通过主机 IP 地址作为出站流量来源来访问网络。每个出站数据包都会由 iptables 重写，使其看起来像是源自主机；响应也会相应重写，以便路由回原始发送方。

在 /etc/network/interfaces 中添加以下行可以修复此问题：

有关此问题的更多信息，请参考以下链接：

Netfilter Packet Flow

Patch on netdev-list introducing conntrack zones

Blog post with a good explanation by using TRACE in the raw table

Bonding（也称为 NIC teaming 或 Link Aggregation）是一种将多个 NIC 绑定为单个网络设备的技术。它可以实现不同目标，例如提升网络容错能力、提高性能，或同时实现二者。

Fibre Channel 等高速硬件及其配套交换硬件可能非常昂贵。通过链路聚合，两块 NIC 可以呈现为一个逻辑接口，从而获得双倍速度。这是 Linux 内核原生功能，并受大多数交换机支持。如果节点有多个 Ethernet 端口，可以将网络线缆连接到不同交换机，以分散故障点；当网络出现问题时，bonded 连接会故障转移到其中一条线缆。

聚合链路可以降低在线迁移延迟，并提高 Proxmox VE 集群节点之间的数据复制速度。

Bonding 有 7 种模式：

如果交换机支持 LACP（IEEE 802.3ad）协议，建议使用对应的 bonding 模式（802.3ad）。否则，通常应使用 active-backup 模式。

对于集群网络（Corosync），建议配置多个网络。Corosync 不需要通过 bond 实现网络冗余，因为当某个网络不可用时，它可以自行在网络之间切换。

以下 bond 配置可用作分布式/共享存储网络。其优势是可以获得更高速度，并让网络具备容错能力。

另一种做法是直接将 bond 用作 bridge port。这可用于让客户机网络具备容错能力。

虚拟 LAN（VLAN）是在网络二层进行划分和隔离的广播域。因此，可以在一个物理网络中拥有多个彼此独立的网络（4096 个）。

每个 VLAN 网络由一个通常称为 tag 的数字标识。随后网络数据包会被“打标签”，用于标识其所属的虚拟网络。

无论是否部署 IPv6，Proxmox VE 都能在所有环境中正常工作。建议保留所有设置的默认值。

如果仍需在节点上禁用 IPv6 支持，请创建适当的 sysctl.conf (5) 片段文件，并设置正确的 sysctls, 例如添加内容如下的 /etc/sysctl.d/disable-ipv6.conf：

相比在 内核命令行 中禁用 IPv6 模块加载，更推荐使用此方法。

默认情况下，bridge 上会启用 MAC learning，以确保虚拟客户机及其网络获得平稳体验。

但在某些环境中，这可能并非期望行为。自 Proxmox VE 7.3 起，可以在 /etc/network/interfaces 中为 bridge 设置 bridge-disable-mac-learning 1 配置，从而禁用该 bridge 上的 MAC learning，例如：

启用后，Proxmox VE 会手动将虚拟机和容器中配置的 MAC 地址添加到 bridge 的 forwarding database，以确保客户机仍可使用网络，但前提是它们使用自身实际的 MAC 地址。

在某些情况下，可能需要使用非默认 NTP 服务器。例如，如果 Proxmox VE 节点由于受限的 防火墙规则无法访问公网，则需要设置本地 NTP 服务器，并指示 NTP 守护进程使用它们。

默认端口为 2003，默认 Graphite 路径为 proxmox。

默认情况下，Proxmox VE 通过 UDP 发送数据，因此 Graphite 服务器必须配置为接受 UDP 数据。在这里也可以为未使用标准 1500 MTU 的环境配置最大传输单元（MTU）。

也可以将插件配置为使用 TCP。为了避免阻塞重要的 pvestatd 统计采集守护进程，需要设置超时时间以应对网络问题。

Proxmox VE 通过 UDP 发送数据，因此 InfluxDB 服务器也必须为此进行配置。必要时，也可以在这里配置 MTU。

以下是在 InfluxDB 服务器上的 InfluxDB 配置示例：

使用该配置时，服务器会在所有 IP 地址的 8089 端口监听，并将数据写入 proxmox 数据库。

也可以将插件配置为使用 InfluxDB 2.x 的 http(s) API。InfluxDB 1.8.x 也包含与该 v2 API 向前兼容的 API endpoint。

要使用该方式，请根据配置将 influxdbproto 设置为 http 或 https。默认情况下，Proxmox VE 使用组织 proxmox 和 bucket/db proxmox（可分别通过 organization 和 bucket 配置项设置）。

由于 InfluxDB 的 v2 API 只能在认证后使用，因此必须生成一个能够写入正确 bucket 的 token 并进行设置。

在 1.8.x 的 v2 兼容 API 中，如有需要，可以使用 user:password 作为 token；由于 organization 在 InfluxDB 1.x 中没有意义，因此可以省略。

还可以通过 timeout 设置 HTTP 超时时间（默认 1s），并通过 max-body-size 设置最大批量大小（默认 25000000 字节）。后者对应 InfluxDB 中同名设置。

查看外部指标服务器配置文件：

确认统计采集守护进程正在运行：

查看某块磁盘的 SMART 摘要信息：

查看 smartd 服务状态：

如果硬盘通过硬件 RAID 控制器使用，通常需要使用控制器厂商提供的工具来监控 RAID 阵列中的磁盘以及阵列本身。有关详细信息，请参考 RAID 控制器厂商的文档。

强烈建议在此类配置中使用硬件 RAID 控制器（带 BBU）。这可以提升性能、提供冗余， 并让磁盘更换更容易（支持热插拔）。

LVM 本身不需要任何特殊硬件，内存需求也很低。

默认会安装两个引导加载器。第一个分区包含标准 GRUB 引导加载器。第二个分区是 EFI System Partition（ESP），用于在 EFI 系统上启动，并允许从用户空间应用 持久化固件更新。

假设有一块空磁盘 /dev/sdb，我们希望在其上创建名为 “vmdata” 的卷组。

首先创建一个分区。

创建一个物理卷（Physical Volume，PV），不要求确认，并使用 250K 元数据大小。

在 /dev/sdb1 上创建名为 “vmdata” 的卷组。

可以通过创建新的 thin LV 轻松完成。

实际示例：

现在必须在该 LV 上创建文件系统。

最后需要将其挂载。

要使其始终可访问，请将以下行添加到 /etc/fstab。

使用以下命令调整 LV 和元数据池大小：

thin 池必须创建在卷组之上。关于如何创建卷组，请参见 LVM 章节。

以下命令可用于查看本地 LVM 状态和 thin 池使用情况：

ZFS 对内存依赖较高，因此起步至少需要 8GB。实践中，应在硬件和预算允许的范围内尽量配置更多内存。为防止数据损坏，建议使用高质量 ECC RAM。

如果使用专用缓存盘和/或日志盘，应使用企业级 SSD。这可以显著提升整体性能。

如果是在虚拟机中实验安装 Proxmox VE（嵌套虚拟化），不要为该虚拟机的磁盘使用 virtio，因为 ZFS 不支持这种磁盘。请改用 IDE 或 SCSI（也可使用 virtio SCSI 控制器类型）。

使用 Proxmox VE 安装程序安装时，可以为根文件系统选择 ZFS。安装时需要选择 RAID 类型：

安装程序会自动对磁盘分区，创建名为 rpool 的 ZFS pool，并将根文件系统安装到 ZFS 子卷 rpool/ROOT/pve-1 上。

安装程序还会创建名为 rpool/data 的子卷用于存储虚拟机镜像。为了让 Proxmox VE 工具使用该子卷，安装程序会在 /etc/pve/storage.cfg 中创建以下配置项：

安装完成后，可以使用 zpool 命令查看 ZFS pool 状态：

zfs 命令用于配置和管理 ZFS 文件系统。以下命令会列出安装后的所有文件系统：

选择 ZFS pool 布局时，需要考虑几个因素。ZFS pool 的基本构建块是虚拟设备，即 vdev。pool 中的所有 vdev 都会被均衡使用，数据会在它们之间条带化（RAID0）。有关 vdev 的更多详情，请查看 zpoolconcepts(7) manpage。

在 ZFS dRAID（declustered RAID）中，热备盘会参与 RAID。其备用容量会被保留，并在某块磁盘故障时用于重建。根据配置不同，发生磁盘故障时，这可以比 RAIDZ 提供更快的重建速度。更多信息请参见官方 OpenZFS 文档。
[OpenZFS dRAID https://openzfs.github.io/openzfs-docs/Basic%20Concepts/dRAID%20Howto.html]

更多信息可在 manual page 中找到：

Proxmox VE 使用 proxmox-boot-tool 管理 bootloader 配置。详情请参见 Proxmox VE 主机 bootloader 章节。

本节给出一些常见任务的使用示例。ZFS 本身功能非常强大，并提供大量选项。管理 ZFS 的主要命令是 zfs 和 zpool。这两个命令都带有完善的 manual page，可以通过以下命令阅读：

ZFS 带有事件守护进程 ZED，用于监控 ZFS 内核模块生成的事件。该守护进程也可以在发生 pool 错误等 ZFS 事件时发送电子邮件。较新的 ZFS 软件包将该守护进程放在独立的 zfs-zed 软件包中，该软件包应已在 Proxmox VE 中默认安装。

可以使用喜欢的编辑器通过 /etc/zfs/zed.d/zed.rc 文件配置该守护进程。电子邮件通知所需设置为 ZED_EMAIL_ADDR，默认设置为 root。

请注意，Proxmox VE 会将发往 root 的邮件转发到为 root 用户配置的电子邮件地址。

默认情况下，ZFS 使用主机内存的 50 % 作为 Adaptive Replacement Cache （ARC）。从 Proxmox VE 8.1 开始的新安装中，ARC 使用上限会设置为已安装物理内存的 10 %，最大限制为 16 GiB。该值写入 /etc/modprobe.d/zfs.conf。

为 ARC 分配足够内存对 I/O 性能至关重要，因此降低该值时应谨慎。一般经验是至少分配 2 GiB Base + 1 GiB/TiB-Storage。例如，如果 pool 有 8 TiB 可用存储空间，则应为 ARC 使用 10 GiB 内存。

ZFS 还会强制执行 64 MiB 的最小值。

可以通过直接写入 zfs_arc_max 模块参数，为当前启动周期修改 ARC 使用上限（重启会重置该更改）：

要*永久更改* ARC 限制，请在 /etc/modprobe.d/zfs.conf 中添加（或修改已有的）以下行：

此示例设置会将使用量限制为 8 GiB（8 * 2³⁰）。

在总内存超过 256 GiB 的系统上，此示例设置会将使用量（临时）限制为 8 GiB（8 * 2³⁰）。在这种情况下，单独设置 zfs_arc_max 不会生效。

在 zvol 上创建的 swap 空间可能会产生一些问题，例如阻塞服务器或造成高 I/O 负载，这种情况常见于开始向外部存储执行备份时。

强烈建议使用足够内存，使系统通常不会遇到低内存情况。如果需要或希望添加 swap，首选是在物理磁盘上创建分区并将其用作 swap 设备。可以在安装程序高级选项中为此预留一些空间。此外，还可以降低 “swappiness” 值。服务器上的一个较好取值是 10：

要使 swappiness 持久化，请使用喜欢的编辑器打开 /etc/sysctl.conf 并添加以下行：

ZFS on Linux 0.8.0 版本引入了对 dataset 原生加密的支持。从较早 ZFS on Linux 版本升级后，可以按 pool 启用加密特性：

加密需要在创建 dataset/zvol 时设置，并默认由子 dataset 继承。例如，要创建加密 dataset tank/encrypted_data 并将其配置为 Proxmox VE 中的存储，请运行以下命令：

在该存储上创建的所有客户机卷/磁盘都会使用父 dataset 的共享 key material 加密。

要实际使用该存储，需要加载关联的 key material 并挂载 dataset。可以通过以下命令一步完成：

也可以通过设置 keylocation 和 keyformat 属性，使用（随机）keyfile 替代交互式输入 passphrase。这既可以在创建时设置，也可以通过 zfs change-key 对现有 dataset 设置：

在加密 dataset 下创建的客户机卷会相应设置其 encryptionroot 属性。每个 encryptionroot 只需加载一次 key material，其下所有加密 dataset 即可使用。

更多详情和高级用法，请参见 encryptionroot、encryption、keylocation、keyformat 和 keystatus 属性，zfs load-key、zfs unload-key、zfs change-key 命令，以及 man zfs 中的 Encryption 章节。

在 dataset 上启用压缩后，ZFS 会尝试在写入所有*新*块之前压缩它们，并在读取时解压缩。已存在的数据不会被追溯压缩。

可以使用以下命令启用压缩：

建议使用 lz4 算法，因为它只会带来很小的 CPU 开销。也可以使用其他算法，例如 lzjb 和 gzip-N，其中 N 是从 1（最快）到 9（最佳压缩率）的整数。根据算法和数据可压缩性不同，启用压缩甚至可能提升 I/O 性能。

可以随时使用以下命令禁用压缩：

同样，只有新块会受到该更改影响。

自 0.8.0 版本起，ZFS 支持 special 设备。pool 中的 special 设备用于存储元数据、去重表，并可选择存储小文件块。

对于由慢速机械硬盘组成且存在大量元数据变更的 pool，special 设备可以提升速度。例如，涉及创建、更新或删除大量文件的工作负载会从 special 设备中受益。还可以配置 ZFS dataset，将整个小文件存储在 special 设备上，从而进一步提升性能。special 设备应使用快速 SSD。

ZFS dataset 暴露 special_small_blocks=<size> 属性。size 可以为 0，表示禁用在 special 设备上存储小文件块；也可以是 512B 到 1M 范围内的 2 的幂。设置该属性后，小于 size 的新文件块会分配到 special 设备上。

在 pool 上设置 special_small_blocks 属性会改变所有子 ZFS dataset 该属性的默认值（例如该 pool 中的所有容器都会选择使用小文件块）。

ZFS 磁盘格式的变更只会在主版本变更之间进行，并通过 features 指定。所有 feature 以及通用机制都在 zpool-features(5) manpage 中有详细记录。

由于启用新 feature 可能导致旧版 ZFS 无法导入 pool，因此必须由管理员主动在 pool 上运行 zpool upgrade 完成（参见 zpool-upgrade(8) manpage）。

除非需要使用某个新 feature，否则启用它们没有额外收益。

事实上，启用新 feature 存在一些缺点：

查看所有 ZFS pool 的状态：

列出 ZFS dataset：

使用 Proxmox VE 安装程序安装时，可以为根文件系统选择 BTRFS。需要在安装时选择 RAID 类型：

安装程序会自动对磁盘分区，并在 /var/lib/pve/local-btrfs 创建一个额外子卷。 为了让 Proxmox VE 工具使用该子卷，安装程序会在 /etc/pve/storage.cfg 中创建 以下配置条目：

这会显式禁用默认的 local 存储，改用额外子卷上的 BTRFS 专用存储条目。

btrfs 命令用于配置和管理 BTRFS 文件系统。安装完成后，以下命令会列出所有 额外子卷：

本节给出一些常见任务的使用示例。

以下命令可用于查看节点任务、唤醒集群节点或批量启动已配置自启动的客户机：

Wake-on-LAN（WoL）允许你通过发送 magic packet 来启动网络中处于睡眠状态的计算机。 至少需要有一个 NIC 支持此功能，并且需要在计算机固件（BIOS/UEFI）配置中启用相应 选项。选项名称可能从 Enable Wake-on-Lan 到 Power On By PCIE Device 不等； 如果不确定，请查阅主板厂商手册。可以运行以下命令，使用 ethtool 检查 <interface> 的 WoL 配置：

pvenode 允许你通过 WoL 唤醒集群中处于睡眠状态的成员，使用命令：

这会在 UDP 端口 9 上广播 WoL magic packet，其中包含从 wakeonlan 属性获取的 <node> MAC 地址。可以使用以下命令设置节点特定的 wakeonlan 属性：

发送 WoL 数据包所使用的接口由默认路由决定。可以通过以下命令设置 bind-interface 来覆盖它：

发送 WoL 数据包时使用的广播地址（默认 255.255.255.255）还可以通过以下命令 显式设置 broadcast-address 来修改：

排查服务器问题时，例如备份作业失败，查看此前运行任务的日志通常很有帮助。在 Proxmox VE 中，可以通过 pvenode task 命令访问节点的任务历史。

可以使用 list 子命令获取节点已完成任务的过滤列表。例如，要获取与虚拟机 100 相关且以错误结束的任务列表，可使用：

随后可以使用任务的 UPID 打印该任务日志：

如果有许多虚拟机/容器，可以使用 pvenode 的 startall 和 stopall 子命令对 客户机执行批量启动和停止操作。默认情况下，pvenode startall 只会启动已设置为 开机自动启动的虚拟机/容器（参见 虚拟机的自动启动和关闭）；不过可以使用 --force 标志覆盖此行为。 这两个命令也都有 --vms 选项，可将停止/启动的客户机限制为指定 VMID。

例如，要启动虚拟机 100、101 和 102，无论它们是否设置了 onboot，可以使用：

要停止这些客户机（以及可能正在运行的任何其他客户机），请使用命令：

如果虚拟机/容器依赖启动较慢的外部资源，例如 NFS 服务器，也可以按节点设置延迟： 从 Proxmox VE 启动完成到第一个配置为自动启动的虚拟机/容器启动之间等待一段时间 （参见 虚拟机的自动启动和关闭）。

可以通过以下设置实现这一点（其中 10 表示以秒为单位的延迟）：

如果升级场景要求将所有客户机从一个节点迁移到另一个节点，pvenode 也提供了用于 批量迁移的 migrateall 子命令。默认情况下，该命令会将系统上的每个客户机迁移到 目标节点；不过也可以设置为只迁移一组客户机。

例如，要将虚拟机 100、101 和 102 迁移到节点 pve2，并启用本地磁盘在线 迁移，可以运行：

自动内存分配的目标百分比默认为 80%。可以通过 设置 ballooning-target 属性按节点自定义此目标。例如，要改为以 90% 主机内存 使用率为目标：

每个 Proxmox VE 集群默认都会创建自己的（自签名）证书颁发机构（CA），并为每个节点生成由该 CA 签名的证书。 这些证书用于与集群的 pveproxy 服务进行加密通信，并在使用 SPICE 时用于 Shell/Console 功能。

CA 证书和密钥存储在 Proxmox Cluster File System (pmxcfs) 中。

REST API 和 Web GUI 由运行在每个节点上的 pveproxy 服务提供。

对于 pveproxy 使用的证书，可以选择以下方式：

对于方式 2 和 3，会使用文件 /etc/pve/local/pveproxy-ssl.pem（以及必须不带密码的 /etc/pve/local/pveproxy-ssl.key）。

证书通过 Proxmox VE 节点管理命令进行管理（参见 pvenode(1) 手册页）。

如果已经有要用于某个 Proxmox VE 节点的证书，可以直接通过 Web 界面上传该证书。

请注意，如果提供证书密钥文件，则该文件不得受密码保护。

Proxmox VE 包含 Automatic Certificate Management Environment （ACME）协议的实现，使 Proxmox VE 管理员可以使用 Let’s Encrypt 等 ACME 提供方， 轻松设置在现代操作系统和 Web 浏览器中默认被接受并信任的 TLS 证书。

目前实现的两个 ACME 端点是 Let’s Encrypt (LE) 生产环境及其 staging 环境。 我们的 ACME 客户端支持使用内置 Web 服务器验证 http-01 挑战， 也支持通过 DNS 插件验证 dns-01 挑战；这些 DNS 插件支持 acme.sh 支持的所有 DNS API 端点。

始终会隐式配置一个 standalone 插件，用于通过在端口 80 上启动的内置 Web 服务器验证 http-01 挑战。

要将其用于 Let’s Encrypt ACME 的证书管理，需要满足几个前提条件。

在无法或不希望通过 http-01 方法进行外部访问验证的系统上，可以使用 dns-01 验证方法。 此验证方法要求 DNS 服务器允许通过 API 配置 TXT 记录。

如果节点已成功配置由 ACME 提供的证书（无论通过 pvenode 还是 GUI），该证书将由 pve-daily-update.service 自动续期。目前，如果证书已经过期，或将在未来 30 天内过期，将尝试续期。

Proxmox VE 安装程序会在所有被选作安装目标的磁盘上创建 3 个分区。

创建的分区包括：

使用 ZFS 作为根文件系统的系统，会通过存储在 512 MB EFI System Partition 上的 内核和 initrd 镜像启动。对于传统 BIOS 系统以及启用了 Secure Boot 的 EFI 系统， 会使用 GRUB；对于未启用 Secure Boot 的 EFI 系统，会使用 systemd-boot。两者 都会被安装并配置为指向 ESP。

在所有使用 GRUB 启动的系统上，BIOS 模式的 GRUB（--target i386-pc）会安装到 所有所选磁盘的 BIOS Boot Partition 上
[这些包括根文件系统位于 ext4 或 xfs 的所有安装，以及非 EFI 系统上根文件系统位于 ZFS 的安装]
。

proxmox-boot-tool 是一个用于确保 EFI System Partition 内容正确配置并保持同步的 工具。它会将特定内核版本复制到所有 ESP，并配置相应的引导加载器，使其从格式化为 vfat 的 ESP 启动。在以 ZFS 作为根文件系统的场景中，这意味着可以在根池上使用 所有可选功能，而无需受限于 GRUB 中 ZFS 实现也支持的子集，也无需创建单独的小型 boot-pool
[使用 GRUB 从 ZFS 根文件系统启动 https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Bookworm%20Root%20on%20ZFS.html]
.

在具备冗余的设置中，安装程序会在所有磁盘上划分 ESP。这样即使第一个启动设备故障， 或者 BIOS 只能从特定磁盘启动，系统仍能启动。

在常规运行期间，ESP 不会保持挂载状态。这样有助于在系统崩溃时避免格式化为 vfat 的 ESP 文件系统损坏，也避免在主启动设备故障时需要手动调整 /etc/fstab。

proxmox-boot-tool 处理以下任务：

可以运行以下命令查看当前已配置的 ESP 及其状态：

要将某个分区格式化并初始化为同步 ESP，例如在 rpool 中更换故障 vdev 后，或将早于 同步机制的现有系统转换为使用该机制时，可以使用 proxmox-kernel-helper 提供的 proxmox-boot-tool。

例如，要将空分区 /dev/sda2 格式化为 ESP，请运行：

要将位于 /dev/sda2 且未挂载的现有 ESP 纳入 Proxmox VE 的内核更新同步机制，请使用：

或：

用于强制使用 GRUB 而不是 systemd-boot 初始化，例如用于支持 Secure Boot。

之后，/etc/kernel/proxmox-boot-uuids 中应包含一行新增分区的 UUID。init 命令 还会自动触发所有已配置 ESP 的刷新。

要复制并配置所有可启动内核，并保持 /etc/kernel/proxmox-boot-uuids 中列出的所有 ESP 同步，只需运行：

（等同于在根文件系统为 ext4 或 xfs 的系统上运行 update-grub）。

如果更改了内核命令行，或希望同步所有内核和 initrd，则需要执行此操作。

默认配置以下内核版本：

如果希望将某个内核和 initrd 镜像添加到可启动内核列表，请使用 proxmox-boot-tool kernel add。

例如，运行以下命令可将 ABI 版本为 5.0.15-1-pve 的内核添加到需要保留安装并同步到 所有 ESP 的内核列表：

proxmox-boot-tool kernel list 会列出当前选定用于启动的所有内核版本：

运行 proxmox-boot-tool kernel remove 可从手动选择的内核列表中移除某个内核，例如：

以下命令可用于查看 ESP 同步状态、列出已选择的内核，并在更改后刷新 ESP 配置：

确定正在使用哪个引导加载器的最简单且最可靠的方法，是观察 Proxmox VE 节点的启动过程。

你会看到 GRUB 的蓝色界面，或者简洁的黑白 systemd-boot 界面。

从正在运行的系统判断引导加载器可能并非 100% 准确。最安全的方式是运行以下命令：

如果返回 EFI 变量不受支持的信息，则说明正在以 BIOS/Legacy 模式使用 GRUB。

如果输出包含类似以下内容的行，则说明正在以 UEFI 模式使用 GRUB。

如果输出包含类似以下内容的行，则说明正在使用 systemd-boot。

运行：

可以确认是否已配置 proxmox-boot-tool，这能够较好地反映系统的启动方式。

多年来，GRUB 一直是启动 Linux 系统的事实标准，并且文档相当完善
[GRUB Manual https://www.gnu.org/software/grub/manual/grub/grub.html]
.

systemd-boot 是轻量级 EFI 引导加载器。它会直接从安装位置所在的 EFI Service Partition（ESP）读取内核和 initrd 镜像。直接从 ESP 加载内核的主要优势在于， 无需重新实现用于访问存储的驱动程序。在 Proxmox VE 中， proxmox-boot-tool 用于保持 ESP 上的配置同步。

可以根据所使用的引导加载器，在以下位置修改内核命令行：

内核命令行需要放在 /etc/default/grub 文件中的 GRUB_CMDLINE_LINUX_DEFAULT 变量内。运行 update-grub 会将其内容追加到 /boot/grub/grub.cfg 中所有 linux 条目。

内核命令行需要作为一行写入 /etc/kernel/cmdline。要应用更改，请运行 proxmox-boot-tool refresh，它会将该内容设置为 loader/entries/proxmox-*.conf 中所有配置文件的 option 行。

完整的内核参数列表可在以下地址找到： https://www.kernel.org/doc/html/v<YOUR-KERNEL-VERSION>/admin-guide/kernel-parameters.html. 请将 <YOUR-KERNEL-VERSION> 替换为 major.minor 版本。例如，对于基于 6.5 版本的 内核，URL 为： https://www.kernel.org/doc/html/v6.5/admin-guide/kernel-parameters.html

可以通过查看 Web 界面（Node -> Summary）或运行以下命令来查找内核版本：

使用输出开头的前两个数字。

要选择当前默认内核之外的内核，可以采用以下方式之一：

这有助于规避较新内核版本与硬件之间的不兼容问题。

例如：若要永久选择版本 5.15.30-1-pve 用于启动，请运行：

也可以设置只在下一次系统启动时引导某个内核版本。例如，这可用于测试更新后的内核 是否已解决最初导致需要 pin 某个版本的问题：

要移除任何已固定的版本配置，请使用 unpin 子命令：

虽然 unpin 也有 --next-boot 选项，但它用于清除通过 --next-boot 设置的固定版本。 由于该操作在启动时已经会自动发生，手动调用的实际用途很小。

设置或清除固定版本后，还需要运行 refresh 子命令来同步 ESP 上的内容和配置。

自 Proxmox VE 8.1 起，通过签名软件包以及与 proxmox-boot-tool 的集成，Secure Boot 可开箱即用。

Secure Boot 正常工作需要以下软件包。可以使用 proxmox-secure-boot-support 元软件包一次性安装它们。

开箱即用的引导加载器仅支持 GRUB，因为其他引导加载器当前不符合 Secure Boot 代码签名条件。

任何新的 Proxmox VE 安装都会自动包含上述所有软件包。

关于 Secure Boot 工作方式以及如何自定义设置的更多详情，请参见 我们的 wiki。

在虚拟化环境中，KSM 可以优化内存使用，因为运行相似操作系统或工作负载的多台虚拟机 可能共享大量相同的内存页。

不过，虽然 KSM 能降低内存使用量，它也带来一些安全风险，因为它可能使虚拟机暴露于 侧信道攻击。研究表明，可以利用 KSM 的某些特性，通过同一主机上的另一台虚拟机推断 正在运行的虚拟机中的信息。

因此，如果使用 Proxmox VE 提供托管服务，应考虑禁用 KSM，以便为用户提供额外的安全性。 此外，还应检查所在国家或地区的法规，因为禁用 KSM 可能是法律要求。

要查看 KSM 是否处于活动状态，可以检查以下命令的输出：

如果处于活动状态，可以使用以下命令立即禁用：

最后，要取消当前所有已合并页面的合并，请运行：

常用命令示例：