From efeb484523be0fab1e8cbd59c991854653397b5a Mon Sep 17 00:00:00 2001 From: Vladislav Panfilov Date: Mon, 22 Jun 2026 21:56:12 +0400 Subject: [PATCH 1/3] docs: note Discovery instruction set is fixed at creation Signed-off-by: Vladislav Panfilov --- api/core/v1alpha2/virtual_machine_class.go | 1 + api/core/v1alpha3/virtual_machine_class.go | 1 + crds/doc-ru-virtualmachineclasses.yaml | 15 ++++++++++----- crds/virtualmachineclasses.yaml | 2 ++ docs/ADMIN_GUIDE.md | 2 +- docs/ADMIN_GUIDE.ru.md | 2 +- 6 files changed, 16 insertions(+), 7 deletions(-) diff --git a/api/core/v1alpha2/virtual_machine_class.go b/api/core/v1alpha2/virtual_machine_class.go index 637ce3a466..11d4c80a9f 100644 --- a/api/core/v1alpha2/virtual_machine_class.go +++ b/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. // diff --git a/api/core/v1alpha3/virtual_machine_class.go b/api/core/v1alpha3/virtual_machine_class.go index 8bbd7e8121..dba94048c8 100644 --- a/api/core/v1alpha3/virtual_machine_class.go +++ b/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. // diff --git a/crds/doc-ru-virtualmachineclasses.yaml b/crds/doc-ru-virtualmachineclasses.yaml index 4676803064..a141eeed24 100644 --- a/crds/doc-ru-virtualmachineclasses.yaml +++ b/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: | Селектор узлов, на которые разрешено планировать ВМ для запуска. diff --git a/crds/virtualmachineclasses.yaml b/crds/virtualmachineclasses.yaml index df97f0ceb8..c83624e2e1 100644 --- a/crds/virtualmachineclasses.yaml +++ b/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: diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index 300a3df7cb..b688ebae43 100644 --- a/docs/ADMIN_GUIDE.md +++ b/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 >}} diff --git a/docs/ADMIN_GUIDE.ru.md b/docs/ADMIN_GUIDE.ru.md index 8e479ca9d3..69edc01367 100644 --- a/docs/ADMIN_GUIDE.ru.md +++ b/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 >}} From c9dca46e6dcdb93302a6c57a0d86c2eb409ba077 Mon Sep 17 00:00:00 2001 From: Vladislav Panfilov Date: Wed, 24 Jun 2026 13:17:27 +0400 Subject: [PATCH 2/3] docs: update FAQ Signed-off-by: Vladislav Panfilov --- docs/FAQ.md | 40 ++++++++++++++++++++++++++++++++++++++++ docs/FAQ.ru.md | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 80 insertions(+) diff --git a/docs/FAQ.md b/docs/FAQ.md index 90a1ba21e0..af71aec16b 100644 --- a/docs/FAQ.md +++ b/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? diff --git a/docs/FAQ.ru.md b/docs/FAQ.ru.md index fc9efdd69b..33ee8e85b2 100644 --- a/docs/FAQ.ru.md +++ b/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 для конфигурирования виртуальных машин? From d94e63022570758a5085ed01e7ae4c8b9e953f0b Mon Sep 17 00:00:00 2001 From: Vladislav Panfilov Date: Wed, 24 Jun 2026 17:18:59 +0400 Subject: [PATCH 3/3] docs: add full tainted cluster setup notes Signed-off-by: Vladislav Panfilov --- docs/INSTALL.md | 14 ++++++++++++++ docs/INSTALL.ru.md | 14 ++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/docs/INSTALL.md b/docs/INSTALL.md index d17a59197d..4111e63f61 100644 --- a/docs/INSTALL.md +++ b/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: diff --git a/docs/INSTALL.ru.md b/docs/INSTALL.ru.md index ebcd1648de..013eab2633 100644 --- a/docs/INSTALL.ru.md +++ b/docs/INSTALL.ru.md @@ -177,6 +177,20 @@ weight: 15 | `importer-*` | system/worker | | | `uploader-*` | system/worker | | +### Full tainted кластер + +Full tainted кластер относится к кластерам, на всех узлах которых установлены taints (любые). Администратор обычно использует такую конфигурацию, чтобы контролировать, на какие узлы могут попадать поды и виртуальные машины. + +При работе модуля `virtualization` в таком кластере учитывайте особенности настройки, описанные ниже: + +1. Если для [VirtualDisk](/modules/virtualization/cr.html#virtualdisk) используется StorageClass с `volumeBindingMode: Immediate`, PersistentVolume создаётся сразу после создания диска. Это происходит ещё до планирования виртуальной машины. Убедитесь, что provisioner может создавать тома на узлах, которые разрешены для виртуальных машин через [параметры размещения](./user_guide.html#размещение-вм-по-узлам), включая `nodeSelector`, `tolerations` и настройки в `spec` виртуальной машины или [VirtualMachineClass](/modules/virtualization/cr.html#virtualmachineclass). Иначе диск может оказаться на узле, где виртуальная машина не сможет запуститься. + +1. Если StorageClass использует `volumeBindingMode: WaitForFirstConsumer`, том создаётся на узле планирования виртуальной машины, и эта проблема не возникает. + +1. Для работы [VirtualImage](/modules/virtualization/cr.html#virtualimage) и [ClusterVirtualImage](/modules/virtualization/cr.html#clustervirtualimage) нужны поды `importer-*` и `uploader-*` из таблицы выше. У них есть toleration к taint `dedicated.deckhouse.io=system`. + +1. В кластере должна быть NodeGroup `system` либо выделенные узлы с taint `dedicated.deckhouse.io=system`. Без таких узлов образы не перейдут в фазу `Ready`. + ## Обновление модуля Модуль `virtualization` использует пять каналов обновлений, предназначенных для использования в разных окружениях, к которым с точки зрения надежности применяются разные требования: