Руководство пользователя

Руководство описывает, как создавать и изменять ресурсы модуля virtualization в проекте или неймспейсе кластера.

Быстрый старт по созданию виртуальной машины

В разделе показан минимальный сценарий, в котором вы создаёте образ Ubuntu 24.04, диск из этого образа и виртуальную машину (ВМ), подключаетесь к ней по консоли, а затем удаляете созданные ресурсы.

Образы

Образ хранит содержимое диска, из которого вы создаёте диски виртуальных машин. Образ VirtualImage создаётся в проекте и доступен только в том проекте или неймспейсе, где он создан.

Виртуальная машина получает доступ к подключённому образу в режиме «только чтение».

Образ появляется в проекте в три шага:

1. Вы создаёте ресурс VirtualImage и указываете в нём источник данных.
2. Deckhouse Platform (DP) загружает образ из этого источника в хранилище, которым в зависимости от выбранного типа выступает DVCR или PVC.
3. Загруженный образ становится доступен для создания дисков.

Источники и варианты хранения

Источником образа может быть HTTP-сервер с файлом образа, хранилище образов контейнеров или файл на вашем компьютере, который вы загружаете из командной строки. Кроме того, образ можно создать из другого образа, из диска виртуальной машины или из снимка диска.

Виды образов, поддерживаемые форматы файлов и алгоритмы сжатия описаны в разделе «Типы и форматы образов» руководства администратора.

Загруженный образ хранится одним из двух способов, который задаёт параметр .spec.storage:

• ContainerRegistry — вариант по умолчанию, образ хранится в DVCR.
• PersistentVolumeClaim — образ хранится в PVC. Этот вариант предпочтителен, если хранилище умеет быстро клонировать PVC, потому что диски из такого образа создаются быстрее.

Ход создания образа показывает колонка PHASE в выводе d8 k get vi, её значения описаны в поле .status.phase. Следить за созданием в реальном времени помогает ключ -w, а если образ надолго остаётся не готов, причину подскажет блок .status.conditions и команда d8 k describe vi.

Пока образ не перешёл в фазу Ready, блок .spec можно менять, и после изменения загрузка начнётся заново. У готового образа блок .spec изменить уже нельзя. Все параметры образа описаны в VirtualImage.

Создание образа с HTTP-сервера

Проще всего создать образ, указав ссылку на файл, который лежит на HTTP-сервере.

Проверка целостности загруженного образа

Блок checksum заставляет DP проверить то, что он скачал с HTTP-сервера. Образ перейдёт в фазу Ready, только если загруженный файл совпал со всеми указанными контрольными суммами, иначе ресурс окажется в фазе Failed:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualImage
metadata:
  name: ubuntu-24-04
spec:
  storage: ContainerRegistry
  dataSource:
    type: HTTP
    http:
      url: https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
      checksum:
        sha256: 78be890d71dde316c412da2ce8332ba47b9ce7a29d573801d2777e01aa20b9b5
EOF

Возьмите контрольную сумму у зеркала, которое публикует образ, и укажите её в поле соответствующего алгоритма:

Скорости даны как порядок величины, а не как обещание. Они измерены на процессоре x86-64 с набором инструкций SHA, а процессор без него считает SHA-1 и SHA-256 в несколько раз медленнее. На любом процессоре сохраняется другое, а именно расстояние между строками. SHA-1 и SHA-256 вычисляются отдельными инструкциями, MD5 и SHA-512 написанным вручную ассемблером, и все четыре хешируют данные быстрее, чем те приходят по сети, поэтому их стоимость остаётся незаметной на фоне самой загрузки.

Алгоритмы «Стрибог» аппаратной поддержки не имеют нигде и медленнее примерно на два порядка. Для образа в 10 ГиБ это около десяти минут одного только хеширования, и создание образа упирается уже в процессор, а не в сеть. Указывайте их только тогда, когда контрольная сумма по ГОСТ действительно требуется. Обе длины стоят одинаково, потому что ГОСТ Р 34.11-2012 использует одну и ту же функцию сжатия и для 256, и для 512 бит, а короткий вариант отличается только начальным значением.

Контрольные суммы считаются за один проход по загружаемым данным, поэтому указание нескольких сумм сразу стоит суммы их времён. Незаполненные поля не стоят ничего.

Тот же блок доступен для источника Upload в параметре dataSource.upload.checksum и работает так же. Загружаемые данные проверяются по всем указанным контрольным суммам, а при несовпадении ресурс остаётся в фазе Failed.

Хранение образа в PVC

Чтобы диски создавались из образа быстрее, храните его в PVC. Тогда DP сможет клонировать том вместо повторной распаковки.

Создание образа из хранилища образов контейнеров

DP умеет забирать образ из внешнего хранилища образов контейнеров, но файл диска должен лежать в образе контейнера по пути /disk. Ниже показано, как подготовить такой образ контейнера и создать из него образ проекта.

Загрузка образа из командной строки

Если файл образа лежит на вашем компьютере, загрузите его напрямую. DP создаёт для этого временную точку приёма данных и ждёт загрузки.

Создание образа из диска

Образ можно создать из диска, если диск не подключён ни к одной виртуальной машине либо машина, к которой он подключён, выключена.

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualImage
metadata:
  name: linux-vm-root
spec:
  storage: ContainerRegistry
  dataSource:
    type: ObjectRef
    objectRef:
      kind: VirtualDisk
      name: linux-vm-root
EOF

Создание образа из снимка диска

Образ можно создать из снимка диска, если снимок находится в фазе Ready.

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualImage
metadata:
  name: linux-vm-root
spec:
  storage: ContainerRegistry
  dataSource:
    type: ObjectRef
    objectRef:
      kind: VirtualDiskSnapshot
      name: linux-vm-root-snapshot
EOF

Свойства образа удобно смотреть в веб-интерфейсе, в разделе «Виртуализация» → «Образы»:

• список показывает имя образа, статус, размер, формат в колонке «Тип» и область видимости в колонке «Доступность», а фильтры сужают его по статусу, образу и типу;
• на странице образа вкладка «Информация» собирает параметры создания в блоках «Хранилище» и «Источник», а в блоке «Состояние» показывает среднюю скорость загрузки, формат, распакованный размер, размер в хранилище, длительность создания, признак «CD-ROM» и путь к образу в DVCR;
• вкладки «Мета» и «YAML» показывают лейблы с аннотациями и полную спецификацию ресурса.

Диски

Диск хранит данные виртуальной машины (ВМ), включая операционную систему и файлы приложений. Описывает диск ресурс VirtualDisk, а его спецификация состоит из двух блоков:

• persistentVolumeClaim — параметры хранения, то есть StorageClass и размер;
• dataSource — источник данных, которым может быть образ, другой диск или снимок.

Без блока dataSource создаётся пустой диск, и тогда в persistentVolumeClaim нужно указать хотя бы размер. Если источник задан, блок persistentVolumeClaim можно опустить, тогда размер DP возьмёт из источника, а класс хранения подберёт по нему же. Когда подобрать класс не удаётся, DP использует StorageClass по умолчанию на уровне кластера либо класс, заданный для дисков в настройках модуля.

Ход создания диска показывает колонка PHASE в выводе d8 k get vd, её значения описаны в поле .status.phase. Если диск надолго остаётся не готов, причину подскажет блок .status.conditions.

Пока диск не перешёл в фазу Ready, менять можно любые поля блока .spec, и после изменения создание начнётся заново. У готового диска остаются изменяемыми только размер и класс хранения в параметрах .spec.persistentVolumeClaim.size и .spec.persistentVolumeClaim.storageClassName.

Влияние хранилища на диск

Поведение диска зависит от того, какое хранилище стоит за выбранным StorageClass. Различия проявляются в двух свойствах.

Тип тома определяет формат, в котором DP создаёт диск. На томах файловой системы (FileSystem, например NFS) диск создаётся в формате qcow2, на блочных устройствах (Block, например iSCSI или Ceph RBD) данные пишутся напрямую. Некоторые хранилища поддерживают оба типа.

Режим привязки тома определяет момент создания диска:

• Immediate — диск создаётся сразу, независимо от виртуальных машин, и подключить его можно к машине на любом узле кластера.

  

• WaitForFirstConsumer — диск создаётся только после того, как его подключат к виртуальной машине, и размещается на узле, где эта машина запускается.

  

Остальные параметры, включая формат диска, DP определяет сам по возможностям выбранного StorageClass.

Чтобы посмотреть доступные хранилища, выполните команду:

d8 k get storageclass

Пример вывода:

NAME                   PROVISIONER                           RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
rv-thin-r1 (default)   replicated.csi.storage.deckhouse.io   Delete          Immediate              true                   48d
rv-thin-r2             replicated.csi.storage.deckhouse.io   Delete          Immediate              true                   48d
nfs-4-1-wffc           nfs.csi.k8s.io                        Delete          WaitForFirstConsumer   true                   30d

В веб-интерфейсе тот же список доступен на вкладке «Система» в разделе «Хранилище» → «Классы хранилищ».

Создание пустого диска

Пустой диск нужен, чтобы установить на него операционную систему или хранить данные отдельно от системного диска.

Создание диска из образа

Диск можно заполнить данными из образа, созданного ранее, будь то проектный VirtualImage или кластерный ClusterVirtualImage.

Размер диска указывать необязательно. Если вы его не задали, DP создаст диск ровно по распакованному размеру образа, а если задали, размер должен быть не меньше распакованного.

Загрузка диска из командной строки

Если файл образа лежит на вашем компьютере, загрузите его сразу в диск. DP создаёт для этого временную точку приёма данных и ждёт загрузки.

Свойства диска удобно смотреть в веб-интерфейсе, в разделе «Виртуализация» → «Диски»:

• список показывает имя диска, статус, размер, класс хранения в колонке «Класс», использующую диск виртуальную машину в колонке «Используется» и возраст ресурса;
• на странице диска вкладка «Конфигурация» показывает источник данных, размер, класс хранения и список ВМ в строке «Используется в»;
• вкладка «Диагностика» показывает имя PVC, его фазу, размер, класс хранения, имя PV и возраст, а также длительность этапов создания диска в блоке «Сводка диагностики».

Изменение размера диска

Диск можно увеличить, даже если он подключён к работающей виртуальной машине (ВМ). Уменьшить диск нельзя.

Миграция дисков на другие хранилища

В коммерческих редакциях DP диск можно перенести в другое хранилище, изменив его класс хранения. Перенос работает и для дисков, заданных в спецификации ВМ, и для подключённых отдельным ресурсом.

Чтобы перенести диск, укажите новый класс хранения в параметре .spec.persistentVolumeClaim.storageClassName:

d8 k patch vd disk --type=merge --patch '{"spec":{"persistentVolumeClaim":{"storageClassName":"new-storage-class-name"}}}'

# Того же результата можно добиться, отредактировав ресурс.
d8 k edit vd disk

После этого запускается живая миграция ВМ, в ходе которой диск переезжает в новое хранилище.

Если перенести нужно несколько дисков одной машины, меняйте класс хранения последовательно, по одному диску за раз:

d8 k patch vd disk1 --type=merge --patch '{"spec":{"persistentVolumeClaim":{"storageClassName":"new-storage-class-name"}}}'
d8 k patch vd disk2 --type=merge --patch '{"spec":{"persistentVolumeClaim":{"storageClassName":"new-storage-class-name"}}}'

Неудачную миграцию DP повторяет с растущей задержкой. Первая попытка идёт сразу, следующие через 5 и 10 секунд, дальше задержка удваивается и с седьмой попытки остаётся равной 300 секундам. Чтобы отменить миграцию, верните в спецификации прежний класс хранения.

Экспорт диска или снимка

Экспорт выгружает содержимое диска или его снимка в файл, чтобы перенести данные за пределы кластера. Для работы этой функции должен быть включён модуль storage-volume-data-manager, а в командной строке нужна утилита d8 версии 0.20.7 и выше.

Чтобы импортировать скачанный диск обратно в кластер, загрузите его как образ или как диск.

d8 data export download -n <NAMESPACE> vd/<VD_NAME> -o file.img

d8 data export download -n <NAMESPACE> vds/<VD_SNAPSHOT_NAME> -o file.img

Виртуальные машины

Для создания виртуальной машины (ВМ) используется ресурс VirtualMachine. Его параметры позволяют сконфигурировать:

• класс виртуальной машины;
• ресурсы, требуемые для работы виртуальной машины (процессор, память, диски и образы);
• правила размещения виртуальной машины на узлах кластера;
• настройки загрузчика и оптимальные параметры для гостевой ОС;
• политику запуска виртуальной машины и политику применения изменений;
• сценарии начальной конфигурации (cloud-init);
• перечень блочных устройств.

С полным описанием параметров конфигурации виртуальных машин можно ознакомиться по в документации конфигурации.

Создание виртуальной машины

