docs: update docs due 1.10.0

api/core/v1alpha2/virtual_machine_class.go

@@ -188,6 +188,7 @@ type SizingPolicyCores struct {
 // * `HostPassthrough`: Uses the platform node's physical CPU directly, without any modifications.
 // When using this class, the guest VM can only be transferred to a target node with a CPU exactly matching the source node's CPU.
 // * `Discovery`: Create a virtual CPU based on instruction sets of physical CPUs for a selected set of nodes.
+// The feature set is fixed when the resource is created and does not change when nodes are added to or removed from the cluster.
 // * `Model`: CPU model. A CPU model is a named and previously defined set of supported CPU instructions.
 // * `Features`: A required set of supported instructions for the CPU.
 //

api/core/v1alpha3/virtual_machine_class.go

@@ -185,6 +185,7 @@ type SizingPolicyCores struct {
 // * `HostPassthrough`: Uses the platform node's physical CPU directly, without any modifications.
 // When using this class, the guest VM can only be transferred to a target node with a CPU exactly matching the source node's CPU.
 // * `Discovery`: Create a virtual CPU based on instruction sets of physical CPUs for a selected set of nodes.
+// The feature set is fixed when the resource is created and does not change when nodes are added to or removed from the cluster.
 // * `Model`: CPU model. A CPU model is a named and previously defined set of supported CPU instructions.
 // * `Features`: A required set of supported instructions for the CPU.
 //

crds/doc-ru-virtualmachineclasses.yaml

@@ -70,11 +70,16 @@ spec:
                       description: |
                         В качестве типа ресурса поддерживаются следующие варианты:
 
-                        * `Host` - используется виртуальный CPU, максимально близкий к CPU узла платформы по набору инструкций. Это обеспечивает высокую производительность и функциональность, а также совместимость с «живой» миграцией для узлов с похожими типами процессоров. Например, миграция ВМ между узлами с процессорами Intel и AMD не будет работать. Это также справедливо для процессоров разных поколений, так как набор инструкций у них отличается;
-                        * `HostPassthrough` - используется физический CPU узла платформы напрямую, без каких-либо изменений. При использовании данного класса гостевая ВМ может быть перенесена только на целевой узел, у которого CPU точно соответствует CPU исходного узла;
-                        * `Discovery` - создание виртуального CPU на основе наборов инструкций физических CPU для заданного набора узлов;
-                        * `Model` - модель процессора. Модель процессора - это именованный и предварительно определённый набор поддерживаемых инструкций процессора;
-                        * `Features` - необходимый набор поддерживаемых инструкций для процессора.
+                        * `Host` — используется виртуальный CPU, максимально близкий к CPU узла платформы по набору инструкций.
+                        Это обеспечивает высокую производительность и функциональность, а также совместимость с «живой» миграцией для узлов с похожими типами процессоров.
+                        Например, миграция ВМ между узлами с процессорами Intel и AMD не будет работать.
+                        Это также справедливо для процессоров разных поколений, так как набор инструкций у них отличается.
+                        * `HostPassthrough` — используется физический CPU узла платформы напрямую, без каких-либо изменений.
+                        При использовании данного класса гостевая ВМ может быть перенесена только на целевой узел, у которого CPU точно соответствует CPU исходного узла.
+                        * `Discovery` — создание виртуального CPU на основе наборов инструкций физических CPU для заданного набора узлов.
+                        Набор инструкций фиксируется при создании ресурса и не меняется при добавлении или удалении узлов в кластере.
+                        * `Model` — модель процессора. Модель процессора — это именованный и предварительно определённый набор поддерживаемых инструкций процессора.
+                        * `Features` — необходимый набор поддерживаемых инструкций для процессора.
                 nodeSelector:
                   description: |
                     Селектор узлов, на которые разрешено планировать ВМ для запуска.

crds/virtualmachineclasses.yaml

@@ -152,6 +152,7 @@ spec:
                         * `HostPassthrough`: Uses the platform node's physical CPU directly, without any modifications.
                         When using this class, the guest VM can only be transferred to a target node with a CPU exactly matching the source node's CPU.
                         * `Discovery`: Create a virtual CPU based on instruction sets of physical CPUs for a selected set of nodes.
+                        The feature set is fixed when the resource is created and does not change when nodes are added to or removed from the cluster.
                         * `Model`: CPU model. A CPU model is a named and previously defined set of supported CPU instructions.
                         * `Features`: A required set of supported instructions for the CPU.
                       enum:
@@ -651,6 +652,7 @@ spec:
                         * `HostPassthrough`: Uses the platform node's physical CPU directly, without any modifications.
                         When using this class, the guest VM can only be transferred to a target node with a CPU exactly matching the source node's CPU.
                         * `Discovery`: Create a virtual CPU based on instruction sets of physical CPUs for a selected set of nodes.
+                        The feature set is fixed when the resource is created and does not change when nodes are added to or removed from the cluster.
                         * `Model`: CPU model. A CPU model is a named and previously defined set of supported CPU instructions.
                         * `Features`: A required set of supported instructions for the CPU.
                       enum:

docs/ADMIN_GUIDE.md

@@ -588,7 +588,7 @@ The administrator can modify the parameters of the `generic` VirtualMachineClass
 
 It is not recommended to use the `generic` VirtualMachineClass for running workloads in production environments, since this class corresponds to a CPU with the smallest feature set.
 
-After all nodes are configured and added to the cluster, it is recommended to create at least one VirtualMachineClass resource of the `Discovery` type. This ensures that the best available CPU configuration compatible with all CPUs in your cluster is selected, allows virtual machines to make full use of CPU capabilities, and enables seamless migration between nodes.
+After all nodes are configured and added to the cluster, it is recommended to create at least one VirtualMachineClass resource of the `Discovery` type. This ensures that the best available CPU configuration compatible with all CPUs in your cluster is selected, allows virtual machines to make full use of CPU capabilities, and enables seamless migration between nodes. For the `Discovery` type, the instruction set is fixed when the resource is created and does not change when nodes are added to or removed from the cluster.
 
 For a configuration example, see [vCPU Discovery configuration example](#vcpu-discovery-configuration-example).
 {{< /alert >}}

docs/ADMIN_GUIDE.ru.md

@@ -594,7 +594,7 @@ VirtualImage           default              ubuntu-2404
 
 Не рекомендуется использовать VirtualMachineClass `generic` для запуска рабочих нагрузок в production-средах, поскольку данный класс соответствует процессору с наименьшей функциональностью.
 
-Рекомендуется после добавления и настройки всех узлов в кластере создать хотя бы один ресурс VirtualMachineClass с типом `Discovery`. Это обеспечит выбор наилучшей доступной конфигурации процессора с учётом всех CPU в вашем кластере, позволит виртуальным машинам максимально эффективно использовать возможности процессоров и обеспечит беспрепятственную миграцию между узлами.
+Рекомендуется после добавления и настройки всех узлов в кластере создать хотя бы один ресурс VirtualMachineClass с типом `Discovery`. Это обеспечит выбор наилучшей доступной конфигурации процессора с учётом всех CPU в вашем кластере, позволит виртуальным машинам максимально эффективно использовать возможности процессоров и обеспечит беспрепятственную миграцию между узлами. Набор инструкций для типа `Discovery` фиксируется при создании ресурса и не меняется при добавлении или удалении узлов в кластере.
 
 Пример настройки смотрите в разделе [Пример конфигурации vCPU Discovery](#пример-конфигурации-vcpu-discovery).
 {{< /alert >}}

docs/FAQ.md

@@ -549,6 +549,46 @@ A golden image is a pre-configured virtual machine image that can be used to qui
 
 After completing these steps, you will have a golden image that can be used to quickly create new virtual machines with pre-installed software and configurations.
 
+### Connecting to a virtual machine
+
+You can connect to a VM via the serial console ([`d8 v console`](https://deckhouse.io/products/kubernetes-platform/documentation/v1/cli/d8/reference/#d8-v-console)) or VNC ([`d8 v vnc`](https://deckhouse.io/products/kubernetes-platform/documentation/v1/cli/d8/reference/#d8-v-vnc)).
+These methods use different communication channels with the guest OS and depend on its configuration.
+For more details on connecting, see the [Connecting to a virtual machine](user_guide.html#connecting-to-a-virtual-machine) section.
+
+The sections below describe common situations where only one connection method works.
+
+#### No VNC access, but the serial console works
+
+VNC displays the guest OS screen and requires virtual terminal support in the kernel.
+The serial console works independently of the graphics subsystem.
+
+Check in the guest OS whether virtual terminal support is enabled in the kernel configuration:
+
+```bash
+cat /boot/config-$(uname -r) | grep CONFIG_VT
+```
+
+The output should show `CONFIG_VT=y`:
+
+```console
+CONFIG_VT=y
+```
+
+If the output shows `CONFIG_VT is not set`, rebuild the kernel with the option enabled or use an OS image with a suitable kernel configuration.
+
+#### No serial console access, but VNC works
+
+The serial console connects to the `ttyS0` port in the guest OS.
+If the `getty` service for this port is not running, `d8 v console` will not show a login prompt even though VNC continues to work.
+
+In the guest OS, enable and start the `serial-getty` service for `ttyS0`:
+
+```bash
+sudo systemctl enable --now serial-getty@ttyS0.service
+```
+
+Then connect to the serial console again.
+
 ## Configuring virtual machines
 
 ### How to use cloud-init to configure virtual machines?

docs/FAQ.ru.md

@@ -549,6 +549,46 @@ Golden image — это предварительно настроенный об
 
 После выполнения всех шагов у вас будет Golden image, который можно использовать для быстрого создания новых виртуальных машин с предустановленным программным обеспечением и настройками.
 
+### Подключение к виртуальной машине
+
+К ВМ можно подключиться через серийную консоль ([`d8 v console`](https://deckhouse.ru/products/kubernetes-platform/documentation/v1/cli/d8/reference/#d8-v-console)) или по VNC ([`d8 v vnc`](https://deckhouse.ru/products/kubernetes-platform/documentation/v1/cli/d8/reference/#d8-v-vnc)).
+Способы используют разные каналы связи с гостевой ОС и зависят от её настройки.
+Подробнее о подключении описано в разделе [Подключение к виртуальной машине](user_guide.html#подключение-к-виртуальной-машине).
+
+Ниже перечислены типовые ситуации, когда доступен только один из способов подключения.
+
+#### Нет доступа по VNC, но серийная консоль работает
+
+VNC выводит изображение экрана гостевой ОС и требует поддержки виртуального терминала в ядре.
+Серийная консоль при этом работает независимо от графической подсистемы.
+
+Проверьте в гостевой ОС, включена ли поддержка виртуального терминала в конфигурации ядра:
+
+```bash
+cat /boot/config-$(uname -r) | grep CONFIG_VT
+```
+
+В выводе значение `CONFIG_VT` должно быть `y`:
+
+```console
+CONFIG_VT=y
+```
+
+Если в выводе указано `CONFIG_VT is not set`, пересоберите ядро с включённым параметром либо используйте образ ОС с подходящей конфигурацией ядра.
+
+#### Нет доступа по серийной консоли, но VNC работает
+
+Серийная консоль подключается к порту `ttyS0` в гостевой ОС.
+Если служба `getty` для этого порта не запущена, при подключении через `d8 v console` не появится приглашение ко входу, хотя VNC продолжит работать.
+
+В гостевой ОС включите и запустите службу `serial-getty` для `ttyS0`:
+
+```bash
+sudo systemctl enable --now serial-getty@ttyS0.service
+```
+
+После этого снова подключитесь к серийной консоли.
+
 ## Конфигурирование виртуальных машин
 
 ### Как использовать cloud-init для конфигурирования виртуальных машин?

docs/INSTALL.md

@@ -177,6 +177,20 @@ Components used to create and import virtual machine images or disks (they run o
 | `importer-*`   | system/worker |         |
 | `uploader-*`   | system/worker |         |
 
+### Full tainted cluster
+
+A full tainted cluster is one where all nodes have taints (any taints). Administrators typically use this configuration to control which nodes pods and virtual machines can be scheduled onto.
+
+When running the `virtualization` module in such a cluster, account for the configuration details below:
+
+1. If a [VirtualDisk](/modules/virtualization/cr.html#virtualdisk) uses a StorageClass with `volumeBindingMode: Immediate`, a PersistentVolume is created as soon as the disk is created. This happens before the virtual machine is scheduled. Make sure the provisioner can create volumes on nodes that are allowed for virtual machines through [placement settings](./user_guide.html#placement-of-vms-by-nodes), including `nodeSelector`, `tolerations`, and settings in the virtual machine `spec` or [VirtualMachineClass](/modules/virtualization/cr.html#virtualmachineclass). Otherwise, the disk may end up on a node where the virtual machine cannot run.
+
+2. If the StorageClass uses `volumeBindingMode: WaitForFirstConsumer`, the volume is created on the node where the virtual machine is scheduled, and this issue does not occur.
+
+3. [VirtualImage](/modules/virtualization/cr.html#virtualimage) and [ClusterVirtualImage](/modules/virtualization/cr.html#clustervirtualimage) require the `importer-*` and `uploader-*` pods from the table above. They have a toleration for the `dedicated.deckhouse.io=system` taint.
+
+4. The cluster must have a `system` NodeGroup or dedicated nodes with the `dedicated.deckhouse.io=system` taint. Without such nodes, images will not reach the `Ready` phase.
+
 ## Module update
 
 The `virtualization` module uses five update channels designed for use in different environments that have different requirements in terms of reliability: