en to zh translation catalogue (51 entries)

note: type: Title ==
en: LINSTOR Volumes in Proxmox VE
zh: Proxmox VE中的LINSTOR卷

note: type: Plain text
en: indexterm:[Proxmox]This chapter describes DRBD in Proxmox VE via the http://git.linbit.com/linstor-proxmox.git[LINSTOR Proxmox Plugin].
zh: indexterm:[Proxmox]本章描述了通过 http://git.linbit.com/linstor-proxmox.git[LINSTOR Proxmox Plugin] 实现的Proxmox VE中的DRBD。

note: type: Title ===
en: Proxmox VE Overview
zh: Proxmox VE概述

note: type: Plain text
en: http://www.proxmox.com/en/[Proxmox VE] is an easy to use, complete server virtualization environment with KVM, Linux Containers and HA.
zh: http://www.proxmox.com/en/[proxmox VE]是一个易于使用的、完整的服务器虚拟化环境，具有KVM、Linux容器和HA。

note: (LVM volumes on DRBD) type: Plain text
en: 'linstor-proxmox' is a Perl plugin for Proxmox that, in combination with LINSTOR, allows to replicate VM disks on several Proxmox VE nodes. This allows to live-migrate active VMs within a few seconds and with no downtime without needing a central SAN, as the data is already replicated to multiple nodes.
zh: `linstor-proxmox` 是proxmox的一个Perl插件，它与LINSTOR结合，允许在多个proxmox VE节点上复制VM磁盘。这允许在几秒钟内实时迁移活动vm，而且不需要中央SAN，因为数据已经复制到多个节点。

note: type: Title ===
en: Proxmox Plugin Installation
zh: Proxmox插件安装

note: type: Plain text
en: LINBIT provides a dedicated public repository for Proxmox VE users. This repository not only contains the Proxmox plugin, but the whole DRBD SDS stack including a DRBD SDS kernel module and user space utilities.
zh: LINBIT为Proxmox VE用户提供了一个专用的公共仓库。这个存储库不仅包含Proxmox插件，还包含整个DRBD-SDS堆栈，包括DRBD SDS内核模块和用户空间实用程序。

note: type: Plain text
en: The DRBD9 kernel module is installed as a `dkms` package (i.e., `drbd-dkms`), therefore you'll have to install
    `pve-headers` package, before you set up/install the software packages from LINBIT's repositories. Following
    that order, ensures that the kernel module will build properly for your kernel. If you don't plan to install
    the latest Proxmox kernel, you have to install kernel headers matching your current running kernel (e.g.,
    		`pve-headers-$(uname -r)`). If you missed this step, then still you can rebuild the dkms package against
    your current kernel, (kernel headers have to be installed in advance), by issuing `apt install --reinstall
    drbd-dkms` command.
zh: DRBD9内核模块是作为dkms软件包（即 `drbd-dkms` ）安装的，因此，您必须先安装 `pve-headers` 软件包，然后才能从LINBIT的存储库中设置/安装软件包。 按照该顺序，确保内核模块将为您的内核正确构建。如果您不打算安装最新的Proxmox内核，则必须安装与当前运行的内核匹配的内核头文件（例如 `pve-headers-$（uname -r）`）。如果您错过了这一步，那么仍然可以通过输入 `apt install --reinstall drbd-dkms` 命令， 针对当前内核重建dkms软件包（必须预先安装内核头文件）。

note: type: Plain text
en: LINBIT's repository can be enabled as follows, where "$PVERS" should be set to your Proxmox VE *major version* (e.g., "5", not "5.2"):
zh: LINBIT的仓库可以如下启用，其中 "$PVERS" 应该设置为Proxmox VE *主版本* （例如， "5" ，而不是 "5.2" ）：

note: type: Title ===
en: LINSTOR Configuration
zh: LINSTOR配置