Ниже показано, как запустить виртуальную машину с Ubuntu 24.04 на диске, созданном ранее. Сценарий cloud-init устанавливает агента qemu-guest-agent и сервис nginx, а также создаёт пользователя cloud с паролем cloud.

Жизненный цикл ВМ

От создания до удаления виртуальная машина проходит через несколько фаз. Текущую показывает поле .status.phase, а подробности о том, что с машиной происходит, содержит блок .status.conditions.

Условия в блоке .status.conditions отвечают на вопрос, почему машина находится в текущей фазе. Посмотреть те из них, где есть сообщение, можно так:

d8 k get vm <VM_NAME> -o json | jq '.status.conditions[] | select(.message != "")'

Здесь <VM_NAME> — имя виртуальной машины.

Диагностика по фазам

Пока ВМ находится в фазе Pending, она ждёт готовности зависимых ресурсов, то есть дисков, образов, класса ВМ, секрета со сценарием начальной конфигурации. Задержка на этой фазе означает, что какой-то из ресурсов не готов либо исчерпаны квоты неймспейса или проекта. Что именно блокирует запуск, показывают условия, оканчивающиеся на Ready:

d8 k get vm <VM_NAME> -o json | jq '.status.conditions[] | select(.type | test(".*Ready"))'

В фазе Starting зависимые ресурсы готовы, и DP запускает ВМ на одном из узлов. Если запуск затягивается, подходящего узла нет либо на подходящих узлах не хватает процессора или памяти. Причину сообщает условие Running:

d8 k get vm <VM_NAME> -o json | jq '.status.conditions[] | select(.type=="Running")'

В фазе Migrating машина переезжает на другой узел живой миграцией. Миграция не начнётся или прервётся, если наборы процессорных инструкций на узлах несовместимы, версии ядра различаются, ни один узел не подходит под правила размещения или на подходящих узлах не хватает ресурсов. Ход миграции показывает условие Migrating вместе с блоком .status.migrationState:

d8 k get vm <VM_NAME> -o json | jq '.status | {condition: .conditions[] | select(.type=="Migrating"), migrationState}'

Фаза Terminating необратима, все связанные с ВМ ресурсы освобождаются, но сами ресурсы не удаляются.

Условия запущенной ВМ

У работающей машины стоит следить за несколькими условиями:

• AgentReady со статусом True означает, что в гостевой системе работает qemu-guest-agent, и тогда блок .status.guestOSInfo содержит сведения о гостевой ОС.
• FirmwareUpToDate со статусом False означает, что прошивку ВМ пора обновить.
• ConfigurationApplied со статусом False означает, что заданная конфигурация к запущенной машине ещё не применена.
• AwaitingRestartToApplyConfiguration со статусом True означает, что часть изменений применится только после перезагрузки, и выполнить её нужно вручную.
• SizingPolicyMatched со статусом False означает, что ресурсы машины не отвечают политике сайзинга её класса. Пока вы не приведёте параметры в соответствие политике, сохранить изменения конфигурации не получится.
• Migratable показывает, можно ли перенести машину живой миграцией. Условие вычисляется только для запущенной ВМ, у выключенной оно отсутствует. Статус False с причиной VirtualMachineNoMigrationTarget означает, что сама машина к миграции пригодна, но подходящего узла в кластере нет. Статус True с причиной VirtualMachineWaitingForMigrationTarget означает, что подходящие узлы есть, но сейчас ни один не может принять машину, и такое состояние проходит само.

Вытеснение с узла

Условие EvictionRequired появляется, когда узел с вашей ВМ переводят в режим обслуживания. Если узел только вывели из планирования командой d8 k cordon, но обслуживание не начали, условие не появляется.

Сообщение условия говорит, что произойдёт с машиной, а именно перенос живой миграцией без остановки гостевой ОС, перезапуск силами DP с разрешения администратора кластера либо ожидание, пока машину не перезапустят. Машину, которую можно перенести живой миграцией, ради освобождения узла не перезапускают. Пока вытеснение не началось, условие носит предупреждающий характер, потому что обслуживание могут отменить.

После перезапуска машина запускается на другом подходящем узле. Если такого узла нет, она остаётся в фазе Pending, а причину от планировщика показывает условие Running. Узел в режиме обслуживания новые машины не принимает, поэтому ВМ, закреплённая за ним правилами размещения или использующая проброшенное с него устройство, запустится только после возвращения узла в работу.

Просмотр состояния в веб-интерфейсе

Веб-интерфейс показывает фазу машины, её ресурсы и текущие проблемы на странице самой машины.

1. Перейдите на вкладку «Проекты» и выберите нужный проект.
2. Перейдите в раздел «Виртуализация» → «Виртуальные машины».
3. Из списка выберите нужную ВМ и нажмите на её имя.

В шапке страницы показаны текущая фаза ВМ, её IP-адрес, класс, конфигурация ресурсов, количество подключённых дисков и образов, узел размещения, признак работы агента гостевой ОС и время с момента запуска. Сама страница разделена на вкладки «Конфигурация», «Мониторинг», «Операции», «События», «VNC», «TTY», «Сетевые политики», «Снимки», «Диагностика», «Мета» и «YAML».

На вкладке «Конфигурация» у запущенной ВМ рядом с полями «Ядра ЦП» и «Объём памяти» отображаются графики использования. В блоке «Диски» для каждого устройства показаны порядковый номер загрузки, имя, размер, статус, способ подключения, класс хранения и текущая нагрузка на диск. В блоке «Сети» показаны имя сети, её статус, IP- и MAC-адреса, а основная сеть кластера обозначена как «Main».

Настройки CPU и coreFraction

Процессорные ресурсы машины задают два параметра. Параметр .spec.cpu.cores определяет число виртуальных ядер, а .spec.cpu.coreFraction — гарантированную долю мощности каждого из них.

spec:
  cpu:
    cores: 2
    coreFraction: 20%

В этом примере машина получает два виртуальных ядра и гарантированные 20% мощности каждого, то есть 0,4 ядра в сумме, независимо от загрузки узла. Когда на узле есть свободные ресурсы, машина может занять оба ядра целиком. Такой запас позволяет держать на узле больше машин, чем на нём физических ядер, и при этом не терять стабильность под нагрузкой.

Если coreFraction не задан, каждое виртуальное ядро получает 100% физического.

Гарантированная доля учитывается при выборе узла, поэтому машина не запустится там, где узел не может обеспечить гарантии всем размещённым на нём машинам. На рисунке показаны две машины с одним ядром каждая, у первой coreFraction: 20%, у второй coreFraction: 80%.

Автоматический coreFraction (Auto)

Долю процессорного времени DP может подбирать сам, следя за тем, сколько машина потребляет.

Вместо фиксированного процента можно задать coreFraction: Auto. Тогда долю подбирает DP, повышая её, когда машине не хватает процессора, и понижая, когда машина простаивает. Число ядер и объём памяти при этом не меняются, а новая доля применяется без перезагрузки.

spec:
  cpu:
    cores: 4
    coreFraction: Auto

Подбор устроен так:

• Начальная доля ядра — 10% или ближайшее значение, разрешённое политикой сайзинга.
• Доля меняется шагами. Если в политике сайзинга класса задан список coreFractions, шагами становятся его значения, иначе используются 5%, 10%, 15%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90% и 99%.
• Значение 100% автоматически не выбирается, потому что при нём запросы процессора сравниваются с лимитами, а такую машину нельзя изменить без перезагрузки. Если 100% указан в coreFractions, он просто не используется, и потолком становится следующее значение вниз, а без политики сайзинга потолок равен 99%.
• По той же причине политика сайзинга должна оставлять хотя бы два значения на выбор. Политика, разрешающая только 50% либо 50% и 100%, навсегда зафиксировала бы машину на 50%, поэтому такое сочетание отклоняется, и долю придётся задать явно.
• Рекомендованное значение публикуется в поле .status.recommendedResources.cpu.coreFraction, а применённое — в .status.resources.cpu.coreFraction. О каждом изменении сообщает событие CoreFractionScaling.
• Если на узле не хватает места под новые запросы, машина переезжает на другой узел и продолжает работать.

Идёт ли подбор, показывает условие CoreFractionAutoscaling. Пока подбор работает, условие имеет статус True, а первые минуты, пока не накопится статистика, причиной будет WaitingForRecommendation, затем CoreFractionAutoscalingEnabled.

Если подбор стал недоступен, условие переходит в False, и причина объясняет, почему это произошло:

• CoreFractionAutoscalingDisabled — выключено вертикальное автомасштабирование;
• InPlaceResizeDisabled — выключено изменение ресурсов на лету;
• SizingPolicyHasNoSteps — политику сайзинга сузили до одного значения.

Машина при этом продолжает работать с текущей долей, но перестаёт следовать за нагрузкой.

Чтобы отказаться от автоматического подбора, задайте явный процент. Переход между 100% и Auto в любую сторону требует перезагрузки машины, потому что меняет её класс QoS, а остальные переходы применяются на лету.

Политика сайзинга

Администратор может ограничить сочетания ресурсов, доступные машинам определённого класса, задав политику сайзинга в параметре .spec.sizingPolicies ресурса VirtualMachineClass. Если политики нет, ресурсы задаются произвольно.

Политика делит число ядер на диапазоны и для каждого задаёт допустимый объём памяти и разрешённые значения coreFraction:

spec:
  sizingPolicies:
    - cores:
        min: 1
        max: 4
      memory:
        min: 1Gi
        max: 8Gi
      coreFractions: [5, 10, 20, 50, 100]
    - cores:
        min: 5
        max: 8
      memory:
        min: 5Gi
        max: 16Gi
      coreFractions: [20, 50, 100]

С такой политикой машина с двумя ядрами попадает в первый диапазон, получает от 1 до 8 ГиБ памяти и одно из значений 5%, 10%, 20%, 50% или 100%. Машина с шестью ядрами попадает во второй диапазон, где памяти доступно от 5 до 16 ГиБ, а долей ядра — 20%, 50% или 100%.

Политика ограничивает и переподписку. Например, минимальное значение coreFraction: 20% гарантирует каждой машине пятую часть ядра, а значит переподписка не превысит 5 к 1.

Если конфигурация машины политике не отвечает, в статусе появляется условие SizingPolicyMatched со статусом False. Такая машина продолжает работать, но сохранить изменения её конфигурации не получится, пока ресурсы не приведут в соответствие политике. Это же происходит, когда администратор меняет политику у класса уже работающих машин.

Кроме границ диапазон может задавать шаг сетки в параметрах cores.step и memory.step, а также границы памяти в расчёте на одно ядро в блоке memory.perCore.

Запрос, нарушающий политику, отклоняется с сообщением, в котором указаны параметр и допустимые значения. Каждое сообщение заканчивается подсказкой check the sizing policy of the VirtualMachineClass or contact the administrator for more information, ниже она опущена.

Для класса supercpu с политикой выше сообщения выглядят так:

• число ядер вне всех диапазонов, cores: 10 — does not match any sizing policy of VirtualMachineClass "supercpu": its 10 CPU core(s) fall outside the allowed ranges (1-4, 5-8); set the number of cores (spec.cpu.cores) accordingly;
• недопустимая доля ядра, cores: 2 и coreFraction: 30% — the CPU core fraction "30%" is not allowed; set the core fraction (spec.cpu.coreFraction) to one of: 5%, 10%, 20%, 50%, 100%;
• память вне диапазона, cores: 2 и size: 16Gi — the memory size (16Gi) is out of the range allowed by the sizing policy; set the memory size (spec.memory.size) between 1Gi and 8Gi.

Если в диапазоне заданы шаг или границы памяти на ядро, добавляются ещё четыре сообщения:

• ядра не на сетке шага — the number of CPU cores (7) does not match the sizing policy step; set the number of cores (spec.cpu.cores) to 6 or 8;
• память не на сетке шага — the memory size (1536Mi) does not match the sizing policy step; set the memory size (spec.memory.size) to 1Gi or 2Gi;
• память на ядро вне диапазона — the memory size (18Gi) is not allowed for 6 CPU core(s); set the memory size (spec.memory.size) between 6Gi and 12Gi, or change the number of cores (spec.cpu.cores) (the sizing policy allows between 1Gi and 2Gi of memory per core);
• память на ядро не на сетке шага — the memory size (2560Mi) does not match the per-core sizing policy step for 2 CPU core(s); set the memory size (spec.memory.size) to 2Gi or 4Gi, or change the number of cores (spec.cpu.cores).

Когда нарушений несколько, все причины перечисляются в одном сообщении под заголовком does not match the sizing policy of VirtualMachineClass "supercpu" for several reasons:.

Топологии CPU

Топология определяет, как ядра процессора машины распределяются по сокетам, и от неё зависит совместимость с приложениями, чувствительными к конфигурации процессора. Вы задаёте только общее число ядер в параметре .spec.cpu.cores, а число сокетов DP рассчитывает сам:

