diff --git a/docs/USER_GUIDE.md b/docs/USER_GUIDE.md index 32d9a0745d..54fc18c159 100644 --- a/docs/USER_GUIDE.md +++ b/docs/USER_GUIDE.md @@ -620,11 +620,6 @@ VolumeBindingMode property: ![vd-wffc](images/vd-wffc.png) -AccessMode: - -- `ReadWriteMany (RWX)`: Multiple disk access. Live migration of virtual machines with such disks is possible. -- `ReadWriteOnce (RWO)`: The disk can be accessed by only a single virtual machine instance. Live migration of virtual machines that use such disks is supported only in commercial editions. - When creating a disk, the controller will independently determine the most optimal parameters supported by the storage. Attention: It is impossible to create disks from iso-images! @@ -928,6 +923,8 @@ Method #2: In commercial editions, you can migrate (move) a virtual machine disk to another storage by changing its StorageClass. +Migration is supported for both statically attached disks and dynamically attached (hotplug) disks. + {{< alert level="warning">}} Limitations of disk migration between storage: @@ -2679,6 +2676,12 @@ Virtual machines can be connected to additional networks: project networks (`Net To do this, specify the desired networks in the configuration section `.spec.networks`. If this block is not specified (which is the default behavior), the VM will use only the main cluster network. +{{< alert level="info" >}} +Specifying the main cluster network (`type: Main`) in `.spec.networks` is optional. If you do not need a connection to the main cluster network, you can use only additional networks (`Network` or `ClusterNetwork`). + +However, if the main network is specified, it must always be first in the `.spec.networks` list. +{{< /alert >}} + Important considerations when working with additional network interfaces: - The order of listing networks in `.spec.networks` determines the order in which interfaces are connected inside the virtual machine. @@ -2687,28 +2690,39 @@ Important considerations when working with additional network interfaces: - Network security policies (NetworkPolicy) do not apply to additional network interfaces. - Network parameters (IP addresses, gateways, DNS, etc.) for additional networks are configured manually from within the guest OS (for example, using Cloud-Init). -Example of connecting a VM to the project network `user-net`: +Example of connecting a VM to the main cluster network and the project network `user-net`: ```yaml spec: networks: - - type: Main # Must always be specified first + - type: Main # If specified, must be first - type: Network # Network type (Network \ ClusterNetwork) name: user-net # Network name ``` -Example of connecting to the cluster network `corp-net`: +Example of connecting to multiple networks, including the cluster network `corp-net`: ```yaml spec: networks: - - type: Main # Must always be specified first + - type: Main # If specified, must be first - type: Network name: user-net - type: ClusterNetwork name: corp-net # Network name ``` +Example of connecting a VM only to additional networks (without the main cluster network): + +```yaml +spec: + networks: + - type: Network + name: isolated-net + - type: ClusterNetwork + name: corp-net +``` + You can view information about connected networks and their MAC addresses in the VM status: ```yaml @@ -2779,12 +2793,13 @@ Snapshots allow you to capture the current state of a resource for later recover Snapshots can be consistent or inconsistent; this is controlled by the `requiredConsistency` parameter. By default, `requiredConsistency` is set to `true`, which means a consistent snapshot is required. -A consistent snapshot guarantees a consistent and complete state of the virtual machine's disks. Such a snapshot can be created when one of the following conditions is met: +A consistent snapshot guarantees a consistent and complete state of disk data. Such a snapshot can be created when one of the following conditions is met: +- The disk is not attached to any virtual machine — the snapshot will always be consistent. - The virtual machine is turned off. -- [`qemu-guest-agent`](#guest-os-agent) is installed in the guest system, which temporarily suspends the file system at the time the snapshot is created to ensure its consistency. +- [`qemu-guest-agent`](#guest-os-agent) is installed and running in the guest system, which temporarily suspends ("freezes") the file system at the time the snapshot is created to ensure its consistency. -An inconsistent snapshot may not reflect a consistent state of the virtual machine's disks and its components. Such a snapshot is created if the VM is running and `qemu-guest-agent` is not installed or not running in the guest OS. +An inconsistent snapshot may not reflect a consistent state of the virtual machine's disks and its components. Such a snapshot is created if the VM is running and `qemu-guest-agent` is not installed or not running in the guest OS. If the snapshot manifest explicitly specifies the `requiredConsistency: false` parameter, but `qemu-guest-agent` is running, an attempt will be made to freeze the file system to ensure that the snapshot is consistent. QEMU Guest Agent supports hook scripts that allow you to prepare applications for snapshot creation without stopping services, ensuring application-level consistency. For more information on configuring hooks scripts, see the [Guest OS agent](#guest-os-agent) section. @@ -2840,9 +2855,11 @@ Example output: ```txt NAME PHASE CONSISTENT AGE -linux-vm-root-1728027905 Ready 3m2s +linux-vm-root-1728027905 Ready true 3m2s ``` +The `CONSISTENT` field shows whether the snapshot was created consistently (`true`) or not (`false`). This value is determined automatically based on the snapshot creation conditions and cannot be changed after creation. + After creation, `VirtualDiskSnapshot` can be in the following states (phases): - `Pending` - waiting for all dependent resources required for snapshot creation to be ready. @@ -3090,8 +3107,9 @@ d8 k get vmsop -o json | jq '.status.resources' VM cloning is performed using the VirtualMachineOperation resource with the `Clone` operation type. -{{< alert level="warning" >}} -Before cloning, the source VM must be [powered off](#vm-start-and-state-management-policy). +Cloning is supported for both powered-off and running virtual machines. When cloning a running VM, a consistent snapshot is automatically created, from which the clone is then formed. + +{{< alert level="info" >}} It is recommended to set the `.spec.runPolicy: AlwaysOff` parameter in the configuration of the VM being cloned if you want to prevent the VM clone from starting automatically. This is because the clone inherits the behaviour of the parent VM. {{< /alert >}} diff --git a/docs/USER_GUIDE.ru.md b/docs/USER_GUIDE.ru.md index 7a9d9b53a4..9a49f80adf 100644 --- a/docs/USER_GUIDE.ru.md +++ b/docs/USER_GUIDE.ru.md @@ -628,11 +628,6 @@ EOF ![](images/vd-wffc.ru.png) -Режим доступа AccessMode: - -- `ReadWriteMany (RWX)` - множественный доступ к диску. Живая миграция виртуальных машин с такими дисками возможна. -- `ReadWriteOnce (RWO)` - доступ к диску предоставляется только одному экземпляру виртуальной машины. Живая миграция виртуальных машин с такими дисками поддерживается только для платных редакций. - При создании диска контроллер самостоятельно определит наиболее оптимальные параметры поддерживаемые хранилищем. > Внимание: Создать диски из iso-образов - нельзя! @@ -936,6 +931,8 @@ linux-vm-root Ready 11Gi 12m В платных редакциях вы можете мигрировать (перенести) диск виртуальной машины на другое хранилище, изменив для него класс хранилища (StorageClass). +Миграция поддерживается как для статически подключённых дисков, так и для динамически подключённых (hotplug) дисков. + {{< alert level="warning">}} Ограничения миграции дисков между хранилищами: @@ -2710,6 +2707,12 @@ EOF Для этого необходимо указать желаемые сети в конфигурационном разделе `.spec.networks`. Если данный блок не задан (что является значением по умолчанию), ВМ будет использовать только основную сеть кластера. +{{< alert level="info" >}} +Указание основной сети кластера (`type: Main`) в `.spec.networks` является опциональным. Если вам не требуется подключение к основной сети кластера, можно использовать только дополнительные сети (`Network` или `ClusterNetwork`). + +Однако если основная сеть указана, она обязательно должна быть первой в списке `.spec.networks`. +{{< /alert >}} + Особенности и важные моменты работы с дополнительными сетевыми интерфейсами: - порядок перечисления сетей в `.spec.networks` определяет порядок подключения интерфейсов внутри виртуальной машины; @@ -2718,28 +2721,39 @@ EOF - политики сетевой безопасности (NetworkPolicy) не применяются к дополнительным сетевым интерфейсам; - параметры сети (IP-адреса, шлюзы, DNS и т.д.) для дополнительных сетей настраиваются вручную изнутри гостевой ОС (например, с помощью Cloud-Init). -Пример подключения ВМ к проектной сети `user-net`: +Пример подключения ВМ к основной сети кластера и проектной сети `user-net`: ```yaml spec: networks: - - type: Main # Обязательно указывать первым + - type: Main # Если указана, должна быть первой - type: Network # Тип сети (Network \ ClusterNetwork) name: user-net # Название сети ``` -Пример подключения кластерной сети `corp-net`: +Пример подключения к нескольким сетям, включая кластерную сеть `corp-net`: ```yaml spec: networks: - - type: Main # Обязательно указывать первым + - type: Main # Если указана, должна быть первой - type: Network name: user-net - type: ClusterNetwork name: corp-net # Название сети ``` +Пример подключения ВМ только к дополнительным сетям (без основной сети кластера): + +```yaml +spec: + networks: + - type: Network + name: isolated-net + - type: ClusterNetwork + name: corp-net +``` + Информацию о подключённых сетях и их MAC-адресах можно посмотреть в статусе ВМ: ```yaml @@ -2810,13 +2824,14 @@ vm-01-fz9cr 5e:e6:19:22:0f:d8 Attached vm-01 5m42s Снимки могут быть консистентными и неконсистентными. За это отвечает параметр `requiredConsistency`, по умолчанию его значение равно `true`, что означает требование консистентного снимка. -Консистентный снимок гарантирует согласованное и целостное состояние дисков виртуальной машины. Такой снимок можно создать при выполнении одного из следующих условий: +Консистентный снимок гарантирует согласованное и целостное состояние данных диска. Такой снимок можно создать при выполнении одного из следующих условий: +- диск не подключён ни к одной виртуальной машине — снимок всегда будет консистентным; - виртуальная машина выключена; -- в гостевой системе установлен [`qemu-guest-agent`](#агент-гостевой-ос), который на момент создания снимка временно приостанавливает работу файловой системы для обеспечения её согласованности. +- в гостевой системе установлен и запущен [`qemu-guest-agent`](#агент-гостевой-ос), который на момент создания снимка временно приостанавливает («замораживает») работу файловой системы для обеспечения её согласованности. -Неконсистентный снимок может не отражать согласованное состояние дисков виртуальной машины и её компонентов. Такой снимок создаётся, если ВМ запущена, и в гостевой ОС не установлен или не запущен `qemu-guest-agent`. -Если в манифесте снимка явно указан параметр `requiredConsistency: false`, но `qemu-guest-agent` при этом запущен, будет акже предпринята попытка заморозки файловой системы, чтобы снимок получился консистентным. +Неконсистентный снимок может не отражать согласованное состояние дисков виртуальной машины и её компонентов. Такой снимок создаётся, если ВМ запущена, и в гостевой ОС не установлен или не запущен `qemu-guest-agent`. +Если в манифесте снимка явно указан параметр `requiredConsistency: false`, но `qemu-guest-agent` при этом запущен, будет также предпринята попытка заморозки файловой системы, чтобы снимок получился консистентным. QEMU Guest Agent поддерживает скрипты hooks, которые позволяют подготовить приложения к созданию снимка без остановки сервисов, обеспечивая согласованное состояние на уровне приложений. Подробнее о настройке скриптов hooks см. в разделе [«Агент гостевой ОС»](#агент-гостевой-ос). @@ -2874,6 +2889,8 @@ NAME PHASE CONSISTENT AGE linux-vm-root-snapshot Ready true 3m2s ``` +Поле `CONSISTENT` показывает, был ли снимок создан консистентным (`true`) или нет (`false`). Это значение определяется автоматически на основе условий создания снимка и не может быть изменено после создания. + После создания `VirtualDiskSnapshot` может находиться в следующих состояниях (фазах): - `Pending` - ожидание готовности всех зависимых ресурсов, требующихся для создания снимка. @@ -3123,9 +3140,9 @@ d8 k get vmsop -o json | jq '.status.resources' Клонирование ВМ выполняется с использованием ресурса VirtualMachineOperation с типом операции `Clone`. -{{< alert level="warning" >}} -Перед клонированием ВМ должна быть [выключена](#политика-запуска-и-управление-состоянием-вм). +Клонирование поддерживается как для выключенных, так и для работающих виртуальных машин. При клонировании работающей ВМ автоматически создаётся консистентный снимок, из которого затем формируется клон. +{{< alert level="info" >}} Рекомендуется задавать параметр `.spec.runPolicy: AlwaysOff` в конфигурации клонируемой ВМ, чтобы предотвратить автоматический запуск клона ВМ. Это связано с тем, что клон наследует поведение родительской ВМ. {{< /alert >}} @@ -3317,3 +3334,4 @@ d8 data download -n vds/ -o file.img {{< alert level="info" >}} Чтобы импортировать скачанный диск обратно в кластер, загрузите его как [образ](#загрузка-образа-из-командной-строки) или как [диск](#загрузка-диска-из-командной-строки). {{< /alert >}} +