note: type: Plain text
en: For the rest of this guide we assume that you have a LINSTOR cluster configured as described in <<s-linstor-init-cluster>>. Also make sure to setup each node as a "Combined" node. Start the "linstor-controller" on one node, and the "linstor-satellite" on all nodes. The preferred way to use the plugin, starting from version 4.1.0, is via LINSTOR resource groups and a single volume group within every resource group. LINSTOR resource groups are described in <<s-linstor-resource-groups>>. All the required LINSTOR configuration (e.g., redundancy count) has to be set on the resource group.
zh: 对于本指南的其余部分，我们假设您已经按照<<s-linstor-init-cluster>>中的说明配置了LINSTOR集群。还要确保将每个节点设置为 "Combined" 节点。在一个节点上启动  "linstor-controller" ` ，在所有节点上启动 "linstor-satellite"  。从4.1.0版开始，使用插件的首选方法是通过LINSTOR资源组和每个资源组中的单个卷组。LINSTOR资源组在<<s-linstor-resource-groups>>中描述。必须在资源组上设置所有必需的LINSTOR配置（如冗余计数）。

note: type: Title ===
en: Proxmox Plugin Configuration
zh: ProxBox插件配置

note: type: Plain text
en: The final step is to provide a configuration for Proxmox itself. This can be done by adding an entry in the `/etc/pve/storage.cfg` file, with a content similar to the following.
zh: 最后一步是为Proxmox本身提供配置。这可以通过在 `/etc/pve/storage.cfg` 文件中添加一个条目来完成，其内容类似于以下内容。

note: type: Plain text
en: The "drbd" entry is fixed and you are not allowed to modify it, as it tells to Proxmox to use DRBD as storage backend.  The "drbdstorage" entry can be modified and is used as a friendly name that will be shown in the PVE web GUI to locate the DRBD storage.  The "content" entry is also fixed, so do not change it. The redundancy (specified in the resource group) specifies how many replicas of the data will be stored in the cluster. The recommendation is to set it to 2 or 3 depending on your setup.  The data is accessible from all nodes, even if some of them do not have local copies of the data.  For example, in a 5 node cluster, all nodes will be able to access 3 copies of the data, no matter where they are stored in. The "controller" parameter must be set to the IP of the node that runs the LINSTOR controller service. Only one node can be set to run as LINSTOR controller at the same time.  If that node fails, start the LINSTOR controller on another node and change that value to its IP address. There are more elegant ways to deal with this problem. For more, see later in this chapter how to setup a highly available LINSTOR controller VM in Proxmox.
zh: "drbd" 条目是固定的，不允许修改它，因为它告诉Proxmox使用drbd作为存储后端。可以修改 "drbdstorage" 条目并将其用作友好名称，该名称将显示在PVE web GUI中以查找DRBD存储。 "content" 条目也是固定的，所以不要更改它。冗余（在资源组中指定）指定将在群集中存储多少数据副本。建议根据您的设置将其设置为2或3。数据可以从所有节点访问，即使其中一些节点没有数据的本地副本。例如，在5节点集群中，所有节点都可以访问数据的3个副本，无论它们存储在何处。 "controller" 参数必须设置为运行LINSTOR控制器服务的节点的IP。只能将一个节点设置为同时作为LINSTOR controller运行。如果该节点出现故障，请在另一个节点上启动LINSTOR controller，并将该值更改为其IP地址。有更优雅的方法来处理这个问题。有关更多信息，请参阅本章后面的 `如何在ProxBox中设置高可用的LINSTOR controller 虚拟机` 。

note: type: Plain text
en: Recent versions of the plugin allow to define multiple different storage pools. Such a configuration would look like this:
zh: 插件的最新版本允许定义多个不同的存储池。这样的配置如下：

note: type: Plain text
en: By now, you should be able to create VMs via Proxmox's web GUI by selecting "__drbdstorage__", or any other of the defined pools as storage location.
zh: 现在，您应该可以通过Proxmox的web GUI创建vm，方法是选择 "__drbdstorage__" , 或者选择任何其他已定义的池作为存储位置。

note: type: Block title
en: NOTE: DRBD supports only the **raw** disk format at the moment.
zh: 注意：目前DRBD只支持 **raw** 磁盘格式。

note: type: Plain text
en: At this point you can try to live migrate the VM - as all data is accessible on all nodes (even on Diskless nodes) - it will take just a few seconds. The overall process might take a bit longer if the VM is under load and if there is a lot of RAM being dirtied all the time.  But in any case, the downtime should be minimal and you will see no interruption at all.
zh: 此时，您可以尝试实时迁移虚拟机 - 因为所有节点（甚至在无盘节点上）都可以访问所有数据 - 只需几秒钟。如果VM负载不足，并且有很多RAM一直被污染，那么整个过程可能需要更长的时间。但是在任何情况下，停机时间都应该是最少的，而且您不会看到任何中断。

note: type: Title ===
en: Making the Controller Highly-Available
zh: Controller HA

note: type: Plain text
en: For the rest of this guide we assume that you installed LINSTOR and the Proxmox Plugin as described in <<s-proxmox-ls-ls-configuration>>.
zh: 对于本指南的其余部分，我们假设您安装了LINSTOR和Proxmox插件，如<<s-proxmox-ls-ls-configuration>>中所述。

note: type: Plain text
en: The basic idea is to execute the LINSTOR controller within a VM that is controlled by Proxmox and its HA features, where the storage resides on DRBD managed by LINSTOR itself.
zh: 基本思想是在一个由Proxmox及其HA特性控制的VM中执行LINSTOR控制器，其中存储驻留在由LINSTOR本身管理的DRBD上。

note: type: Plain text
en: The first step is to allocate storage for the VM: Create a VM as usual and select "Do not use any media" on the "OS" section. The hard disk should of course reside on DRBD (e.g., "drbdstorage"). 2GB disk space should be enough, and for RAM we chose 1GB. These are the minimum requirements for the appliance LINBIT provides to its customers (see below). If you wish to set up your own controller VM, and you have enough hardware resources available, you can increase these minimum values. In the following use case, we assume that the controller VM was created with ID 100, but it is fine if this VM was created at a later time and has a different ID.
zh: 第一步是为VM分配存储空间：像往常一样创建一个VM，并在 "OS" 部分选择 "Do not use any media"。硬盘当然应该位于DRBD上（例如 "drbdstorage" ）。2GB的磁盘空间应该足够了，对于RAM，我们选择了1GB。这些是LINBIT为其客户提供的设备的最低要求（见下文）。如果您希望设置自己的控制器虚拟机，并且您有足够的可用硬件资源，则可以增加这些最小值。在下面的用例中，我们假设控制器VM是用ID 100创建的，但是如果这个VM是在以后创建的，换成一个不同的ID，就可以了。

note: type: Plain text
en: LINBIT provides an appliance for its customers that can be used to populate the created storage. For the appliance to work, we first create a "Serial Port". First click on "Hardware" and then on "Add" and finally on "Serial Port":
zh: LINBIT为其客户提供了一个设备，可用于填充创建的存储。为了让设备工作，我们首先创建一个 "Serial Port"。首先点击 \:Hardware" ，然后点击 "Add" ，最后点击 "Serial Port" :

note: type: Block title
en: Adding a Serial Port
zh: 添加串行端口

note: type: Plain text
en: If everything worked as expected the VM definition should then look like this:
zh: 如果一切正常，VM定义应该如下所示：

note: type: Block title
en: VM with Serial Port
zh: 带串行端口的虚拟机

note: type: Plain text
en: The next step is to copy the VM appliance to the VM disk storage. This can be done with `qemu-img`.
zh: 下一步是将VM设备复制到VM磁盘存储。这可以通过 `qemu img` 完成。

note: type: Plain text
en: Make sure to replace the VM ID with the correct one.
zh: 确保用正确的VM ID替换VM ID。

note: type: Plain text
en: Once completed you can start the VM and connect to it via the Proxmox VNC viewer. The default user name and password are both "linbit". Note that we kept the default configuration for the ssh server, so you will not be able to log in to the VM via ssh and username/password. If you want to enable that (and/or "root" login), enable these settings in `/etc/ssh/sshd_config` and restart the ssh service. As this VM is based on "Ubuntu Bionic", you should change your network settings (e.g., static IP) in `/etc/netplan/config.yaml`.  After that you should be able to ssh to the VM:
zh: 完成后，您可以启动VM并通过Proxmox VNC查看器连接到它。默认用户名和密码都是 "linbit" 。注意，我们保留了ssh服务器的默认配置，因此您将无法通过ssh和用户名/密码登录到VM。如果要启用该功能（和/或 "root" 登录），请在 `/etc/ssh/sshd_config` 中启用这些设置， 然后重新启动ssh服务。由于这个虚拟机是基于 "Ubuntu Bionic", 您应该在 `/etc/netplan/config.yaml` 中更改网络设置（例如，静态IP）。之后，您应该能够通过ssh连接到VM：

note: type: Block title
en: LINBIT LINSTOR Controller Appliance
zh: LINBIT LINSTOR Controller设备

note: type: Plain text
en: In the next step you add the controller VM to the existing cluster:
zh: 在下一步中，将controller VM添加到现有集群：

note: type: Plain text
en: As the Controller VM will be handled in a special way by the Proxmox storage plugin (comparing to the rest of VMs), we must make sure all hosts have access to its backing storage, *before* PVE HA starts the VM, otherwise the VM will fail to start. See below for the details on how to achieve this.
zh: 由于Controller VM将由Proxmox存储插件以特殊的方式处理（与其他虚拟机相比），我们必须确保所有主机都有权访问其备份存储，在PVE HA启动虚拟机 *之前* ，否则虚拟机将无法启动。有关如何实现此目标的详细信息，请参见下文。

note: type: Plain text
en: In our test cluster the Controller VM disk was created in DRBD storage and it was initially assigned to one host (use `linstor resource list` to check the assignments).  Then, we used `linstor resource create` command to create additional resource assignments to the other nodes of the cluster for this VM.  In our lab consisting of four nodes, we created all resource assignments as diskful, but diskless assignments are fine as well. As a rule of thumb keep the redundancy count at "3" (more usually does not make sense), and assign the rest as diskless.
zh: 在我们的测试集群中，Controller VM磁盘是在DRBD存储中创建的， 最初分配给一个主机（使用 `linstor resource list` 检查分配）。然后，我们使用 `linstor resource create` 命令为这个VM创建额外的资源分配给集群的其他节点。在由四个节点组成的实验环境中，我们将所有资源分配创建为磁盘分配，但无磁盘分配也很好。根据经验，将冗余计数保持在 "3" （通常没有意义），并将其余部分分配为无盘。

note: type: Plain text
en: As the storage for the Controller VM must be made available on all PVE hosts in some way, we must make sure to enable the `drbd.service` on all hosts (given that it is not controlled by LINSTOR at this stage):
zh: 由于Controller VM的存储必须以某种方式在所有PVE主机上可用，因此我们必须确保在所有主机上启用 `drbd.service` （假定它在此阶段不受LINSTOR控制）：

note: type: Plain text
en: By default, at startup the `linstor-satellite` service deletes all of its resource files (`*.res`) and regenerates them.  This conflicts with the `drbd` services that needs these resource files to start the controller VM. It is good enough to first bring up the resources via `drbd.service` and ensure that the `linstor-satellite.service`, which brings up the controller resource never deletes the according `res` file.  To make the necessary changes, you need to create a drop-in for the `linstor-satellite.service` via `systemctl` (do *not* edit the file directly).
zh: 默认情况下， `linstor satellite` 服务在启动时删除其所有资源文件（`*.res`）并重新生成它们。这与需要这些资源文件来启动控制器VM的 `drbd` 服务冲突。首先通过 `drbd.service` 调出资源，并确保调出控制器资源的 `linstor satellite.service` 不会删除相应的 `res` 文件。要进行必要的更改，需要通过 `systemctl` 为 `linstor satellite.service` 创建一个drop-in（不要直接编辑文件）。

note: type: Plain text
en: Of course adapt the name of the controller VM in the `LS_KEEP_RES` variable. Note that the value given is interpreted as regex, so you don't need to specify the exact name.
zh: 当然，在 `LS_KEEP_RES` 变量中需要调整controller VM的名称。请注意，给定的值被解释为regex，因此不需要指定确切的名称。

note: type: Plain text
en: Don't forget to restart the `linstor-satellite.service`.
zh: 别忘了重新启动 `linstor satellite.service` 。

note: type: Plain text
en: After that, it is time for the final steps, namely switching from the existing controller (residing on the physical host) to the new one in the VM. So let's stop the old controller service on the physical host, and copy the LINSTOR controller database to the VM host:
zh: 在那之后，是时候进行最后的步骤了，即从现有的控制器（驻留在物理主机上）切换到VM中的新控制器。因此，让我们停止物理主机上的旧控制器服务，并将LINSTOR控制器数据库复制到VM主机：

note: type: Plain text
en: Finally, we can enable the controller in the VM:
zh: 最后，我们可以在VM中启用控制器：

note: type: Plain text
en: To check if everything worked as expected, you can query the cluster nodes on a physical PVE host by asking the controller in the VM: `linstor --controllers=10.43.7.254 node list`. It is perfectly fine that the controller (which is just a Controller and not a "Combined" host) is shown as "OFFLINE". This might change in the future to something more reasonable.
zh: 要检查一切是否按预期工作，可以通过询问VM中的控制器来查询物理PVE主机上的群集节点： `linstor--controllers=10.43.7.254 node list`。controller（只是一个controller，而不是 "Combined" 主机）显示为 "OFFLINE"， 但一切正常。这在未来可能会改变为更合理的方式。

note: type: Plain text
en: As the last -- but crucial -- step, you need to add the "controlervm" option to `/etc/pve/storage.cfg`, and change the controller IP address to the IP address of the Controller VM:
zh: 作为最后一步 -- 但至关重要 --，您需要将 "controlervm" 选项添加到 `/etc/pve/storage.cfg` ，并将控制器IP地址更改为控制器虚拟机的IP地址：

note: type: Plain text
en: Please note the additional setting "controllervm". This setting is very important, as it tells to PVE to handle the Controller VM differently than the rest of VMs stored in the DRBD storage.  In specific, it will instruct PVE to NOT use LINSTOR storage plugin for handling the Controller VM, but to use other methods instead. The reason for this, is that simply LINSTOR backend is not available at this stage.  Once the Controller VM is up and running (and the associated LINSTOR controller service inside the VM), then the PVE hosts will be able to start the rest of virtual machines which are stored in the DRBD storage by using LINSTOR storage plugin. Please make sure to set the correct VM ID in the "controllervm" setting. In this case is set to "100", which represents the ID assigned to our Controller VM.
zh: 请注意附加设置 "controllervm" 。这个设置非常重要，因为它告诉PVE以不同于DRBD存储中存储的其他VM的方式处理控制器VM。具体来说，它将指示PVE不要使用LINSTOR存储插件来处理控制器VM，而是使用其他方法。原因是，在这个阶段没有简单的LINSTOR后端。一旦控制器VM启动并运行（以及VM中相关的LINSTOR控制器服务），PVE主机将能够使用linstorage插件启动存储在DRBD存储中的其余虚拟机。请确保在 `controllervm` 设置中设置正确的VM ID。在本例中设置为 `100` ，表示分配给控制器VM的ID。

note: type: Plain text
en: It is very important to make sure that the Controller VM is up and running at all times and that you are backing it up at regular times(mostly when you do modifications to the LINSTOR cluster). Once the VM is gone, and there are no backups, the LINSTOR cluster must be recreated from scratch.
zh: 非常重要的一点是，要确保控制器VM始终处于启动和运行状态，并且要定期备份它（主要是在修改LINSTOR集群时）。一旦VM消失，并且没有备份，LINSTOR集群必须从头开始重新创建。

note: type: Plain text
en: To prevent accidental deletion of the VM, you can go to the "Options" tab of the VM, in the PVE GUI and enable the "Protection" option.  If however you accidentally deleted the VM, such requests are ignored by our storage plugin, so the VM disk will NOT be deleted from the LINSTOR cluster. Therefore, it is possible to recreate the VM with the same ID as before(simply recreate the VM configuration file in PVE and assign the same DRBD storage device used by the old VM). The plugin will just return "OK", and the old VM with the old data can be used again. In general, be careful to not delete the controller VM and "protect" it accordingly.
zh: 为了防止意外删除VM，可以转到PVE GUI中VM的 "Options" 选项卡并启用 "Protection" 选项。但是，如果您意外地删除了VM，那么存储插件会忽略这些请求，因此VM磁盘不会从LINSTOR集群中删除。因此，可以使用与以前相同的ID重新创建VM（只需在PVE中重新创建VM配置文件并分配旧VM使用的相同DRBD存储设备）。这个插件只会返回 "OK" ，带有旧数据的旧VM可以再次使用。一般来说，注意不要删除控制器VM并相应地 "protect" 它。

note: type: Plain text
en: Currently, we have the controller executed as VM, but we should make sure that one instance of the VM is started at all times. For that we use Proxmox's HA feature. Click on the VM, then on "More", and then on "Manage HA". We set the following parameters for our controller VM:
zh: 目前，我们已经将控制器作为VM执行，但是我们应该确保VM的一个实例始终启动。为此，我们使用Proxmox的HA特性。点击虚拟机，然后点击 "More" ，然后点击 "Manage HA" 。我们为控制器VM设置以下参数：

note: type: Block title
en: HA settings for the controller VM
zh: 控制器虚拟机的HA设置

note: type: Plain text
en: As long as there are surviving nodes in your Proxmox cluster, everything should be fine and in case the node hosting the Controller VM is shut down or lost, Proxmox HA will make sure the controller is started on another host. Obviously the IP of the controller VM should not change. It is up to you as an administrator to make sure this is the case (e.g., setting a static IP, or always providing the same IP via dhcp on the bridged interface).
zh: 只要您的Proxmox集群中有幸存的节点，一切都应该正常，并且如果承载控制器VM的节点关闭或丢失，Proxmox HA将确保controller在另一台主机上启动。显然，控制器VM的IP不应该更改。这取决于作为管理员的您，以确保是这样的情况（例如，设置一个静态IP，或始终通过桥接接口上的dhcp提供相同的IP）。

note: type: Plain text
en: It is important to mention at this point that in the case that you are using a dedicated network for the LINSTOR cluster, you must make sure that the network interfaces configured for the cluster traffic, are configured as bridges (i.e vmb1,vmbr2 etc) on the PVE hosts. If they are setup as direct interfaces (i.e eth0,eth1 etc), then you will not be able to setup the Controller VM vNIC to communicate with the rest of LINSTOR nodes in the cluster, as you cannot assign direct network interfaces to the VM, but only bridged interfaces.
zh: 在此必须指出的是，如果要为LINSTOR集群使用专用网络，则必须确保为集群通信配置的网络接口在PVE主机上配置为网桥（即vmb1、vmbr2等）。如果将它们设置为直接接口（即eth0、eth1等），则您将无法设置控制器VM vNIC以与群集中的其余LINSTOR节点通信，因为您无法将直接网络接口分配给VM，而只能将桥接接口分配给VM。

note: type: Plain text
en: One limitation that is not fully handled with this setup is a total cluster outage (e.g., common power supply failure) with a restart of all cluster nodes. Proxmox is unfortunately pretty limited in this regard. You can enable the "HA Feature" for a VM, and you can define "Start and Shutdown Order" constraints. But both are completely separated from each other. Therefore it is hard/impossible to guarantee that the Controller VM will be up and running, before all other VMs are started.
zh: 此设置未完全处理的一个限制是所有群集节点重新启动后的群集完全中断（例如，常见电源故障）。不幸的是Proxmox在这方面非常有限。可以为VM启用 "HA Feature" ，还可以定义 "Start and Shutdown Order" 约束。但两者都是完全分离的。因此，在启动所有其他VM之前，很难/不可能保证controller VM将启动并运行。

note: type: Plain text
en: It might be possible to work around that by delaying VM startup in the Proxmox plugin itself until the controller VM is up (i.e., if the plugin is asked to start the controller VM it does it, otherwise it waits and pings the controller). While a nice idea, this would horribly fail in a serialized, non-concurrent VM start/plugin call event stream where some VM should be started (which then are blocked) before the Controller VM is scheduled to be started. That would obviously result in a deadlock.
zh: 可以通过在Proxmox插件中延迟VM启动来解决这个问题，直到控制器VM启动（即，如果要求插件启动控制器VM，它就会启动，否则它会等待并ping控制器）。虽然这是一个好主意，但在序列化的、非并发的VM启动/插件调用事件流中，这可能会严重失败，在controller VM启动之前，应该启动某些VM（然后被阻止）。这显然会导致僵局。

note: type: Plain text
en: We will discuss these options with Proxmox, but we think the current solution is valuable in most typical use cases, as is. Especially, compared to the complexity of a pacemaker setup. Use cases where one can expect that not the whole cluster goes down at the same time are covered. And even if that is the case, only automatic startup of the VMs would not work when the whole cluster is started. In such a scenario the admin just has to wait until the Proxmox HA service starts the controller VM.  After that all VMs can be started manually/scripted on the command line.
zh: 我们将与Proxmox讨论这些选项，但是我们认为当前的解决方案在大多数典型用例中都是有价值的。尤其是，与pacemaker配置的复杂性相比。我们将讨论一些用例，在这些用例中，人们可以预期不会同时关闭整个集群。即使是这样，当整个集群启动时，只有VMs的自动启动将不起作用。在这种情况下，管理员只需等到Proxmox HA服务启动控制器VM。之后，所有vm都可以在命令行上手动启动/或通过脚本批量启动。