spec:
  cpu:
    cores: 20

Чем больше ядер, тем на большее число сокетов они делятся, и тем крупнее шаг, с которым можно менять их количество. Общее число ядер должно быть кратно числу сокетов, иначе запрос отклоняется.

Например, 20 ядер дают два сокета по 10 ядер, а 80 ядер — восемь сокетов по 10. Максимум для одной машины составляет 248 ядер.

Рассчитанную топологию DP публикует в статусе:

status:
  resources:
    cpu:
      topology:
        coresPerSocket: 10
        sockets: 2

Накладные расходы памяти зависят от фактически активных ядер и составляют 8 МиБ на каждое логическое ядро, то есть на произведение числа сокетов, ядер в сокете и потоков на ядро.

Настройка типа ОС и загрузчика

Параметр osType определяет тип операционной системы и применяет оптимальный набор виртуальных устройств и параметров для корректной работы виртуальной машины (ВМ).

Поддерживаемые значения:

• Generic (по умолчанию) — для Linux и других операционных систем. Используется стандартная конфигурация виртуальных устройств.
• Windows — для операционных систем семейства Microsoft Windows. Автоматически включает функции Hyper-V, TPM-устройство и другие настройки, оптимизированные для работы Windows.
• Legacy — для операционных систем без встроенных драйверов AHCI и virtio, то есть Windows XP, Windows 2000, Windows Server 2003, систем эпохи DOS и Linux с ядром старше 2.6.19. Такая ВМ получает чипсет i440fx, а с enableParavirtualization: false — ещё и шину IDE для дисков и CD-ROM и сетевой адаптер RTL8139, драйверы которых есть в этих операционных системах.

Набор виртуальных устройств, которые видит гостевая ОС:

Проброс USB-устройств для Legacy работает, но контроллер UHCI ограничен скоростью USB 1.1 в 12 Мбит/с, поэтому быстрый накопитель в такой ВМ упрётся в шину.

Выбирайте Legacy, когда гостевая операционная система не умеет работать с контроллером AHCI, а не просто потому, что она старая. Для Linux с ядром 2.6.19 и новее подходит osType: Generic с enableParavirtualization: false — там нет ограничения в четыре устройства и диски можно подключать на ходу через VirtualMachineBlockDeviceAttachment.

Для Legacy недоступны:

• изменение числа ядер процессора и объёма памяти на работающей ВМ, потому что эти гостевые ОС не вводят их в работу. Изменение принимается, ВМ показывает его в .status.restartAwaitingChanges вместе с условием AwaitingRestartToApplyConfiguration, а применяется оно после перезапуска;
• изменение состава .spec.blockDeviceRefs у работающей ВМ, потому что в обоих режимах паравиртуализации эти диски остаются статическими, поэтому блочное устройство добавляйте до запуска ВМ;
• загрузчики EFI и EFIWithSecureBoot, а также начальная инициализация (cloud-init и Sysprep), потому что эти гостевые ОС их не поддерживают;
• сведения о гостевой ОС в статусе ВМ и информация о файловых системах.

Гостевой агент QEMU в такую ОС поставить можно, из архивного выпуска virtio-win, и ВМ действительно покажет AgentReady, но его версия слишком старая для DP. У ВМ появляется условие AgentVersionNotSupported, сведения о гостевой ОС не собираются, а обновить агента не на что.

Снимок с requiredConsistency: true тоже не завершится успешно, но по другой причине. DP запрашивает заморозку файловой системы, а агент отвечает, что команда в его сборке отключена, сообщением guest-fsfreeze-status has been disabled for this instance. На Windows заморозка идёт через провайдер VSS, которого в этой сборке нет. Снимок около десяти минут ждёт в фазе InProgress и переходит в Failed, поэтому для таких ВМ задавайте requiredConsistency: false.

С enableParavirtualization: false добавляется ещё одно ограничение. Блочных устройств может быть не более четырёх суммарно, потому что шина IDE предоставляет два канала по два устройства.

Пример конфигурации для виртуальной машины с Windows XP:

spec:
  osType: Legacy
  bootloader: BIOS
  enableParavirtualization: false
  # остальные параметры...

Параметр bootloader определяет тип загрузчика виртуальной машины:

• BIOS (по умолчанию) — использование устаревшего BIOS;
• EFI — использование Unified Extensible Firmware Interface (UEFI/EFI);
  • EFIWithSecureBoot — использование UEFI/EFI с поддержкой Secure Boot.

Пример конфигурации для виртуальной машины с Windows:

spec:
  osType: Windows
  bootloader: EFI
  # остальные параметры...

Пример конфигурации для виртуальной машины с Linux (значения по умолчанию можно не указывать):

spec:
  osType: Generic
  bootloader: BIOS
  # остальные параметры...

Параметр enableParavirtualization управляет использованием шины virtio для подключения виртуальных устройств ВМ. Изменение значения параметра учитывается только после перезагрузки ВМ.

• true (по умолчанию) — используется шина virtio для дисков, сетевых интерфейсов и других устройств, что обеспечивает лучшую производительность. Состав .spec.blockDeviceRefs у работающей ВМ можно менять без перезагрузки — добавляя и удаляя устройства, если диск доступен на узле, где выполняется ВМ.
• false — используется эмуляция стандартных устройств (SATA для дисков, e1000 для сетевых интерфейсов; IDE и RTL8139 для типа ОС Legacy), что может быть необходимо для совместимости со старыми ОС без драйверов VirtIO. Изменения в .spec.blockDeviceRefs на работающей ВМ (добавление и удаление дисков и образов, в том числе ISO) вступают в силу после перезагрузки ВМ. Подключать и отключать диски без перезагрузки можно через ресурс VirtualMachineBlockDeviceAttachment (vmbda), не меняя список в спецификации ВМ.

Для типа ОС Legacy значение по умолчанию true не подходит, потому что встроенных драйверов virtio у этих операционных систем нет, поэтому для ВМ, которую предстоит установить с оригинального носителя, укажите enableParavirtualization: false — иначе установщик сообщит, что не нашёл жёстких дисков. При создании и изменении такой ВМ выдаётся предупреждение.

Оставляйте enableParavirtualization: true для ВМ с типом ОС Legacy только тогда, когда драйверы virtio уже установлены в гостевой ОС. Тогда ВМ сохраняет чипсет i440fx и загрузчик BIOS, но получает диски на virtio-blk, адаптер virtio-net и лишается ограничения в четыре устройства. CD-ROM остаётся на шине IDE, потому что у virtio-blk привода нет.

Переключить уже установленную систему можно так:

1. Установите драйверы virtio в гостевой ОС. Для Windows XP, 2000 и Server 2003 возьмите архивный выпуск virtio-win, потому что в текущих выпусках драйверов для этих систем уже нет, и установите viostor, драйвер virtio-blk. Драйвера virtio-scsi для этих ОС в пакете нет.
2. Выключите ВМ.
3. Задайте enableParavirtualization: true.
4. Запустите ВМ.

Порядок шагов важен. Драйвер дискового контроллера должен появиться в гостевой ОС до переключения, а не после, ведь именно с этого контроллера ВМ загружается. Если после переключения ВМ не загрузилась, верните enableParavirtualization: false и перезапустите её. Диски вернутся на шину IDE, и гостевая ОС загрузится как прежде.

Пример конфигурации с отключенной паравиртуализацией:

spec:
  enableParavirtualization: false
  # остальные параметры...

Сценарии начальной инициализации ВМ

Сценарии начальной инициализации предназначены для первичной конфигурации виртуальной машины при её запуске.

В качестве сценариев начальной инициализации поддерживаются:

• Cloud-Init.
• Sysprep.

Cloud-Init

Cloud-Init — это инструмент для автоматической настройки виртуальных машин при первом запуске. Он позволяет выполнять широкий спектр задач конфигурации без ручного вмешательства.

Основные возможности Cloud-Init:

• создание пользователей, установка паролей, добавление SSH-ключей для доступа;
• автоматическая установка необходимого программного обеспечения при первом запуске;
• запуск произвольных команд и скриптов для настройки системы;
• автоматический запуск и включение системных сервисов (например, qemu-guest-agent).

Ниже приведены типичные сценарии.

1. Добавление SSH-ключа для предустановленного пользователя, который уже может присутствовать в cloud-образе (например, пользователь ubuntu в официальных образах Ubuntu). Имя такого пользователя зависит от образа. Уточните его в документации к вашему дистрибутиву.

   #cloud-config
   ssh_authorized_keys:
     - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD... your-public-key ...

2. Создание пользователя с паролем и SSH-ключом:

   #cloud-config
   users:
     - name: cloud
       passwd: <PASSWORD_HASH>
       lock_passwd: false
       sudo: ALL=(ALL) NOPASSWD:ALL
       shell: /bin/bash
       ssh-authorized-keys:
         - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD... your-public-key ...
   ssh_pwauth: True

   Здесь <PASSWORD_HASH> — хеш пароля в кавычках, полученный командой mkpasswd --method=SHA-512 --rounds=4096.

3. Установка пакетов и сервисов:

   #cloud-config
   package_update: true
   packages:
     - nginx
     - qemu-guest-agent
   runcmd:
     - systemctl daemon-reload
     - systemctl enable --now nginx.service
     - systemctl enable --now qemu-guest-agent.service

Ниже показано, как передать сценарий виртуальной машине:

spec:
  provisioning:
    type: UserData
    userData: |
      #cloud-config
      package_update: true
      ...

apiVersion: v1
kind: Secret
metadata:
  name: cloud-init-example
data:
  userData: <base64 data>
type: provisioning.virtualization.deckhouse.io/cloud-init

spec:
  provisioning:
    type: UserDataRef
    userDataRef:
      kind: Secret
      name: cloud-init-example

Sysprep

Для конфигурирования виртуальных машин под управлением ОС Windows с использованием Sysprep поддерживается только вариант с ресурсом Secret.

Пример ресурса Secret со сценарием Sysprep:

apiVersion: v1
kind: Secret
metadata:
  name: sysprep-example
data:
  unattend.xml: <base64 data>
type: provisioning.virtualization.deckhouse.io/sysprep

Фрагмент конфигурации виртуальной машины с использованием скрипта начальной инициализации Sysprep в ресурсе Secret:

spec:
  provisioning:
    type: SysprepRef
    sysprepRef:
      kind: Secret
      name: sysprep-example

Агент гостевой ОС

Установите в гостевую систему QEMU Guest Agent, чтобы DP мог взаимодействовать с операционной системой внутри ВМ. Агент нужен для трёх вещей:

• он позволяет создавать консистентные снимки дисков и ВМ;
• он сообщает сведения о работающей системе, и они попадают в блок .status.guestOSInfo;
• по нему видно, что операционная система действительно загрузилась, а не просто запустилась виртуальная машина.

DP работает с qemu-guest-agent версии 5.2.0 и выше. Проверить установленную версию можно командой:

qemu-guest-agent --version

Сведения о гостевой системе выглядят так:

status:
  guestOSInfo:
    id: fedora
    kernelRelease: 6.11.4-301.fc41.x86_64
    kernelVersion: "#1 SMP PREEMPT_DYNAMIC Sun Oct 20 15:02:33 UTC 2024"
    machine: x86_64
    name: Fedora Linux
    prettyName: Fedora Linux 41 (Cloud Edition)
    version: 41 (Cloud Edition)
    versionId: "41"

Работает ли агент, показывает колонка AGENT:

d8 k get vm -o wide

Пример вывода:

NAME     PHASE     UPTIME   CORES   COREFRACTION   MEMORY   NEED RESTART   AGENT   MIGRATABLE   NODE           IPADDRESS    AGE
fedora   Running   5d21h    6       5%             8000Mi   False          True    True         virtlab-pt-1   10.66.10.1   5d21h

Установите агента командой для вашего дистрибутива и запустите службу:

# Debian и производные.
sudo apt install qemu-guest-agent

# CentOS и производные.
sudo yum install qemu-guest-agent

sudo systemctl enable --now qemu-guest-agent

Для Linux установку удобно автоматизировать сценарием начальной инициализации:

#cloud-config
package_update: true
packages:
  - qemu-guest-agent
runcmd:
  - systemctl enable --now qemu-guest-agent.service

Настраивать агента после установки не требуется. Если снимкам нужна согласованность данных приложения, положите скрипты подготовки в каталог /etc/qemu-ga/hooks.d/ на Debian и Ubuntu либо /etc/qemu/fsfreeze-hook.d/ на RHEL, CentOS и Fedora. Скрипты должны быть исполняемыми, агент запускает их до заморозки файловой системы и после её разморозки, поэтому сервисы приложения останавливать не приходится.

Подключение к виртуальной машине

К виртуальной машине (ВМ) можно подключиться четырьмя способами. Первый — по протоколу удалённого управления вроде SSH, который вы настраиваете в гостевой ОС сами. Второй — через серийную консоль. Третий — по VNC. Четвёртый — по SPICE, если он включён у машины.

d8 v console linux-vm

Successfully connected to linux-vm console. The escape sequence is ^]
linux-vm login: cloud
Password: cloud

d8 v vnc linux-vm

d8 v spice linux-vm

d8 v ssh cloud@linux-vm

Серийная консоль и VNC эксклюзивны, в них работает только один пользователь, и новое подключение отключает того, кто уже работает с машиной.

Перед подключением d8 v console и d8 v vnc сообщают, кто занял поток и с какого времени, и предлагают выбор:

The serial console of linux-vm is in use:
  user       serviceaccount default/alice
  connected  12 minutes ago (14:32), from the d8 v command line

Connect and disconnect them? [y] yes  [N] no  [w] wait until free:

Ответ w означает дождаться, пока другой пользователь отключится, и подключиться автоматически. Нажатие Enter отменяет подключение, потому что по умолчанию выбран безопасный вариант. Флаг --force подключает без вопроса, и он же нужен при неинтерактивном запуске в скрипте.

SPICE

SPICE — второй протокол удалённого дисплея, который в отличие от VNC передаёт из гостевой системы звук, пробрасывает в неё USB-устройства с вашего компьютера и разделяет с ней буфер обмена. Он работает рядом с VNC, поэтому уже открытые VNC-сессии и веб-интерфейс продолжают работать.

По умолчанию SPICE выключен. Чтобы включить его, задайте параметр .spec.spice.enabled и перезапустите машину:

spec:
  spice:
    enabled: true

Вместе со SPICE машина получает видеоадаптер virtio-gpu. Если драйвера для него в гостевой системе нет, как в Windows 7 и Windows XP, задайте другую модель адаптера аннотацией virtualization.deckhouse.io/video со значением vga, bochs или ramfb.

Общий буфер обмена, подстройку разрешения под окно клиента и локальный курсор добавляет гостевой агент SPICE. Установите его в гостевой системе, в Linux это пакет spice-vdagent, в Windows — spice-guest-tools.

Для подключения нужен клиент remote-viewer из пакета virt-viewer, и команда d8 v spice открывает его сама. Если такого клиента нет, запустите только прокси и подключитесь своим клиентом на порт, который выведет команда:

d8 v spice linux-vm --proxy-only

Политика запуска и управление состоянием ВМ

Политика запуска определяет, как DP поддерживает состояние машины. Её задаёт параметр .spec.runPolicy:

• AlwaysOnUnlessStoppedManually — вариант по умолчанию. Машина всегда работает, а остановить её можно только вручную;
• AlwaysOn — машина всегда работает, и даже после выключения из гостевой ОС DP запускает её снова;
• Manual — состоянием машины вы управляете сами;
• AlwaysOff — машина всегда выключена, и запустить её нельзя.

Управлять состоянием машины можно двумя способами, создавая ресурс VirtualMachineOperation или пользуясь утилитой d8. Ресурс описывает действие декларативно, а утилита создаёт такой же ресурс за вас.

Ниже показано, как выполнить операцию над виртуальной машиной:

d8 v restart linux-vm

d8 k create -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineOperation
metadata:
  generateName: restart-linux-vm-
spec:
  virtualMachineName: linux-vm
  # Тип выполняемой операции.
  type: Restart
EOF

d8 k get virtualmachineoperation

# Короткий вариант команды.
d8 k get vmop

Для одной машины одновременно выполняется только одна операция. Новая операция либо вытесняет активную, либо завершается неудачей, и какой из вариантов сработает, зависит от пары типов:

Вытесненная операция переходит в фазу Superseded. Операция, которая вытеснить активную не может, переходит в фазу Failed, поэтому её нужно создать заново после того, как активная завершится. Восстановление и клонирование другие операции не вытесняют.

Изменение конфигурации ВМ

Конфигурацию виртуальной машины (ВМ) можно менять в любой момент после создания. У выключенной машины изменения применяются сразу, у работающей — по-разному, в зависимости от того, что именно вы изменили.

Ниже показано, как изменить конфигурацию виртуальной машины:

spec:
  disruptions:
    restartApprovalMode: Automatic

Изменение числа ядер без перезапуска

Число ядер работающей машины можно менять, не перезагружая её, если изменение применимо через живую миграцию. В пределах текущей топологии CPU ядра можно и добавлять, и убирать.

Возможность выключена по умолчанию. Чтобы её включить, администратор добавляет HotplugCPUWithLiveMigration в параметр .spec.settings.featureGates:

kind: ModuleConfig
metadata:
  name: virtualization
spec:
  settings:
    featureGates:
      - HotplugCPUWithLiveMigration

В веб-интерфейсе тот же переключатель называется «Изменение CPU без перезагрузки» и находится в блоке «Экспериментальные возможности» на вкладке «Система» → «Deckhouse» → «Модули» → virtualization → «Конфигурация». Права на это есть только у администратора DP.

Когда возможность включена, а новое значение .spec.cpu.cores остаётся в пределах текущей топологии, DP применяет изменение живой миграцией. Если изменение требует смены топологии, машину придётся перезагрузить. Правила расчёта топологии описаны в разделе «Топологии CPU».

d8 k patch vm linux-vm --type merge -p '{"spec":{"cpu":{"cores":4}}}'

Гостевая ОС не всегда вводит новые ядра в работу сама, особенно после живой миграции. В Linux ядро включается через sysfs:

echo 1 > /sys/devices/system/cpu/cpu1/online

Чтобы это происходило автоматически, добавьте правило udev:

cat <<'EOF' > /etc/udev/rules.d/99-hotplug-cpu.rules
SUBSYSTEM=="cpu",ACTION=="add",RUN+="/bin/sh -c '[ ! -e /sys$devpath/online ] || echo 1 > /sys$devpath/online'"
EOF

Введённые в работу ядра появляются в выводе nproc, cat /proc/cpuinfo и top.

При уменьшении числа ядер в пределах текущей топологии распределение ядер по сокетам сохраняется.

Изменение объёма памяти без перезапуска

Объём памяти работающей машины можно увеличивать, не перезагружая её. Уменьшение требует перезапуска.

Возможность выключена по умолчанию. Чтобы её включить, администратор добавляет HotplugMemoryWithLiveMigration в параметр .spec.settings.featureGates:

kind: ModuleConfig
metadata:
  name: virtualization
spec:
  settings:
    featureGates:
      - HotplugMemoryWithLiveMigration

В веб-интерфейсе переключатель называется «Изменение памяти без перезагрузки» и лежит там же, в блоке «Экспериментальные возможности» настроек модуля.

Когда возможность включена, новое значение .spec.memory.size больше текущего и машина допускает миграцию, DP применяет изменение живой миграцией. Перезапуск понадобится, если память уменьшают, если исходный размер меньше 1 ГиБ или если машину нельзя мигрировать. Без перезапуска память растёт до 256 ГиБ, это предел, заложенный в конфигурацию машины при первом запуске.

d8 k patch vm linux-vm --type merge -p '{"spec":{"memory":{"size":"4Gi"}}}'

Как и с ядрами, гостевая ОС может не ввести новые блоки памяти в работу сама. В Linux блок включается через sysfs, а имя устройства видно в выводе lsmem или в каталоге /sys/bus/memory/devices/:

echo 1 > /sys/bus/memory/devices/memoryXXX/online

Чтобы это происходило автоматически, добавьте правило udev:

cat <<'EOF' > /etc/udev/rules.d/99-hotplug-memory.rules
SUBSYSTEM=="memory",ACTION=="add",DEVPATH=="/devices/system/memory/memory[0-9]*", TEST=="state", ATTR{state}!="online", ATTR{state}="online"
EOF

Размещение ВМ по узлам

Тем, где именно запускается виртуальная машина (ВМ), управляют четыре механизма:

• .spec.nodeSelector — самый простой способ, выбирает узлы с нужными лейблами;
• .spec.affinity.nodeAffinity — задаёт приоритетные узлы для размещения;
• .spec.affinity.virtualMachineAndPodAffinity — размещает машину рядом с другими машинами и рабочими нагрузками;
• .spec.affinity.virtualMachineAndPodAntiAffinity — наоборот, разводит их по разным узлам.

Условия бывают жёсткими и мягкими. Жёсткое условие requiredDuringSchedulingIgnoredDuringExecution обязательно к исполнению, и машина не запустится, если подходящего узла нет. Мягкое условие preferredDuringSchedulingIgnoredDuringExecution планировщик учитывает по возможности.

Все правила, включая .spec.nodeSelector из класса ВМ, применяются вместе. Если хотя бы одно жёсткое условие выполнить нельзя, машина остаётся в фазе Pending. Поэтому задавайте непротиворечивые правила, предпочитайте комбинации лейблов одиночным жёстким ограничениям и держите в запасе узлы для критичных нагрузок. Учитывайте и порядок запуска. Если одна машина обязана оказаться рядом с другой, сначала должна запуститься вторая. Если на нужных узлах стоят ограничения taints, добавьте машине соответствующие tolerations.

Как задать правила размещения в веб-интерфейсе:

1. Перейдите на вкладку «Проекты» и выберите нужный проект.
2. Перейдите в раздел «Виртуализация» → «Виртуальные машины».
3. Из списка выберите нужную ВМ и нажмите на её имя.
4. На вкладке «Конфигурация» прокрутите страницу до переключателя «Размещение ВМ».
5. Выберите режим заполнения. В режиме «Базовая настройка» правила задаются переключателями «Совместное размещение» и «Раздельное размещение», в режиме «Редактирование» блок размещения задаётся вручную в виде YAML.
6. Включите нужный переключатель и заполните поля. В поле «Выберите режим правила» доступны «Принудительное» (requiredDuringSchedulingIgnoredDuringExecution) и «Предпочтительное» (preferredDuringSchedulingIgnoredDuringExecution), а в поле «Правило размещения» — размещение относительно других ВМ или относительно лейблов узлов.
7. Нажмите появившуюся кнопку «Сохранить».

Толерантность к ограничениям узлов

Tolerations позволяют ВМ запускаться на узлах с ограничениями (taints), которые иначе блокируют планирование (scheduling). Это полезно, когда нужно запускать ВМ на специальных узлах (например, тестовых) или узлах с определёнными характеристиками.

Пример использования tolerations для разрешения запуска на узлах с taint node.deckhouse.io/group=:NoSchedule:

spec:
  tolerations:
    - key: "node.deckhouse.io/group"
      operator: "Exists"
      effect: "NoSchedule"

Каждый элемент списка tolerations должен соответствовать taint на узле, чтобы ВМ могла быть размещена на этом узле.

Чтобы посмотреть taints на узлах кластера, выполните команду:

d8 k get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

Чтобы посмотреть подробную информацию об узле, выполните команду:

d8 k describe node <NODE_NAME>

Простое связывание по меткам (nodeSelector)

nodeSelector — это простейший способ контролировать размещение виртуальных машин, используя набор меток. Он позволяет задать, на каких узлах могут запускаться виртуальные машины, выбирая узлы с необходимыми метками.

spec:
  nodeSelector:
    disktype: ssd

В этом примере в кластере три узла, два из них с быстрыми дисками (disktype=ssd) и один с медленными (disktype=hdd). Виртуальная машина будет размещена только на узлах, которые имеют метку disktype со значением ssd.

Как выполнить операцию в веб-интерфейсе в разделе «Размещение»:

1. Включите переключатель «Совместное размещение».
2. В поле «Выберите режим правила» выберите «Принудительное».
3. В поле «Правило размещения» выберите «На выбранных узлах».
4. В поле «Как определить группу узлов» выберите «По лейблам» и укажите лейблы узлов (например, disktype: ssd); вариант «По имени» позволяет выбрать конкретные узлы.
5. Нажмите появившуюся кнопку «Сохранить».

Предпочтительное связывание (Affinity)

Affinity предоставляет более гибкие и мощные инструменты по сравнению с nodeSelector. Он позволяет задавать «предпочтения» и «обязательности» для размещения виртуальных машин. Affinity поддерживает два вида, nodeAffinity и virtualMachineAndPodAffinity.

nodeAffinity — определяет узлы для запуска ВМ с помощью выражений селекторов меток.

Пример использования nodeAffinity с жестким правилом:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd

В этом примере в кластере три узла, два из них с быстрыми дисками (disktype=ssd) и один с медленными (disktype=hdd). Виртуальная машина будет размещена только на узлах, которые имеют метку disktype со значением ssd.

Если использовать мягкое требование (preferredDuringSchedulingIgnoredDuringExecution), то при отсутствии ресурсов для запуска ВМ на узлах с дисками disktype=ssd она будет запланирована на узле с дисками disktype=hdd.

virtualMachineAndPodAffinity управляет размещением виртуальных машин относительно других виртуальных машин. Он позволяет задавать предпочтение размещения виртуальных машин на тех же узлах, где уже запущены определенные виртуальные машины.

Пример мягкого правила:

spec:
  affinity:
    virtualMachineAndPodAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          podAffinityTerm:
            labelSelector:
              matchLabels:
                server: database
            topologyKey: "kubernetes.io/hostname"

В этом примере виртуальная машина размещается только на узлах, где уже работает виртуальная машина с лейблом server: database. Правило мягкое (preferred), поэтому при отсутствии таких узлов машина запустится на любом подходящем.

Чтобы размещать ВМ по зонам доступности (а не привязывать к конкретным узлам), задайте topologyKey: topology.kubernetes.io/zone (раздел «Размещение ВМ по зонам доступности»).

Как задавать «предпочтения» и «обязательности» для размещения виртуальных машин в веб-интерфейсе в разделе «Размещение»:

1. Включите переключатель «Совместное размещение» — он соответствует настройкам spec.affinity.virtualMachineAndPodAffinity.
2. В поле «Выберите режим правила» выберите «Принудительное» или «Предпочтительное».
3. В поле «Правило размещения» выберите «На узлах с выбранными ВМ».
4. В поле «Выберите лейблы» выберите лейблы нужных ВМ из списка или введите свой в формате key: value.
5. Нажмите появившуюся кнопку «Сохранить».

Избежание совместного размещения (AntiAffinity)

AntiAffinity используется для предотвращения совместного размещения ВМ на узлах. Полезно для обеспечения отказоустойчивости или балансировки нагрузки.

Термины Affinity и AntiAffinity описывают отношения между виртуальными машинами. Для узлов такого антонима нет, но того же результата можно добиться через nodeAffinity с оператором NotIn, исключив нужные узлы.

Пример использования virtualMachineAndPodAntiAffinity:

spec:
  affinity:
    virtualMachineAndPodAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              server: database
          topologyKey: "kubernetes.io/hostname"

В данном примере создаваемая виртуальная машина не будет размещена на одном узле с виртуальной машиной с меткой server: database.

Чтобы размещать ВМ по зонам доступности (а не привязывать к конкретным узлам), задайте topologyKey: topology.kubernetes.io/zone (раздел «Размещение ВМ по зонам доступности»).

Как настроить предотвращение совместного размещения ВМ на узлах в веб-интерфейсе в разделе «Размещение»:

1. Включите переключатель «Раздельное размещение» — он соответствует настройкам spec.affinity.virtualMachineAndPodAntiAffinity.
2. В поле «Выберите режим правила» выберите «Принудительное» или «Предпочтительное».
3. В поле «Правило размещения» выберите «На узлах с выбранными ВМ».
4. В поле «Выберите лейблы» выберите лейблы ВМ, рядом с которыми размещать машину не нужно, или введите свой лейбл в формате key: value.
5. Нажмите появившуюся кнопку «Сохранить».

Размещение ВМ по зонам доступности

Правила размещения работают не только на уровне узлов, но и на уровне зон доступности.

В примерах выше используется topologyKey: "kubernetes.io/hostname", что размещает ВМ на одном узле. Для размещения ВМ по зонам доступности вместо узлов используйте topologyKey: "topology.kubernetes.io/zone".

При использовании Affinity с topologyKey: "topology.kubernetes.io/zone" ВМ будут размещаться в той же зоне доступности, где присутствует виртуальная машина с указанными метками.

При использовании AntiAffinity с topologyKey: "topology.kubernetes.io/zone" ВМ не будут размещаться в той же зоне доступности, что и виртуальная машина с указанными метками. Это полезно для обеспечения отказоустойчивости при распределении ВМ по разным зонам доступности.

Чтобы посмотреть зоны доступности на узлах кластера (если эти зоны заданы), выполните команду:

d8 k get nodes -o custom-columns=NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone

Подключение блочных устройств (диски и образы)

К виртуальной машине (ВМ) можно подключать диски и образы. Они описываются как блочные устройства (BlockDevices).

Типы блочных устройств и режимы доступа:

Подключение устройств возможно двумя способами:

• через спецификацию ВМ (.spec.blockDeviceRefs) — диски указываются в конфигурации VirtualMachine и для них задаётся порядок загрузки (по позиции в списке или через поле bootOrder). Рекомендуется при настройке ВМ вручную, а также когда нужен контроль порядка загрузки (например, ISO для установки ОС).
• через VirtualMachineBlockDeviceAttachment (vmbda) — диск подключается отдельным ресурсом и не участвует в порядке загрузки. Диски подключаются через шину virtio-scsi, независимо от значения enableParavirtualization. Рекомендуется для автоматизации и когда нет прав на редактирование ВМ.

При enableParavirtualization: true оба способа позволяют подключать и отключать диски у работающей ВМ без перезагрузки, если диск доступен на узле, где она выполняется. При enableParavirtualization: false состав .spec.blockDeviceRefs у запущенной ВМ меняется только после перезагрузки; без перезагрузки диски можно подключать и отключать через VirtualMachineBlockDeviceAttachment (vmbda).

Подключить диск к работающей ВМ можно только тогда, когда хранилище доступно на том узле кластера, где выполняется виртуальная машина. При создании и обновлении ВМ, а также при создании VirtualMachineBlockDeviceAttachment, учитываются правила размещения (nodeSelector, affinity, tolerations) тома, виртуальной машины и класса ВМ, и хотя бы одно общее допустимое размещение у них должно найтись. Если ВМ уже запущена и работает на конкретном узле, новый диск должен быть доступен на этом узле.

Пока живая миграция машины готовит целевой узел, диск нельзя ни подключить, ни отключить. Новый ресурс VirtualMachineBlockDeviceAttachment остаётся в фазе Pending с причиной BlockedByMigration в условии Attached, а удаляемый остаётся в фазе Terminating, и оба доводятся до конца после миграции. Пока миграция стоит в очереди и целевой узел ещё не готовится, подключение и отключение работают как обычно.

Подключение через спецификацию ВМ

Устройства, перечисленные в спецификации машины, подключаются при её запуске и остаются на месте всё время работы. Их список задаёт поле .spec.blockDeviceRefs ресурса VirtualMachine.

Порядок загрузки по умолчанию совпадает с порядком устройств в списке, а задать его явно позволяет необязательное поле bootOrder (меньшее значение — выше приоритет). Если bootOrder указан хотя бы у одного устройства, в цепочку загрузки попадают только устройства с заданным bootOrder. Допустимы целые числа от 1 и выше, уникальные в пределах списка. При удалении устройства из списка порядок загрузки пересчитывается для оставшихся устройств.

Изменение порядка устройств в списке или значений bootOrder вступает в силу после перезагрузки ВМ. Например, можно подключить ISO-образ для установки ОС с нужным приоритетом загрузки, а после установки удалить его из списка. Если у ВМ отключена паравиртуализация (enableParavirtualization: false), правки в .spec.blockDeviceRefs у работающей ВМ, в том числе с ISO-образом, применяются после перезагрузки ВМ.

spec:
  blockDeviceRefs:
    - kind: VirtualDisk
      name: <VD_NAME>
      bootOrder: 1
    - kind: VirtualImage
      name: <VI_NAME>
      bootOrder: 2

spec:
  blockDeviceRefs:
    - kind: VirtualDisk
      name: <VD_NAME>
    - kind: VirtualImage
      name: <VI_NAME>
    - kind: VirtualDisk
      name: <ADDITIONAL_DISK_NAME>

Подключение через VirtualMachineBlockDeviceAttachment

Ресурс VirtualMachineBlockDeviceAttachment подключает и отключает блочное устройство у ВМ, не затрагивая её спецификацию. Он подходит для автоматизации и для случаев, когда у пользователя нет прав на редактирование машины.

Устройство подключено, когда ресурс переходит в фазу Attached. Остальные фазы описаны в поле .status.phase, а причину задержки показывает блок .status.conditions.

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineBlockDeviceAttachment
metadata:
  name: attach-blank-disk
spec:
  blockDeviceRef:
    kind: VirtualDisk
    name: blank-disk
  virtualMachineName: linux-vm
EOF

d8 k get vmbda attach-blank-disk

NAME                PHASE      VIRTUALMACHINE   AGE
attach-blank-disk   Attached   linux-vm         3m7s

d8 v ssh cloud@linux-vm --command "lsblk"

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda       8:0    0   10G  0 disk <--- статично подключенный диск linux-vm-root
|-sda1    8:1    0  9.9G  0 part /
|-sda14   8:14   0    4M  0 part
`-sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0    1M  0 disk <--- cloudinit
sdc       8:32   0 95.9M  0 disk <--- динамически подключенный диск blank-disk

d8 k delete vmbda attach-blank-disk

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineBlockDeviceAttachment
metadata:
  name: attach-ubuntu-iso
spec:
  blockDeviceRef:
    kind: VirtualImage # или ClusterVirtualImage
    name: ubuntu-iso
  virtualMachineName: linux-vm
EOF

Именование дисков в гостевой ОС

Имена дисков в гостевой системе не постоянны, поэтому опираться на них в настройках опасно.

Пример:

После первой загрузки ВМ:

$ lsscsi
[0:0:0:1]  disk    QEMU     QEMU HARDDISK   /dev/sda
[0:0:0:2]  disk    QEMU     QEMU HARDDISK   /dev/sdb

После перезагрузки ВМ:

$ lsscsi
[0:0:0:1]  disk    QEMU     QEMU HARDDISK   /dev/sdb
[0:0:0:2]  disk    QEMU     QEMU HARDDISK   /dev/sda

SCSI-адреса (0:0:0:1, 0:0:0:2) остаются неизменными, но имена устройств (/dev/sda, /dev/sdb) меняются местами.

Используйте стабильные идентификаторы вместо /dev/sdX:

• /dev/disk/by-uuid/ — по UUID разделов (предпочтительно для /etc/fstab);
• /dev/disk/by-path/ — по SCSI пути подключения;
• /dev/disk/by-id/ — по SCSI ID устройства.

В конфигурационных файлах и скриптах используйте UUID разделов или символические ссылки из /dev/disk/by-* вместо имён /dev/sdX.

Именование сетевых интерфейсов в гостевой ОС

В системах без поддержки предсказуемого именования интерфейсов (predictable network interface naming) имена сетевых интерфейсов (eth0, eth1, eth2 и так далее) присваиваются ядром Linux в порядке обнаружения устройств при загрузке. При добавлении новых сетевых интерфейсов или изменении порядка сетей в .spec.networks порядок интерфейсов может измениться, из-за чего IP-адреса могут быть назначены не тем интерфейсам.

Использование ethX в конфигурационных файлах (например, /etc/network/interfaces, netplan, systemd-networkd) или в скриптах при добавлении новых интерфейсов или изменении порядка сетей может привести к сбоям в работе сети или подключению к неверной сети.

В современных дистрибутивах с systemd (Ubuntu 16.04+, Debian 9+, CentOS 7+, RHEL 7+) по умолчанию используются предсказуемые имена интерфейсов (enpXsY, ensX, enoX), которые основаны на физических характеристиках устройства (PCI координаты) и остаются стабильными между перезагрузками и при добавлении новых интерфейсов.

Но даже с предсказуемыми именами привязывайте конфигурацию сети к MAC-адресам интерфейсов, особенно если порядок сетей меняется в .spec.networks или добавлении новых интерфейсов.

Пример для систем без предсказуемого именования:

Изначально ВМ имеет два интерфейса:

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

После добавления нового интерфейса в начало списка .spec.networks и перезагрузки ВМ:

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500  # Новый интерфейс
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500  # Старый eth0
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500  # Старый eth1

MAC-адреса остаются неизменными, но имена интерфейсов (eth0, eth1) сдвигаются, что может привести к назначению IP-адресов не тем интерфейсам.

Используйте стабильные идентификаторы вместо ethX:

• enpXsY — предсказуемые имена на основе физического расположения (systemd networkd naming scheme, включены по умолчанию в современных системах);
• привязка по MAC-адресу — в конфигурации netplan, systemd-networkd или /etc/network/interfaces (предпочтительно для гарантированной стабильности).

В конфигурационных файлах и скриптах используйте стабильные имена интерфейсов (enpXsY) или привязку по MAC-адресу вместо имён ethX.

Чтобы открыть приложение машины другим машинам или пользователям снаружи кластера, настройте сервис или Ingress, как описано в разделе «Доступ к приложениям на виртуальной машине».

Живая миграция ВМ

Живая миграция виртуальных машин (ВМ) — это процесс перемещения работающей ВМ с одного физического узла на другой без её отключения. Эта функция играет ключевую роль в управлении виртуализованной инфраструктурой, обеспечивая непрерывность работы приложений во время технического обслуживания, балансировки нагрузки или обновлений.

Принцип работы живой миграции

Процесс живой миграции состоит из нескольких этапов:

1. На целевом узле создаётся новая ВМ в приостановленном состоянии. Её конфигурация (процессор, диски, сеть) копируется с исходного узла.

2. Вся оперативная память ВМ копируется на целевой узел по сети. Это называется первичной передачей.

3. Пока память передаётся, ВМ продолжает работать на исходном узле и может изменять некоторые страницы памяти. Такие страницы называются «грязными» (dirty pages), и гипервизор их помечает.

4. После первичной передачи начинается повторная отправка только изменённых страниц. Этот процесс повторяется в несколько циклов:

   • Чем выше нагрузка на ВМ, тем больше «грязных» страниц появляется, и тем дольше длится миграция.
   • При хорошей пропускной способности сети объём несинхронизированных данных постепенно уменьшается.

5. Когда количество «грязных» страниц становится минимальным, ВМ на исходном узле приостанавливается (обычно на 100 миллисекунд):

   • Оставшиеся изменения памяти передаются на целевой узел.
   • Состояние процессора, устройств и открытых соединений синхронизируется.
   • ВМ запускается на новом узле, а исходная копия удаляется.

До момента переключения ВМ на новый узел (шаг 5) ВМ на исходном узле продолжает работать в обычном режиме и предоставлять сервис пользователям.

Требования и ограничения

Живая миграция удаётся не всегда. Ниже перечислено, что должно совпасть на исходном и целевом узлах.

Доступность дисков. Все подключённые к ВМ диски должны быть доступны на целевом узле. У сетевых хранилищ вроде NFS или Ceph это требование выполняется само, потому что диски видны со всех узлов кластера. Локальному хранилищу нужна возможность создать новый локальный том на целевом узле, а если такое хранилище есть только на исходном узле, миграция не выполнится.

Подключение и отключение дисков. Пока миграция готовит целевой узел, диски нельзя ни подключить к машине ресурсом VirtualMachineBlockDeviceAttachment, ни отключить, удалив такой ресурс. Подключаемый ресурс остаётся в фазе Pending с причиной BlockedByMigration в условии Attached, а удаляемый в фазе Terminating, пока миграция не завершится. Пока миграция стоит в очереди и целевой узел ещё не готовится, например когда она ждёт освобождения квоты проекта, подключение и отключение работают как обычно. Верно и обратное, уже отправленный запрос на подключение или отключение миграция дожидается, и всё это время ресурс VirtualMachineOperation остаётся в фазе Pending с причиной WaitingForBlockDeviceAttachment. Если запрос не завершится за 5 минут, операция завершается ошибкой.

Пропускная способность сети. Чем медленнее сеть, тем больше итераций синхронизации памяти проходит миграция и тем дольше простой ВМ на финальном этапе, а в худшем случае миграция не укладывается в таймаут. Ходом миграции управляет политика миграции, а с медленной сетью помогает механизм AutoConverge.

Версии ядра. На всех узлах кластера должна работать одна версия ядра Linux. Различия в версиях приводят к несовместимости интерфейсов, системных вызовов и работы с ресурсами, из-за чего миграция срывается.

Совместимость процессоров. Требования к процессорам задаёт тип CPU в классе виртуальной машины. Тип Host разрешает миграцию только между узлами с похожими процессорами, поэтому она не работает ни между Intel и AMD, ни между разными поколениями CPU, у которых различаются наборы инструкций. Тип HostPassthrough требует на целевом узле точно такой же процессор, как на исходном. Чтобы машина мигрировала между узлами с разными процессорами, задайте в классе тип Discovery, Model или Features.

Время выполнения. У миграции есть таймаут завершения, равный 800 секундам на каждый гибибайт памяти ВМ, а при переносе дисков вместе с ней ещё и на каждый гибибайт диска. Например, машине с 4 ГиБ памяти и диском на 20 ГиБ отводится 800 × (4 + 20) = 19200 секунд, то есть около 5,3 часа. Миграция, не уложившаяся в это время, считается неудачной и отменяется, а происходит это при медленной сети или высокой нагрузке на ВМ.

Проверка готовности ВМ к миграции

Условие type: Migratable в статусе ВМ показывает, можно ли перенести ВМ живой миграцией. Оно учитывает как саму ВМ (диски, проброшенные устройства, тип процессора), так и состояние кластера (есть ли узел, на который её можно перенести). Значение True отвечает на вопрос о возможности переноса, а не о том, поедет ли ВМ в это мгновение, поэтому вместе со значением смотрите причину.

Общая картина по всем ВМ:

d8 k get vm -o wide

Значение в колонке MIGRATABLE показывает результат, причина описывается в условии:

d8 k get vm <VM_NAME> -o json | jq '.status.conditions[] | select(.type=="Migratable")'

Причины, которые встречаются чаще всего:

Перенос дисков вместе с ВМ доступен в коммерческих редакциях DP, поэтому причина VirtualMachineDisksShouldBeMigrating встречается только в них. В DP Open ВМ с дисками в хранилище, доступном с одного узла, получает причину VirtualMachineDisksNotMigratable.

Особенности условия Migratable

Несколько особенностей условия, которые важно учитывать при планировании обслуживания и при чтении статуса:

• Условие Migratable описывает не только ВМ, но и сам кластер. Если с единственного подходящего узла снять нужный лейбл, не изменяя параметры ВМ, условие всё равно станет False. При появлении подходящего узла условие вернётся в значение True.

• При выведении узла из планирования ВМ остаётся способной мигрировать. Кордон, перезагрузка и обслуживание узлов проходят сами, поэтому условие остаётся в значении True, а причина меняется на VirtualMachineWaitingForMigrationTarget. Иначе плановое обслуживание соседнего узла превращало бы изменение процессора и памяти в перезапуск ВМ. В DP Open такие изменения требуют перезагрузки в любом случае.

• Значение True означает способность ВМ мигрировать, а не готовность мигрировать прямо сейчас. Перед миграцией смотрите причину. Значение VirtualMachineMigratable означает, что узел для миграции есть, а VirtualMachineWaitingForMigrationTarget — что подходящего узла на этот момент нет. Метрика d8_virtualization_virtualmachine_migratable несёт тот же ответ в лейбле reason, поэтому дашборд, фильтрующий ВМ только по значению, посчитает ожидающие ВМ вместе с готовыми к миграции.

• Миграция, запущенная с причиной VirtualMachineWaitingForMigrationTarget, не ожидает узел бесконечно. Если целевой под не удаётся запланировать в течение пяти минут, операция завершается ошибкой, а условие Completed ресурса VirtualMachineOperation получает причину TargetUnschedulable. Если обслуживание затянулось, перезапустите миграцию.

• У остановленной ВМ нет условия, так как способность ВМ мигрировать вычисляется только для запущенной ВМ. За время простоя диски могли переехать в другое хранилище, а устройство могло быть отключено.

• В DP Open изменения размещения учитываются после перезапуска ВМ. Пока ВМ работает, она использует параметры, с которыми была запущена, и условие описывает именно их. Новые nodeSelector, affinity или класс ВМ попадут в расчёт только после перезапуска. В коммерческих редакциях DP такие изменения применяются без перезапуска и сразу попадают в расчёт условия.

• Локальные диски не мешают миграции, но узел всё равно нужен. В коммерческих редакциях DP ВМ с локальными дисками переносится вместе с ними, поэтому условие остаётся True с причиной VirtualMachineDisksShouldBeMigrating. Если же ни один узел кластера не подходит под её правила размещения, условие будет False, так как переносить диски вместе с ВМ некуда.

Запуск живой миграции

Миграцию запускает операция Migrate ресурса VirtualMachineOperation, которую можно создать вручную или командой утилиты d8. Прервать миграцию, пока она находится в фазе Pending или InProgress, можно удалением этого ресурса.

d8 k get vm

NAME       PHASE     UPTIME   NODE           IPADDRESS     AGE
linux-vm   Running   79m      virtlab-pt-1   10.66.10.14   79m

d8 v migrate -n <NAMESPACE> <VM_NAME> [--force] [--target-node-name string]

d8 v migrate -n project-1 linux-vm --target-node-name production-1

d8 k create -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineOperation
metadata:
  generateName: migrate-linux-vm-
  namespace: project-1
spec:
  # Имя виртуальной машины.
  virtualMachineName: linux-vm
  # Операция для миграции.
  type: Migrate
  # Определяет операцию миграции виртуальной машины.
  migrate:
    nodeSelector:
      # Кроме того, вы можете установить любой подходящий селектор узлов.
      kubernetes.io/hostname: production-1
  # Разрешить замедление процессора механизмом AutoConverge, для гарантии, что миграция выполнится.
  force: true
EOF

d8 k get vm -w

NAME       PHASE       UPTIME   NODE           IPADDRESS     AGE
linux-vm   Running     79m      virtlab-pt-1   10.66.10.14   79m
linux-vm   Migrating   79m      virtlab-pt-1   10.66.10.14   79m
linux-vm   Migrating   79m      virtlab-pt-1   10.66.10.14   79m
linux-vm   Running     79m      virtlab-pt-2   10.66.10.14   79m

Настройка политики миграции

Политика миграции определяет, когда использовать механизм AutoConverge (замедление процессора) для гарантированного завершения миграции.

Механизм AutoConverge помогает завершить миграцию даже при низкой пропускной способности сети, что позволяет с высокой вероятностью успешно завершить операцию. Однако он замедляет процессор виртуальной машины, что может повлиять на производительность приложений, работающих на виртуальной машине.

Механизм AutoConverge работает в два этапа:

1. Замедление процессора виртуальной машины

   Гипервизор постепенно снижает частоту процессора исходной виртуальной машины. Это уменьшает скорость появления новых «грязных» страниц. Чем выше нагрузка на виртуальную машину, тем сильнее замедление.

2. Автоматическое завершение миграции

   Как только скорость передачи данных превышает скорость изменения памяти, запускается финальная синхронизация, и виртуальная машина переключается на новый узел.

Для настройки политики миграции используйте параметр .spec.liveMigrationPolicy в конфигурации виртуальной машины. Допустимые значения параметра:

• AlwaysSafe — миграция всегда выполняется без замедления процессора (AutoConverge не используется). Подходит для случаев, когда важна максимальная производительность виртуальной машины, но требует высокой пропускной способности сети.
• PreferSafe (используется в качестве политики по умолчанию) — миграция выполняется без замедления процессора (AutoConverge не используется). Однако можно запустить миграцию с замедлением процессора, используя ресурс VirtualMachineOperation с параметрами type=Migrate и force=true.
• AlwaysForced — миграция всегда использует AutoConverge, то есть процессор замедляется при необходимости. Это гарантирует завершение миграции даже при плохой сети, но может снизить производительность виртуальной машины.
• PreferForced — миграция использует AutoConverge, то есть процессор замедляется при необходимости. Однако можно запустить миграцию без замедления процессора, используя ресурс VirtualMachineOperation с параметрами type=Migrate и force=false.

Миграции при недостаточной пропускной способности сети

При живой миграции виртуальной машины может возникнуть ситуация, когда пропускной способности сети недостаточно для передачи данных быстрее, чем они изменяются в памяти виртуальной машины. В этом случае количество «грязных» страниц продолжает расти, и миграция может не завершиться в течение таймаута.

Для решения этой проблемы используется механизм AutoConverge, который настраивается через политику миграции.

Чтобы понять, что пропускной способности сети не хватает для живой миграции виртуальной машины, проверьте графики в разделе «Namespace / Virtual Machine» → «VM Status details» → «Live migration memory metrics»:

• Processed memory rate (скорость передачи памяти) меньше Dirty memory rate (скорость изменения памяти);
• Remaining memory rate (оставшаяся память) долго не уменьшается.

Это означает, что сеть стала узким местом для миграции.

Пример ситуации, когда миграция не может быть завершена из-за недостаточной пропускной способности сети. Внутри виртуальной машины непрерывно меняется память при помощи stress-ng.

Пример выполнения миграции той же виртуальной машины с использованием флага --force команды d8 v migrate (который включает механизм AutoConverge). Здесь хорошо видно, что частота процессора снижается поэтапно, чтобы уменьшить скорость изменения содержимого памяти.

Если сеть ограничивает скорость миграции, можно:

1. Дождаться, когда операция завершится с ошибкой из-за таймаута.

2. Отменить текущую операцию миграции, удалив ресурс VirtualMachineOperation, где <VMOP_NAME> — имя этого ресурса:

   d8 k delete vmop <VMOP_NAME>

3. Повторно запустить миграцию с использованием флага --force, чтобы включить механизм AutoConverge. Использование флага --force должно соответствовать текущей политике миграции виртуальной машины.

Миграции, запускаемые системой

Часть миграций DP запускает сам, создавая ресурс VirtualMachineOperation с типом Evict. Что именно вызвало такую миграцию, видно по префиксу имени ресурса:

Миграция завершилась успешно, когда ресурс переходит в фазу Completed. Остальные фазы описаны в поле .status.phase, а для отмены миграции ресурс удаляют.

Ниже показано, как посмотреть список таких операций:

d8 k get vmop

NAME                    PHASE       PROGRESS   TYPE    VIRTUALMACHINE   AGE
firmware-update-fnbk2   Completed   100%       Evict   linux-vm         1m

Живая миграция ВМ при изменении параметров размещения

Когда правила размещения меняются у работающей машины, DP переносит её на подходящий узел живой миграцией.

Ниже механизм миграции показан на примере кластера с двумя группами узлов, green и blue. Допустим, виртуальная машина изначально запущена на узле группы green, а её конфигурация не содержит ограничений на размещение.

Сначала добавьте в спецификацию ВМ требование размещаться в группе green:

spec:
  nodeSelector:
    node.deckhouse.io/group: green

После сохранения изменений ВМ продолжит работать на текущем узле, так как условие nodeSelector уже выполняется.

Теперь измените требование на группу blue:

spec:
  nodeSelector:
    node.deckhouse.io/group: blue

Текущий узел из группы green новым условиям больше не отвечает. DP создаст ресурс VirtualMachineOperation с типом Evict и запустит живую миграцию ВМ на доступный узел группы blue.

Пример вывода:

NAME                         PHASE       PROGRESS   TYPE    VIRTUALMACHINE   AGE
nodeplacement-update-dabk4   Completed   100%       Evict   linux-vm         1m

Сбор отладочной информации

Если машина ведёт себя не так, как ожидалось, соберите её состояние и состояние связанных ресурсов в один архив.

В архив попадает следующая информация:

• конфигурация виртуальной машины;
• операции над виртуальной машиной;
• информация о миграциях;
• блочные устройства;
• связанные PVC и PV;
• поды, связанные с ВМ, включая их логи (последние 10000 строк);
• события (Events) для всех связанных ресурсов;
• XML-конфигурация домена ВМ.

Собранные данные лежат в архиве в формате YAML (для ресурсов) и в текстовых файлах (для логов). Такой архив можно передать в службу технической поддержки для анализа проблемы.

Ниже показано, как собрать такой архив:

# Сбор отладочной информации для виртуальной машины 'linux-vm'
d8 v collect-debug-info linux-vm > debug-info.tar.gz

# Сбор отладочной информации для ВМ с указанием неймспейса
d8 v collect-debug-info linux-vm -n mynamespace > debug-info.tar.gz

# Сбор отладочной информации для ВМ с указанием полного имени (name.namespace)
d8 v collect-debug-info linux-vm.mynamespace > debug-info.tar.gz

Сеть виртуальных машин

Каждая виртуальная машина (ВМ) получает адрес в основной сети кластера, а при необходимости подключается к дополнительным сетям. В этом разделе описано, как управлять адресами машины, открывать доступ к её приложениям и подключать дополнительные интерфейсы.

IP-адреса ВМ

Адрес машины в основной сети кластера описывают два ресурса, аренда адреса в кластере и закреплённый за проектом адрес.

Блок .spec.settings.virtualMachineCIDRs в настройках модуля задаёт подсети, из которых машины получают IP-адреса. Доступны все адреса подсети, кроме первого и последнего.

Кластерный ресурс VirtualMachineIPAddressLease (vmipl) управляет арендой IP-адресов из общего пула, указанного в virtualMachineCIDRs, а проектный ресурс VirtualMachineIPAddress (vmip) отвечает за резервирование арендованных адресов и их привязку к машинам. Адрес закреплён за машиной, когда ресурс переходит в фазу Attached. Остальные фазы описаны в поле .status.phase.

По умолчанию DP назначает машине адрес сам и держит его закреплённым до удаления машины. Происходит это так:

• Вы создаёте виртуальную машину с именем <VM_NAME>.
• DP создаёт ресурс VirtualMachineIPAddress с именем <VM_NAME>-<HASH>, чтобы запросить IP-адрес и связать его с виртуальной машиной.
• Для этого VirtualMachineIPAddress создаётся ресурс аренды VirtualMachineIPAddressLease, который выбирает случайный IP-адрес из общего пула.
• Как только ресурс VirtualMachineIPAddress создан, виртуальная машина получает назначенный IP-адрес.

После удаления машины ресурс VirtualMachineIPAddress тоже удаляется, но сам адрес какое-то время остаётся закреплённым за проектом, и его можно запросить повторно.

d8 k get vmipl

NAME             VIRTUALMACHINEIPADDRESS                             STATUS   AGE
ip-10-66-10-14   {"name":"linux-vm-7prpx","namespace":"default"}     Bound    12h

d8 k get vmip

NAME             ADDRESS       STATUS     VM         AGE
linux-vm-7prpx   10.66.10.14   Attached   linux-vm   12h

Назначение конкретного IP-адреса

Вместо случайного адреса из пула машине можно выдать адрес, выбранный заранее.

Сохранение IP-адреса за проектом

Чтобы автоматически выданный ip-адрес виртуальной машины не удалился вместе с самой виртуальной машиной выполните следующие действия.

Получите название ресурса VirtualMachineIPAddress для заданной виртуальной машины:

d8 k get vm linux-vm -o jsonpath="{.status.virtualMachineIPAddressName}"

Пример вывода:

linux-vm-7prpx

Удалите блок .metadata.ownerReferences из найденного ресурса:

d8 k patch vmip linux-vm-7prpx --type=merge --patch '{"metadata":{"ownerReferences":null}}'

# Или внесите аналогичные изменения, отредактировав ресурс.

d8 k edit vmip linux-vm-7prpx

После удаления виртуальной машины ресурс VirtualMachineIPAddress сохранится, и его можно будет переиспользовать снова во вновь созданной виртуальной машине:

spec:
  virtualMachineIPAddressName: linux-vm-7prpx

Даже если ресурс VirtualMachineIPAddress удалить, IP-адрес остаётся арендованным за проектом ещё 10 минут, и его можно занять снова:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineIPAddress
metadata:
  name: linux-vm-custom-ip
spec:
  staticIP: 10.66.20.77
  type: Static
EOF

Доступ к приложениям на виртуальной машине

К виртуальной машине (ВМ) можно обращаться напрямую по её IP-адресу, но у такого подхода есть ограничения. Адрес приходится знать заранее, при пересоздании машины он может смениться, а обратиться сразу к группе машин не получится. Все эти задачи решают сервисы Kubernetes.

Сервис даёт машине или группе машин постоянное имя, за которым скрываются их адреса, и равномерно распределяет между ними запросы. Имя формируется как <SERVICE_NAME>.<NAMESPACE>.svc.<CLUSTER_NAME>, а внутри того же неймспейса достаточно короткой формы <SERVICE_NAME>.

Какой тип сервиса выбрать, зависит от задачи:

• Headless — прямой доступ к конкретным машинам внутри кластера без единой точки входа;
• ClusterIP — единый внутренний адрес с балансировкой между машинами;
• NodePort — доступ извне через порт на узлах кластера;
• LoadBalancer — доступ извне через внешний балансировщик.

Машина попадает в сервис по лейблам. Проставьте машине лейбл, который сервис будет искать:

d8 k label vm linux-vm app=nginx

virtualmachine.virtualization.deckhouse.io/linux-vm labeled

Headless сервис

Headless-сервис не выделяет собственный IP-адрес, а возвращает адреса самих машин. Так вы обращаетесь к конкретной машине по DNS-имени, не заводя для неё отдельную точку входа. Даже для одной машины это удобнее фиксированного адреса, потому что имя не меняется при пересоздании.

d8 k apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: http
  namespace: default
spec:
  clusterIP: None
  selector:
    # Лейбл, по которому сервис отбирает виртуальные машины.
    app: nginx
EOF

Сервис с типом ClusterIP

Такой сервис даёт приложению машины постоянный адрес внутри кластера.

ClusterIP — это стандартный тип сервиса, который предоставляет внутренний IP-адрес для доступа к сервису внутри кластера. Этот IP-адрес используется для маршрутизации трафика между различными компонентами системы и позволяет виртуальным машинам взаимодействовать друг с другом через предсказуемый и стабильный адрес.

d8 k apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: http
spec:
  selector:
    # Лейбл по которому сервис определяет на какую виртуальную машину направлять трафик.
    app: nginx
EOF

Сервис с типом NodePort

Такой сервис открывает приложение машины на порту каждого узла кластера.

NodePort — это расширение сервиса ClusterIP, которое обеспечивает доступ к сервису через заданный порт на всех узлах кластера. Это делает сервис доступным извне кластера через комбинацию IP-адреса узла и порта и подходит для случаев, когда внешний балансировщик не нужен.

d8 k apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: linux-vm-nginx-nodeport
spec:
  type: NodePort
  selector:
    # Лейбл по которому сервис определяет на какую виртуальную машину направлять трафик.
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 31880
EOF

Сервис с типом LoadBalancer

Такой сервис выдаёт приложению внешний адрес через балансировщик нагрузки.

LoadBalancer — это тип сервиса, который автоматически создаёт внешний балансировщик нагрузки с постоянным IP-адресом. Этот балансировщик распределяет входящий трафик среди виртуальных машин, обеспечивая доступность сервиса из интернета.

d8 k apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: linux-vm-nginx-lb
spec:
  type: LoadBalancer
  selector:
    # Лейбл по которому сервис определяет на какую виртуальную машину направлять трафик
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
EOF

Публикация сервисов ВМ с использованием Ingress

Ingress открывает приложение машины по доменному имени и берёт на себя терминацию TLS.

Ingress позволяет управлять входящими HTTP/HTTPS-запросами и маршрутизировать их к различным серверам в рамках вашего кластера. Это наиболее подходящий метод, если вы хотите использовать доменные имена и SSL-терминацию для доступа к вашим виртуальным машинам.

d8 k apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: linux-vm-nginx
spec:
  selector:
    # лейбл по которому сервис определяет на какую виртуальную машину направлять трафик
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
EOF

d8 k apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: linux-vm
spec:
  rules:
    - host: linux-vm.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: linux-vm-nginx
                port:
                  number: 80
EOF

Дополнительные сетевые интерфейсы

Кроме основной сети кластера машину можно подключить к дополнительным сетям, проектным (Network) и кластерным (ClusterNetwork). Нужные сети перечисляют в блоке .spec.networks, а если этот блок не задан, машина работает только в основной сети кластера.

Особенности дополнительных сетевых интерфейсов:

• порядок перечисления сетей в .spec.networks определяет порядок подключения интерфейсов внутри виртуальной машины;
• добавление или удаление дополнительной сети (Network или ClusterNetwork) на работающей ВМ применяется без перезагрузки. ACPI-индексы существующих интерфейсов сохраняются при добавлении и удалении, поэтому имена интерфейсов в гостевой ОС остаются стабильными;
• добавление или удаление основной сети (type: Main) по-прежнему требует перезагрузки ВМ, так как она связана с основным сетевым интерфейсом пода и не может быть изменена на работающем поде;
• чтобы сохранить порядок сетевых интерфейсов внутри гостевой операционной системы, добавляйте новые сети в конец списка .spec.networks и не меняйте порядок существующих;
• политики сетевой безопасности (NetworkPolicy) не применяются к дополнительным сетевым интерфейсам;
• параметры сети (IP-адреса, шлюзы, DNS и так далее) для дополнительных сетей настраиваются вручную изнутри гостевой ОС (например, с помощью Cloud-Init), если для сети не настроен IPAM, описанный в подразделе «IPAM для дополнительных сетевых интерфейсов».

Для каждого дополнительного сетевого интерфейса автоматически создаётся и резервируется уникальный MAC-адрес, что обеспечивает отсутствие коллизий MAC-адресов. Для этого служат ресурсы VirtualMachineMACAddress (vmmac) и VirtualMachineMACAddressLease (vmmacl).

MAC-адрес генерируется случайным образом из пула разрешённых диапазонов.

• Диапазоны: x2-xx-xx-xx-xx-xx, x6-xx-xx-xx-xx-xx, xA-xx-xx-xx-xx-xx, xE-xx-xx-xx-xx-xx.
• Первые три октета (OUI) формируются на основе UUID кластера, последние три (NIC) — выбираются случайно из 16 миллионов возможных комбинаций.

Кластерный ресурс VirtualMachineMACAddressLease (vmmacl) управляет арендой адресов из общего пула, а проектный ресурс VirtualMachineMACAddress (vmmac) отвечает за резервирование арендованных адресов и их привязку к машинам. Адрес закрепляется за машиной до её удаления.

При удалении сети из конфигурации ВМ:

• MAC-адрес интерфейса освобождается.
• Автоматически удаляются связанные ресурсы VirtualMachineMACAddress и VirtualMachineMACAddressLease.
• Автоматически удаляется выделенный ресурс IPAddress (если использовался IPAM).

Ниже показано, как подключить машину к дополнительной сети:

spec:
  networks:
    - type: Main # Если указана, должна быть первой
    - type: Network # Тип сети (Network \ ClusterNetwork)
      name: user-net # Название сети

spec:
  networks:
    - type: Main # Если указана, должна быть первой
    - type: Network
      name: user-net
    - type: ClusterNetwork
      name: corp-net # Название сети

spec:
  networks:
    - type: Network
      name: isolated-net
    - type: ClusterNetwork
      name: corp-net

status:
  networks:
    - type: Main
    - type: Network
      name: user-net
      macAddress: aa:bb:cc:dd:ee:01
    - type: ClusterNetwork
      name: corp-net
      macAddress: aa:bb:cc:dd:ee:02

d8 k get vmmacl

NAME                    VIRTUALMACHINEMACADDRESS                      STATUS   AGE
mac-5e-e6-19-22-0f-d8   {"name":"vm-01-fz9cr","namespace":"pr-sdn"}   Bound    45s
mac-5e-e6-19-29-89-cf   {"name":"vm-01-99qj6","namespace":"pr-sdn"}   Bound    45s
mac-5e-e6-19-54-f9-be   {"name":"vm-01-5jqxg","namespace":"pr-sdn"}   Bound    45s

d8 k get vmmac

NAME          ADDRESS             STATUS     VM      AGE
vm-01-5jqxg   5e:e6:19:54:f9:be   Attached   vm-01   5m42s
vm-01-99qj6   5e:e6:19:29:89:cf   Attached   vm-01   5m42s
vm-01-fz9cr   5e:e6:19:22:0f:d8   Attached   vm-01   5m42s

Именование интерфейсов и ARP Flux в гостевой ОС

При настройке сетевых интерфейсов в гостевой ОС используйте стабильные идентификаторы (предсказуемые имена enpXsY или привязку по MAC-адресу) вместо имён ethX, как описано в разделе «Именование сетевых интерфейсов в гостевой ОС».

На гостевой системе Linux с несколькими интерфейсами в одной подсети может возникать проблема ARP Flux, при которой ядро отвечает на ARP-запросы через произвольный интерфейс, а не через тот, на который пришёл запрос, что приводит к нестабильному соединению и потере пакетов из-за некорректного MAC-адреса в кеше маршрутизаторов.

Чтобы это исправить, установите параметры, которые заставляют систему отвечать на запросы строго через интерфейс с целевым IP и использовать корректный исходный адрес:

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

Пример для cloud-init:

write_files:
- path: /etc/sysctl.d/90-arp-strict.conf
content: |
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Значения параметров описаны в документации IP sysctl.

IPAM для дополнительных сетевых интерфейсов

Адреса в дополнительной сети DP может выдавать сам, если администратор настроил для этой сети пул адресов.

Если в модуле sdn для дополнительной сети настроен IPAM (пул IP-адресов, привязанный к сети через spec.ipam.ipAddressPoolRef), DP может автоматически выделять IP-адреса для дополнительных интерфейсов ВМ и доставлять их в гостевую ОС через DHCP.

Поддерживаются два режима:

• Автоматический (DHCP) — если в .spec.networks[] не указано поле ipAddressName, контроллер автоматически создаёт ресурс IPAddress (тип Auto), привязанный к ВМ через ownerReferences, и передаёт его в модуль sdn. Модуль sdn выделяет адрес из пула и доставляет его в гостевую ОС через DHCP. Адрес сохраняется при перезагрузках и миграции ВМ, поскольку привязан к ВМ, а не к поду. Для работы этого режима в гостевой ОС на соответствующем интерфейсе должен быть включён DHCP-клиент.

• Статический — если в .spec.networks[] указано поле ipAddressName, контроллер использует предоставленный пользователем ресурс IPAddress (тип Static, network.deckhouse.io/v1alpha1). Адрес определяется пользователем и не изменяется автоматически.

Если у дополнительной сети не настроен пул IPAM, функция IPAM не включается. Интерфейс работает в режиме L2-only, а IP-адресацию необходимо настроить вручную в гостевой ОС.

spec:
  networks:
    - type: Main
    - type: ClusterNetwork
      name: corp-net
      # ipAddressName не указан → используется автоматический режим (DHCP)

spec:
  networks:
    - type: Main
    - type: ClusterNetwork
      name: corp-net
      ipAddressName: my-static-ip # Имя ресурса IPAddress (SDN)

apiVersion: network.deckhouse.io/v1alpha1
kind: IPAddress
metadata:
  name: my-static-ip
  namespace: my-namespace
spec:
  networkRef:
    kind: ClusterNetwork
    name: corp-net
  type: Static
  static:
    ip: 192.168.200.42

status:
  ipAddress: 10.66.10.2                     # IP-адрес основной сети.
  virtualMachineIPAddressName: vm-01-main-ip # Имя IPAddress основной сети.
  networks:
    - type: Main
    - type: ClusterNetwork
      name: corp-net
      macAddress: 32:a6:a1:0a:92:48
      virtualMachineMACAddressName: vm-01-rxzd6
      ipAddress: 192.168.200.4               # IP-адрес дополнительной сети (из IPAM).

Настройка гостевой ОС для интерфейсов, добавленных на ходу

Когда дополнительный сетевой интерфейс подключают к уже запущенной ВМ, гостевая ОС должна быть настроена на автоматический подъём новых сетевых интерфейсов и запрос DHCP-аренды. Linux по умолчанию не запускает DHCP-клиент на интерфейсах, добавленных на ходу.

Чтобы такие интерфейсы настраивались сами, используйте в гостевой ОС один из следующих подходов:

• NetworkManager (Ubuntu, RHEL, CentOS) — автоматически настраивает новые интерфейсы с DHCP, если запущен сервис network-manager;

• udev-правило (Alpine и другие системы без network-manager) — добавьте udev-правило для подъёма новых интерфейсов:

  write_files:
    - path: /etc/udev/rules.d/90-hotplug-network.rules
      content: |
        SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/ifup %k"

Для интерфейсов, присутствующих при загрузке ВМ (включённых в начальную сетевую конфигурацию), дополнительная настройка не требуется — гостевая ОС настраивает их при запуске через Cloud-Init.

Снимки, восстановление и клонирование

Снимки позволяют зафиксировать текущее состояние ресурса для последующего восстановления или клонирования. Снимок диска сохраняет только данные выбранного диска, а снимок виртуальной машины (ВМ) включает в себя её параметры и состояние всех дисков.

Консистентные снимки

Снимки могут быть консистентными и неконсистентными. За это отвечает параметр requiredConsistency, по умолчанию его значение равно true, что означает требование консистентного снимка.

Консистентный снимок фиксирует согласованное и целостное состояние данных диска. Такой снимок можно создать при выполнении одного из следующих условий:

• диск не подключён ни к одной виртуальной машине — снимок всегда будет консистентным;
• виртуальная машина выключена;
• в гостевой ОС установлен и запущен qemu-guest-agent. При создании снимка он временно приостанавливает («замораживает») работу файловой системы, чтобы обеспечить согласованность данных.

Неконсистентный снимок может не отражать согласованное состояние дисков виртуальной машины и её компонентов. Такой снимок создаётся, если ВМ запущена, и в гостевой ОС не установлен или не запущен qemu-guest-agent. Если в манифесте снимка явно указан параметр requiredConsistency: false, но qemu-guest-agent при этом запущен, будет также предпринята попытка заморозки файловой системы, чтобы снимок получился консистентным.

QEMU Guest Agent поддерживает скрипты hooks, которые позволяют подготовить приложения к созданию снимка без остановки сервисов, обеспечивая согласованное состояние на уровне приложений. Настройка скриптов hooks описана в разделе «Агент гостевой ОС».

Создание снимков дисков

Снимок диска сохраняет его данные на момент создания и служит источником для новых дисков.

Снимки дисков описывает ресурс VirtualDiskSnapshot. Они могут служить источником данных при создании новых дисков, например для клонирования или восстановления информации.

Целостность данных гарантирована, когда снимок создают в одном из следующих случаев:

• Диск не подключён ни к одной виртуальной машине.
• ВМ выключена.
• ВМ запущена, в гостевой ОС установлен qemu-guest-agent, и файловая система успешно «заморожена» (операция fsfreeze).

Если консистентность данных не требуется (например, для тестовых сценариев), задайте в снимке параметр .spec.requiredConsistency со значением false. Тогда снимок создаётся и на работающей ВМ без «заморозки» файловой системы, в том числе когда диск подключён к ней.

Снимок диска проходит следующие фазы:

• Pending — ожидание готовности всех зависимых ресурсов, требующихся для создания снимка.
• InProgress — идёт процесс создания снимка виртуального диска.
• Ready — создание снимка успешно завершено, и снимок виртуального диска доступен для использования.
• Failed — произошла ошибка во время процесса создания снимка виртуального диска.
• Terminating — ресурс находится в процессе удаления.

Причину проблемы с ресурсом показывает блок .status.conditions.

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualDiskSnapshot
metadata:
  name: linux-vm-root-snapshot
spec:
  requiredConsistency: true
  virtualDiskName: linux-vm-root
EOF

d8 k get vdsnapshot

NAME                   PHASE     CONSISTENT   AGE
linux-vm-root-snapshot Ready     true         3m2s

Восстановление дисков из снимков

Из снимка создаётся новый диск, а исходный остаётся нетронутым.

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualDisk
metadata:
  name: linux-vm-root
spec:
  # Настройки параметров хранения диска.
  persistentVolumeClaim:
    # Укажем размер больше чем значение .
    size: 10Gi
    # Подставьте ваше название StorageClass.
    storageClassName: rv-thin-r2
  # Источник из которого создается диск.
  dataSource:
    type: ObjectRef
    objectRef:
      kind: VirtualDiskSnapshot
      name: linux-vm-root-snapshot
EOF

Создание снимков ВМ

Снимок виртуальной машины — это сохранённое состояние виртуальной машины в определённый момент времени. Для создания снимков виртуальных машин используется ресурс VirtualMachineSnapshot.

Создание снимка виртуальной машины будет неудачным, если выполнится хотя бы одно из следующих условий:

• не все зависимые устройства виртуальной машины готовы;
• среди зависимых устройств есть диск, находящийся в процессе изменения размера.

При создании снимка динамический IP-адрес ВМ автоматически преобразуется в статический и сохраняется для восстановления. Если преобразование и использование старого адреса не нужны, задайте параметру .spec.keepIPAddress значение Never, и тогда тип адреса останется прежним (Auto или Static).

Ниже показано, как создать снимок виртуальной машины:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineSnapshot
metadata:
  name: linux-vm-snapshot
spec:
  virtualMachineName: linux-vm
  requiredConsistency: true
  keepIPAddress: Never
EOF

status:
  ...
  resources:
  - apiVersion: virtualization.deckhouse.io/v1alpha2
    kind: VirtualMachine
    name: linux-vm
  - apiVersion: v1
    kind: Secret
    name: cloud-init
  - apiVersion: virtualization.deckhouse.io/v1alpha2
    kind: VirtualDisk
    name: linux-vm-root

Восстановление ВМ

Восстановление возвращает машину и её диски к состоянию, сохранённому в снимке. Запускает его ресурс VirtualMachineOperation с типом Restore, у которого есть три режима:

• DryRun — холостой запуск операции восстановления, необходим для проверки возможных конфликтов, которые будут отображены в статусе ресурса (status.resources).
• Strict — режим строгого восстановления, когда требуется восстановление ВМ «как в снимке», отсутствующие внешние зависимости могут привести к тому, что ВМ после восстановления будет в Pending.
• BestEffort — отсутствующие внешние зависимости (ClusterVirtualImage, VirtualImage) игнорируются и удаляются из конфигурации ВМ.

Восстановление виртуальной машины из снимка возможно только при выполнении всех следующих условий:

• Восстанавливаемая ВМ присутствует в кластере (ресурс VirtualMachine существует, а его .metadata.uid совпадает с идентификатором, использованным при создании снимка).
• Восстанавливаемые диски (определяются по имени) либо не подключены к другим ВМ, либо отсутствуют в кластере.
• Восстанавливаемый IP-адрес либо не занят другой ВМ, либо отсутствует в кластере.
• Восстанавливаемые MAC-адреса либо не используются другими ВМ, либо отсутствуют в кластере.

Вместе с машиной восстанавливаются и её диски, поэтому в спецификации диска будет указан параметр dataSource со ссылкой на нужный снимок диска.

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineOperation
metadata:
  name: <VMOP_NAME>
spec:
  type: Restore
  virtualMachineName: <VM_NAME>
  restore:
    mode: DryRun | Strict | BestEffort
    virtualMachineSnapshotName: <VM_SNAPSHOT_NAME>