Делаем собственные шаблоны апплайнсов для oVirt

В данной серии статей я планирую рассказать о том, как создавать виртуальные апплайнсы для платформы виртуализации oVirt. Несмотря на использование oVirt в качестве эталонной платформы, приведенные ниже инструкции и рекомендации могут быть легко адаптированы и для других решений вроде Proxmox, Open Nebula, Open Stack или обычного KVM.

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

Все скрипты, приведенные в данной статье, доступны на странице в GitHub: https://github.com/omnimod/ovirt-appliance

Введение

До сих пор виртуальные апплайнсы остаются одним из самых удобных способов доставки и развертывания ПО в виртуальных инфраструктурах. Идейным вдохновителем данной концепции стала компания VMware, которая поставляет большую часть своего ПО в виртуальных апплайнсах. В качестве примера на ум приходит VMware vCenter Server, который присутствует буквально в каждой инфраструктуре vSphere, SDN контроллер NSX Manager, сервер мониторинга Aria Operations и многие другие. Для других платформ такой подход также часто применяется. Например, сервер управления oVirt Engine - аналог vCenter также может поставляться в виде виртуального апплайнса.

Несколько лет назад я уже писал о том, как создавать виртуальные апплайнсы в vSphere. Данная возможность реализована благодаря поддержке OVF (Open Virtualization Format) - специальному формату, который позволяет описывать конфигурацию ВМ, а также дополнительные параметры для настройки гостевой ОС и приложений при развертывании ВМ из шаблона.

Дополнительную информацию о возможностях OVF и работе с ним вы можете узнать из статьи: https://blog.vmpress.org/2017/01/appliance.html

Несмотря на то, что формат OVF является открытым и поддерживается во многих Open Source решениях, не все платформы виртуализации предоставляют одинаковые возможности при работе с OVF шаблонами. Например, oVirt в отличие от VMware vSphere не поддерживает работу с расширенными свойствами и конфигурациями в OVF шаблоне. Также не все платформы виртуализации поддерживают виртуальные flat и sparse диски vmdk. Из-за данных ограничений OVF шаблоны не выглядят столь эффективными для передачи и развертывание ВМ на платформах виртуализации, отличных от VMware.

С другой стороны, oVirt поддерживает Cloud-init - другой распространенный способ для автоматической настройки ВМ в виртуальных инфраструктурах и облаках, благодаря которому можно реализовать схожие возможности по настройке ВМ.

Для наглядности я опишу процесс подготовки шаблона виртуального апплайнса с веб-сервером Nginx и покажу, как с помощью Cloud-init, нескольких скриптов и утилит можно выполнять автоматическую настройку гостевой ОС и приложения.

Установка ОС

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

В качестве основы возьмём Ubuntu Server 22.04. Для тестов не играет особой роли, какой дистрибутив вы выберите, но на практике всегда следует стремиться к тому, чтобы апплайнс занимал минимальное место на диске, не был перегружен лишними утилитами и сервисами, и на нём были установлены только те инструменты, которые требуются для его работы.

Для чистовой установки загрузите дистрибутив Ubuntu Live Server 22.04.5 с сайта Canonical: https://ubuntu.com/download/alternative-downloads

Создайте ВМ с необходимыми ресурсами, например: 2 vCPU, 2 GB RAM, 6 GB Disk и одним сетевым адаптером. Создайте тонкий диск в формате QCOW2, чтобы после подготовки образ не занимал лишнее дисковое пространство, и его было проще загружать и импортировать.

Из дополнительных параметров ВМ выберите:

• General -> Chipset/Firmware Type: Q35 Chipset with UEFI, но если требуется образ минимального размера, то можно выбрать Q35 Chipset with BIOS и сэкономить место, которое используется под раздел /boot/efi.

Остальные настройки ВМ оставьте по умолчанию.

Подключите к ВМ ISO образ с дистрибутивом Ubuntu Server и запустите ВМ. При установке ОС выберите следующие параметры:

• Choose the base for the installation: Ubuntu Server (minimized) - выполнит установку ОС, которая будет занимать минимальное пространство на диске, содержащую только базовые компоненты и утилиты, необходимые для работы.
• Configure a guided storage layout: Use an entire disk
• Разметка диска: оставьте по умолчанию
• Default user: user (здесь и далее для настройки будет использоваться учетная запись пользователя с именем user)
• Пароль по умолчанию: на ваше усмотрение
• Install OpenSSH server: включено

Остальные параметры оставьте по умолчанию.

В качестве альтернативного варианта вместо установки ВМ можно загрузить готовый образ виртуального диска с предустановленной ОС (jammy-server-cloudimg-amd64.img) с сайта: https://cloud-images.ubuntu.com/jammy/current/

Видеоинструкция по импорту виртуального диска в oVirt, созданию ВМ и подключению к ней диска доступна по ссылке: https://www.youtube.com/watch?v=dUNYrCoCcmg

Настройка ОС

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

Обновление ОС и установка пакетов

Для начала обновите ОС и установите несколько дополнительных пакетов:

sudo apt update && sudo apt upgrade -y

sudo apt install cockpit nano network-manager nginx pvm-dev qemu-guest-agent whiptail -y

Данный набор пакетов является минимально необходимым для дальнейшей настройки апплайнса. При желании вы можете заменить nano на другой привычный вам редактор. По остальным пакетам:

• cockpit и pvm-dev - сервис для удаленной настройки сервера через веб-интерфейс.
• network-manager - используется для настройки сетевых интерфейсов.
• nginx - веб-сервер, который будет играть роль ПО, работающего на апплайнсе, которое мы будем настраивать.
• qemu-guest-agent - агент для получения oVirt'ом информации о статусе гостевой ОС и дополнительной служебной информации, вроде имени хоста и назначенных сетевых адресов.
• whiptail - утилита для отрисовки псевдографического интерфейса в консоли.

Настройка сети

Если вы планируете настраивать сетевые интерфейсы апплайнса с помощью Network Manager, отредактируйте файл 50-cloud-init.yaml в каталоге /etc/netplan/, либо создайте новый файл конфигурации netplan и добавьте в него строчку renderer: NetworkManager в раздел network, например:

network:

  version: 2

  renderer: NetworkManager

  ethernets:

    enp1s0:

      dhcp4: yes

Затем примените примените настройки Netplan:

sudo netplan apply

Запуск SUDO без ввода пароля

При работе с апплайнсом из командной строки можно настроить запуск команд в режиме sudo без необходимости вводить пароль. Для этого потребуется отредактировать файл /etc/sudoers, добавив в него строку:

user ALL=(ALL) NOPASSWD:ALL

, где user - имя учетной записи пользователя, для которого требуется запускать sudo без запроса пароля.

Автоматический вход в систему

Для упрощения настройки апплайнса на первом этапе можно настроить автоматический вход под учетной записью пользователя при подключении к локальной консоли (например, tty1) без аутентификации. Такой вариант можно совместить с мастером первоначальной настройки, который будет запускаться при первом старте апплайнса и выполнять базовую конфигурацию ОС, например, задавать имя хоста, сетевые настройки, менять пароль администратора и пр.

Для примера выполним настройки для двух виртуальных терминалов. Для tty1, который будет отображаться по умолчанию, настроим автоматический вход под учетной записью user, а для tty2 оставим возможность входа по логину и паролю.

Для настройки автоматического локального входа в систему нужно отредактировать файл /etc/systemd/logind.conf, раскомментировать в нем следующие строки и указать количество виртуальных терминалов:

NAutoVTs=1

ReserverVT=2

А также создать файл настроек для автоматического входа в систему:

sudo mkdir /etc/systemd/system/getty@tty1.service.d/

sudo sh -c "cat << 'EOF' > /etc/systemd/system/getty@tty1.service.d/override.conf

[Service]

ExecStart=

ExecStart=-/sbin/agetty --noissue --autologin user %I $TERM

Type=idle

EOF"

, где user - имя пользователя для автоматического входа в систему.

Теперь при каждом запуске апплайнса или завершении сеанса в ttyt1 будет выполняться автоматический вход в систему под учетной записью user. Для отключения автоматического входа достаточно удалить или переименовать файл override.conf в каталоге /etc/systemd/system/getty@tty1.service.d/.

sudo mv /etc/systemd/system/getty@tty1.service.d/override.conf /etc/systemd/system/getty@tty1.service.d/override.conf.old

Message of the Day

При подключении к локальной консоли или по ssh вы можете увидеть приветственное оповещение, которое содержит различную полезную информацию о состоянии системы и ссылки на документацию (Message of the Day).

В Ubuntu MOTD генерируется при помощи скриптов, размещенных в каталоге /etc/update-motd.d. Очередность выводимого текста определяется последовательностью именования файлов скриптов.

Для примера удалим существующие скрипты и создадим новый скрипт, который выводит приветствие, информацию о названии апплайнса и его IP адрес.

sudo rm -f /etc/update-motd.d/*

cat << 'EOF' | sudo tee /etc/update-motd.d/01-welcome

#!/bin/sh

printf "Welcome to Appliance OS\n"

printf "Hostname: %s\n" "$(hostname)"

printf "IP Address: %s\n" "$(hostname -I)"

EOF

sudo chmod +x /etc/update-motd.d/01-welcome

Посмотреть сгенерированный MOTD можно, открыв файл /var/run/motd.dynamic.

Псевдографический интерфейс

Многие виртуальные апплайнсы позволяют выполнять базовые настройки без ввода команд в консоли, используя псевдографический интерфейс. Сделать такой интерфейс не сложно, если использовать bash и whiptail. Whiptail позволяет отрисовывать различные виды окон для отображения текстовой информации, создания форм для ввода текста или меню для выбора действий: https://en.wikibooks.org/wiki/Bash_Shell_Scripting/Whiptail

Для примера я подготовил скрипт, который отрисовывает меню выбора типовых действий, вроде настройки сетевых интерфейсов через Network Manager UI, смены номера порта для сервера Nginx или перезапуска ОС.

Чтобы добавить меню сохраните скрипт show-appliance-menu.sh в каталоге /usr/bin/ и разрешите его выполнение:

sudo chmod +x /usr/bin/show-appliance-menu.sh

Для настройки Nginx я подготовил еще два скрипта load-app-config.sh и save-app-config.sh. Сохраните их в каталоге /usr/sbin/ и разрешите выполнение:

sudo chmod +x /usr/sbin/load-app-config.sh

sudo chmod +x /usr/sbin/save-app-config.sh

Эти же скрипты будут использоваться для настройки Nginx через VAMI интерфейс в следующем разделе.

Если вы хотите, чтобы меню show-appliance-menu.sh автоматически запускалось при входе пользователя в консоль или подключении по ssh, то просто добавьте в конец файла ~/.profile в домашней директории пользователя путь к скрипту:

echo /usr/bin/show-appliance-menu.sh >> ~/.profile

Virtual Appliance Management Interface

Cockpit

Многие виртуальные апплайнсы предоставляют специализированный интерфейс управления, доступный при подключении с помощью веб-браузера. Через такой интерфейс можно выполнить базовые настройки и посмотреть статус работы ОС и сервисов. В качестве примера можно привести VAMI интерфейс в vCenter Server и других виртуальных апплайнсах VMware. 

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

Установите Cockpit и зависимости, если не сделали этого ранее:

sudo apt install pvm-dev cockpit -y

Интерфейс Cockpit по умолчанию доступен при подключении через веб-браузер на адрес: https://<server_ip>:9090. Для измененая номера порта можете воспользоваться инструкцией: https://cockpit-project.org/guide/latest/listen.html

Для безопасного подключения при установке в каталоге /etc/cockpit/ws-certs.d создается самозаверенный сертификат, который при необходимости можно заменить на сертификат от доверенного УЦ.

Cockpit поддерживает аутентификацию с помощью локальных учетных записей пользователей.

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

Для настройки сетевых интерфейсов через Cockpit требуется, чтобы в настройках netplan был указан renderer: NetworkManager. Также при использовании Network Manager отключите сервис /lib/systemd/system/systemd-networkd-wait-online.service, чтобы избежать ошибки timeout'а при попытке запустить сервис networkd для настройки интерфейсов:

sudo systemctl disable /lib/systemd/system/systemd-networkd-wait-online.service

Плагин Cockpit для настройки приложения

Огромным плюсом Cockpit является возможность расширения за счет использования плагинов. Посмотреть список установленных плагинов можно с помощью команды:

cockpit-bridge --packages

Предустановленные плагины по умолчанию размещаются в дочерних директориях в каталоге /usr/share/cockpit/. Каждый плагин содержит файл манифеста, веб-страницы и js скрипты, с помощью которых можно выполнять действия в системе.

Описание файла манифеста доступно по ссылке: https://cockpit-project.org/guide/latest/packages.html#package-manifest

Для оформления интерфейса встроенные плагины используют дизайн модель Patternfly (https://www.patternfly.org/), но вам ничто не мешает использовать собственные CSS шаблоны и ресурсы для оформления страницы плагина.

Для примера я подготовил простой плагин на базе статического html документа, с помощью которого можно настроить порта для сервиса Nginx.

Для добавления плагина создайте каталог myapp в /usr/share/cockpit/:

sudo mkdir /usr/share/cockpit/myapp

Скопируйте в данный каталог три файла: manifest.json, myapp.html и myapp.js.

Также  скопируйте файлы load-app-config.sh и save-app-config.sh в каталог /usr/sbin и разрешите их выполнение, если не сделали этого ранее.

Перезагрузите страницу Cockpit в браузере, теперь на панели навигации появится новый раздел MyApp, в котором можно будет посмотреть и изменить номер порта Nginx.

Подготовка к автоматизированному развертыванию

Как я говорил в начале статьи, одним из плюсов формата OVF в vSphere является поддержка передачи параметров в гостевую ОС при развертывании ВМ из шаблона. Это позволяет администраторам задать настройки, используя мастер импорта, и получать ВМ, готовую к работе сразу после развертывания.

Схожие возможности можно реализовать при помощи сценариев Cloud-init. Например, в oVirt при кастомизации ОС через Cloud-init можно запускать произвольные команды и скрипты внутри гостевой ОС.

Давайте добавим в гостевую ОС еще один скрипт для первоначальной настройки: init-appliance.sh, с помощью которого можно будет настроить сетевой интерфейс ВМ, имя хоста и порт для сервера Nginx.

Скопируйте файл init-appliance.sh в каталог /usr/sbin/ и настройте разрешение на выполнение:

chmod +x /usr/sbin/init-appliance.sh

Скрипт поддерживает следующие опции при запуске:

• -n, --hostname - имя хоста
• -m, --mode - режим настройки сети на интерфейсе: dhcp | static
• -a, --address - сетевой адрес в CIDR формате при статической настройке
• -g, --gateway - адрес маршрутизатора по умолчанию
• -d, --dnsservers - список dns серверов, разделенных запятой
• -p, --port - порт для Nginx сервера

Теперь при первом запуске ВМ достаточно будет запустить Cloud-init, добавив в поле Custom Scripts дополнительную команду для запуска скрипта с нужными параметрами, например:

runcmd:

  - init-appliance.sh -n app02a -m static -a 192.168.1.228/24 -g 192.168.1.1 -d 192.168.1.2,192.168.1.3 -p 8080

Задаст имя хоста app02a, настроит статический IP адрес 192.168.1.228 с 24 маской на сетевом интерфейсе enp1s0 и поменяет порт Nginx на 8080.

Очистка апплайнса от артефактов

Перед тем как приступить к тестированию развертывание апплайнса потребуется очистить его от временных файлов, ключей безопасности и подготовить к запуску Cloud-init.

Существует два вариант как это можно сделать:

• Скриптом перед финальным выключением ВМ.
• Функцией запечатывания (Seal Template), встроенной в oVirt.

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

Вот пример скрипта, который удаляет временные файлы и устаревшие пакеты, обнуляет machine-id, а также удаляет SSH существующие ключи.

# Удаление временных файлов

sudo rm -rf /tmp/*

sudo rm -rf /var/tmp/*

# Пересоздание SSH ключей

rm -f /etc/ssh/ssh_host_*

# Очистка локального репозитория

sudo apt clean

# Очистка артефактов cloud-init

sudo cloud-init clean --logs --seed

# Удаление machine-id

cat /dev/null | sudo tee /etc/machine-id

sudo rm /var/lib/dbus/machine-id

sudo ln -s /etc/machine-id /var/lib/dbus/machine-id

# Очистка истории bash

history -w && cat /dev/null > ~/.bash_history

history -c

Примечание: если вы удаляете SSH ключи с помощью скрипта, то важно, чтобы при развертывании ВМ была выбрана опция Regenerate SSH Keys, либо в скрипт init-appliance.sh добавлена строчка dpkg-reconfigure openssh-server, иначе сервис ssh не сможет корректно стартовать.

После выполнения скрипта просто выключите ВМ и шаблон готов.

Второй вариант - создать из ВМ шаблон и запечатать его. Для этого выключите ВМ и в консоли oVirt выберите действие Make Template.

В окне настроек шаблона выберите опцию Seal Template (Linux only). 

При создании шаблона oVirt запустит утилиту virt-sysprep, которая удалит с диска ВМ все артефакты, включая ssh ключи, machine-id, историю bash и прочие артефакты.

Примечание: в oVirt 4.5.5 есть баг из-за которого при создании Sealed шаблона у всех ВМ, создаваемых из данного шаблона остается установленным флаг Sealed, что приводит к ошибке при развертывания. Для решение данной проблемы просто откройте созданный шаблон на редактирование, на вкладке General проверьте, что флажок Sealed находится в выключенном положении и нажмите OK для применения настроек. После этого ВМ будут создаваться без флага Sealed.

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

Тестовое развертывание

Настало время протестировать автоматическую настройку нового апплайнса.

В зависимости от того, какой выбор очистки от артефактов вы выбрали, создайте новую тестовую машину из существующей ВМ или из созданного шаблона.

После завершения создания выберите опцию Run One и укажите настройки Cloud-init, которые требуется передать в новую ВМ:

• Cloud-init - установите флаг для инициализации Cloud-init при следующем запуске ВМ.
• VM Hostname - имя хоста в гостевой ОС. Данный параметр является опциональным, т.к. скрипт init-appliance.sh также может менять имя хоста.
• Configure Time Zone - установка временной зоны в гостевой ОС.
• Authentication - позволяет создать пользователя по умолчанию или поменять пароль, если пользователь уже существует (например, если указать User Name: user, Password и Verify Password), а также добавить разрешенные ключи для доступа по SSH.
• Regenerate SSH Keys - пересоздать приватные и публичные ключи SSH сервера в гостевой ОС.
• Network - позволяет настроить сетевые интерфейсы. Данный раздел является опцпиональным, т.к. скрипт init-appliance.sh также может менять сетевые настройки интерфейса.
• Custom Script - может содержать дополнительные операции, которые должен выполнить Cloud-init. Например:

runcmd:

  - init-appliance.sh -n app02a -m static -a 192.168.1.228/24 -g 192.168.1.1 -d 192.168.1.2,192.168.1.3 -p 8080

Дождитесь завершения загрузки ВМ и работы Cloud-init. После запуска гостевая ОС будет автоматически настроена в соответствии с параметрами, которые были переданы в Custom Script.

На этом наш шаблон виртуального апплайнса готов. Вы можете экспортировать файл виртуального диска .qcow2 или весь шаблон в виде .OVA архива для развертывания на целевых платформах виртуализации.

В следующей части мы поговорим о том, как можно упростить передачу параметров Cloud-init с помощью собственного мастера развертывания виртуального апплайнса.

Перечень возможностей oVirt по работе с Виртуальными Машинами

На своей странице в Gitbook я выложил таблицу с перечнем функциональных возможностей oVirt по работе с виртуальными машинами.

Все функции разбиты на несколько категорий - работа с процессорами, памятью, дисками, снапшотами и т.д.

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

Плейбук Ansible для массового создания ВМ в vSphere

Недавно на своей страничке в GitHub я опубликовал плейбук Ansible для автоматического создания виртуальных машин в vSphere. Плейбук получает входные параметры из CSV файла и с помощью модуля vmware_guest создает и настраивает ВМ.

Persistent Disk в Horizon 8 2306

Одним из нововведений Horizon 8 2306 стало возвращение функции Persistent Disk, хорошо известной администраторам Horizon 7. Зачем это нужно и в чем отличия новой реализации?

Persistent Disk доступны во всех редакциях Horizon и позволяют подключать к виртуальным десктопам с Windows выделенные диски, на которые переносятся профили и документы пользователей. Это позволяет сохранять все изменения сделанные пользователя даже после завершения рабочего сеанса и отката Instant Clone десктопов, без необходимости использования сторонних инструментов вроде перемещаемых профилей Windows.

Тестирование производительности сети с iPerf в ВМ с Windows

Часто возникает необходимость определить максимальную скорость передачи данных (Bandwidth) по сети между ВМ.

Помочь в этом может утилита iPerf (https://github.com/esnet/iperf), которая работает под Linux, Windows, MacOS, Android, iOS, FreeBSD и даже ESXi.

Для тестирования скорости на одной ВМ достаточно запустить iperf с ключом -s, данная ВМ будет выполнять роль сервера, а на второй ВМ выполнить iperf -c <IP_адрес_сервера>.

Но если речь идет о тестировании производительности в сети 10 Гбит/с или выше, то при запуске теста с настройками по умолчанию вы редко сможете увидеть максимально возможную скорость передачи данных.

Ниже приведены рекомендации и ссылки на сторонние ресурсы, которые позволят добиться более высокой скорости передачи данных в тестах. Важно отметить, что не все из них применимы применимы при оптимизации ВМ под реальные нагрузки, а при необходимости достижения минимальных задержек или максимального кол-ва передаваемых пакетов (packet rate) некоторые из рекомендаций, наоборот, приведут к худшим результатам.

Зачем указывать Gateway Location в свойствах UAG

При настройке интеграции Unified Access Gateway с Horizon внимание администраторов может привлечь параметр Gateway Location.

Официальная документация на UAG дает мало информации не очень и говорит, что параметр определяет место, откуда выполняется подключение, и может иметь одно из двух значений: External или Internal. Но для чего разделять подключения на внешние и внутренние, и в каких случаях это может пригодиться?

База знаний по oVirt

Те, кто недавно посещал данный блог, могли заметить, что в области навигации появился новый раздел Руководство oVirt. Я немного отошел от темы продуктов VMware (хотя и не собираюсь забрасывать их) и в последние месяцы осваиваю альтернативные платформы. За это время я успел накопить некий багаж знаний, который решил оформить в виде статей на Gitbook. Поэтому если вы или ваши коллеги,эксплуатируют или только присматриваются к oVirt, думаю, вы найдете эти материалы полезными.

Также я сделал пару демо-роликов на своем Youtube-канале. 

Пока это только малая часть того, что я успел раскопать по oVirt, периодически я планирую обновлять материалы и добавлять новые статьи.

Настраиваем Ubuntu под VDI с помощью Ansible

Настройка Linux в качестве виртуального десктопа для VMware Horizon - не самая простая и быстрая задача. В свое время VMware даже опубликовала готовый виртуальны апплайнс на базе Ubuntu 18.04, который с помощью shell скрипта и черной магии позволял автоматизировать многие рутинные задачи для подготовки виртуального десктопа. Отдельно скрипт можно загрузить с репозитория на GitHub: https://github.com/thatvirtualboy/horizon-linux-vm

К сожалению, с тех пор данный проект не обновлялся, и для новых версий Ubuntu 20.04 и Ubuntu 22.04 без доработок он не подходит.

Поэтому я написал небольшой playbook для Ansible, чтобы автоматизировать настройку Ubuntu 18.04 / 20.04 / 22.04 под Horizon: https://github.com/omnimod/linux-optimize4vdi

Linux-optimize4vdi выполняет основные шаги по настройке гостевой ОС с Ubuntu, такие как обновление ОС, удаление/установка пакетов, установка параметров рабочего стола GNOME и т.д. Текущая версия поддерживает Ubuntu 22.04.

Автоматизация функций

Этот плейбук выполняет следующие оптимизации:

1. Удаляет ненужные приложения из Ubuntu (игры, утилиты USB Creator и Transmission).
2. Обновляет и апгрейдит пакеты с помощью apt update && apt upgrade.
3. Обновляет установленные приложения с помощью snap refresh.
4. Устанавливает последнюю версию Open-VM-Tools.
5. Устанавливает новые приложения через apt (chromium, 7zip, vlc, telegram desktop client и zoom client).
6. Отключает автоматические обновления и апдейты apt.
7. Включает тихую загрузку GRUB.
8. Отключает гибернацию и сон системы.
9. Отключает ненужные службы (bluetooth, thunderbolt, служба обновления прошивок).
10. Вводит компьютер в домен.
11. Компилирует и устанавливает драйвер VHCI для перенаправления USB Horizon.
12. Компилирует и устанавливает драйвер V4L2Loopback для Horizon RTAV.
13. Устанавливает Horizon Agent с включенными функциями audio redirection, USB redirection и RTAV.
14. Включает SSO для Horizon.
15. Оптимизирует рабочий стол GNOME (отключает анимацию, устанавливает одноцветный фон рабочего стола).
16. Очищает историю bash.
17. Перезагружает виртуальный рабочий стол.

Как использовать

Установите гостевую ОС Ubuntu 18.04, 20.04 или 22.04 на виртуальную машину с настройками по умолчанию. При установке создайте учетную запись 'user'. Эта учетная запись будет использоваться для удаленного подключения от Ansible (если вы создали ее в момент установки системы, то ей автоматически будут выданы права sudoer для выполнения части оптимизаций в системе). Если вы используете другое имя пользователя, пожалуйста, измените шаги конфигурации и ansible.cfg соответствующим образом, и проверьте, что пользователь имеет права sudoer.

Установите сервер OpenSSH на виртуальный рабочий стол:

sudo apt get install openssh-server

Установите Ansible на отдельной рабочей станции / клиентском компьютере. При желании вы можете установить Ansible локально на сам виртуальный десктоп. В этом случае рекомендуется пропускать шаг перезагрузки десктопа после выполнения всех задач (см. раздел Тэги).

Для аутентификации и авторизации пользователя Ansible используются ssh ключи. Сгенерируйте ssh-ключ на вашей рабочей станции с настройками по умолчанию:

ssh-keygen

Скопируйте открытый ключ с рабочей станции на виртуальный рабочий стол:

ssh-copy-id -i ~/id_rsa.pub user@virtual_desktop_ip_address

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

Измените файл inventory, в разделе [ubuntu] укажите IP-адрес виртуального рабочего стола, а также измените необходимые переменные. Значение переменных описано в файле inventory.

Скачайте и поместите необходимые установочные архивы с пакетами vhci, v4l2loopback и Horizon Agent в папку files.

Запустите плейбук Ansible с помощью команды:

ansible-playbook --ask-become-pass optimize.yml

Тэги

Если вы хотите запустить только определенную оптимизацию, вы можете запустить ansible-playbook с параметром --tags "tag1, tag2, tag3". В настоящее время этот плейбук поддерживает теги:

• horizon - установить и настроить VMware Horizon Agent на виртуальном рабочем столе.
• domain - присоединиться к домену с параметрами, указанными в файлах инвентаризации.
• gnome - выполнить настройки и оптимизацию рабочего стола GNOME.
• reboot - перезагрузить виртуальный рабочий стол после завершения оптимизации.

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

ansible-playbook --ask-become-pass --tags "horizon, domain" optimize.yml

Переменные

Файл inventory содержит следующие переменные, необходимых для работы плейбука:

• horizon_agent - имя архива с дистрибутивом horizon_agent
• vhci_driver - имя архива с драйвером vhci
• v4l2loopback_driver - имя архива с драйвером v4l2loopback
• domain_name - имя домена для подключения
• domain_user - имя учетной записи для ввода в домен
• domain_password - пароль учетной записи для ввода в домен
• debug - установите в True для вывода расширенной информации от выполненных команд

Немного о блоге и Энциклопедия VMware

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

А пока я решил обобщить ту информацию, которую накопил за время работы в VMware, и сделать обзорный документ на GitHub по продуктам и решениям компании "Энциклопедия VMware".

Несмотря на прекращение продаж на территории России и Беларуси, технологии VMware остаются востребованными и у нас в стране, и у русскоязычных специалистов за рубежом.

Оговорюсь, что данное описание не покрывает ВСЕ доступные предложения компании и может содержать опечатки, неточности и устаревшую информацию, но как отправная точка вполне сгодится для новичков, которые хотят быстро погрузиться в тему и понять - что кроется за всеми этими многочисленными названиями.

VMware Horizon Recording FAQ

Часто меня спрашивают о том, как работает функция VMware Horizon Recording, и какие у нее есть ограничения, поэтому я решил подготовить FAQ по основным вопросам.

Что такое VMware Horizon Recording?

VMware Horizon Recording - это утилита, позволяющая записывать экран при подключении к удаленному рабочему столу VDI или терминальной сессии Horizon.

Ранее эта утилита называлась Horizon Session Recording и выпускалась в экспериментальном формате в виде Fling (https://flings.vmware.com/horizon-session-recording).

VMware Horizon Recording стал доступен в Horizon 2106 в качестве опционального модуля, включающего в себя агент (Recording Agent) и сервер записи (Recording Server). Агент устанавливается на виртуальный десктоп или терминальный сервер, захватывает изображение с экрана и передает его на сервер записи, где его можно посмотреть или загрузить для дальнейшего анализа.

Оптимизируем работу Horizon Blast на медленных каналах

Один из основных сценариев использования VDI - организация удаленной работы сотрудников. Но далеко не все пользователи VDI, работающие вне офиса или подключающиеся из других регионов, могут похвастаться качественным широкополосным доступом в Интернет. Часто пользователи подключаются к VDI через мобильных операторов, либо через местных провайдеров, а в нередких случаях и через спутник.

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

Настраиваем VMware Workstation для работы с контейнерами и кластерами Kubernetes

Если вы еще только осваиваете контейнеры и кластеры Kubernetes и ищете простой способ настроить для них тестовую инфраструктуру, то вам может пригодиться VMware Workstation Pro или Workstation Player, в которых начиная с 16 версии появилась поддержка контейнеров.

Механизм работы с контейнерами в Workstation похож на тот, что присутствует в vSphere with Tanzu. Для запуска контейнеров в Workstation используются легковесные ВМ CXR (Container Runtime for ESXi) внутри которых установлена Photon OS с containerd. Каждый контейнер запускается внутри отдельной ВМ, что, с одной стороны, требует дополнительных вычислительных ресурсов на хосте Workstation по сравнению с одной "большой" ВМ, с другой, обеспечивает лучшую изоляцию запускаемых приложений друг от друга, а также позволяет упростить настройку сети для контейнеров, поскольку каждая ВМ имеет уникальный адрес в виртуальной сети.

Помимо запуска контейнеров, вместе с Workstation идет Open Source инструмент Kind, который позволяет создавать кластеры Kubernetes внутри контейнеров.

В этой статье мы рассмотрим шаги по базовой настройке Kubernetes поверх Workstation, а также затронем вопросы по настройке сети для Pod'ов.

Установка Open Source Telegraf для vRealize Operations

Начиная с версии 8.0, в vRealize Operations добавили функцию мониторинга (Application and OS Monitoring) через UCP Telegraf агент. Данный агент устанавливается в гостевую ОС, собирает метрики с ОС и приложений и передает их в vROps. Хотя UCP Telegraf агент просто устанавливается и настраивается прямо из консоли vROps, он поддерживает довольно скромный набор метрик и приложений.

Поэтому в vROps 8.6, наряду с UCP Telegraf агентом, добавили поддержку Open Source Telegraf агента. Open Source Telegraf поддерживает большое число различных plugin'ов: https://docs.influxdata.com/telegraf/v1.20/plugins/. 

Это расширяет перечень сценариев использования vROps, позволяя мониторить ОС Windows или Linux внутри ВМ, работающих в vSphere или других гипервизорах, на физических серверах и даже в контейнерах.

В этой статье я рассмотрю пример установки и настройки OS Telegraf агента для гостевой ОС Windows.

Восстанавливаем работу OneDrive после VMware OS Optimization Tool

Всем администраторам VDI хорошо знакома утилита OSOT, позволяющая оптимизировать и ускорить ОС Windows. Но использовать её нужно с осторожностью, чтобы ненароком не отключить часть функций ОС, требующихся для работы.

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

Любая попытка переустановить OneDrive или сбросить настройки, используяю команду onedrive.exe /reset, не приводило ни к каким результатам.

Виновником как раз оказалась выполненная оптимизация Prevent the usage of OneDrive for file storage - Machine Policy, которая отвечает за управление групповой политикой Computer Configuration -> Administrative Templates -> Windows Components -> OneDrive -> Prevent the usage of OneDrive for file storage.

Для отключение настройки требуется установить значение групповой политики в Disabled или удалить параметр реестра  реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\OneDrive\DisableFileSyncNGSC

Кстати, внутри OSOT есть механизм History, позволяющий откатить некоторые ранее выполненные изменения (отключеные службы, изменения реестра и локальных групповых политик).

Архив конфигурации сохраняется в папке "C:\ProgramData\VMware\VMware Horizon OS Optimization Tool\Archive\" в папке с именем ВМ.

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

Автоматическая установка Horizon Client через PowerShell

Довольно часто для доступа к VDI инфраструктуре используются компьютеры под Windows с установленным клиентом Horizon Client.

Чтобы автоматизировать установку и обновление клиентов я сделал небольшой скрипт на PowerShell: https://github.com/omnimod/Install-HorizonClient/blob/main/Install-HorizonClient.ps1

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

• FilePath - Путь к установочному файлу Horizon Client. Если не указан, то скрипт попытается запустить исполняемый файл VMware-Horizon-Client-2106-8.3.0-18287501.exe из текущей директории.
• ArgumentList - Список параметров для запуска инсталлятора. По умолчанию используются параметры "ADDLOCAL=ALL /silent /norestart". Дополнительная информация по параметрам установки приведена в https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/2106/horizon-client-windows-installation/GUID-2DDF9C24-A1E9-4357-A832-2A5A19352D61.html 
• UpdateOldClients - Указывает, следует ли автоматически обновлять старые версии клиентов Horizon Client. По умолчанию установлен в $true.
• Logfile - Место расположение файла журнала, куда скрипт будет записывать отладочную информацию. По умолчанию используется C:\Windows\Temp\horizon-client-autoinstall-script.txt.

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

.\Install-HorizonClient.ps1 -FilePath "C:\Install\VMware-Horizon-Client-2106-8.3.0-18287501.exe"

Запускать скрипт можно как вручную на нескольких компьютерах сразу, например, с помощью Invoke-Command, так и через доменные групповые политики: Computer Configuration -> Policies -> Windows Settings -> Scripts (Startup/Shutdown).

VMworld 2021, какие сессии следует посетить?

До начала онлайн-конференции VMworld 2021 осталось меньше месяца, но у вас еще есть время, чтобы зарегистрироваться на мероприятие и выбрать сессии, которые стоит посетить.

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

Для себя я уже отметил несколько интересных сессий из каталога:

• VMware vSAN – Dynamic Volumes for Traditional and Modern Applications [MCL1084]
• 60 Minutes of Non-Uniform Memory Access (NUMA) 3rd Edition [MCL1853]
• vSAN Technical Deep Dive [MCL1654]
• Automate your Ops using vROps and REST APIs [VMTN3231]
• 99 problems but a snapshot’s not one! [VMTN3281]
• Securing Modern Apps with Tanzu Service Mesh [2944]
• Cool, DEM Integrated with UEM! A Deep Dive on How it Works and What it Delivers [VMTN2888]
• NSX-V to NSX-T Migration - Tools, Approaches and Lessons Learned [VMTN3292]
• Nerd Tours: A Tech Deep Dive of the VDI NerdFest 2021 Extravaganza [EUS3107]
• Extreme Performance Series: Performance Best Practices [MCL1635]

Для обладателей Tech+ Pass пропуска доступен расширенный набор сессий, из которых я выбрал:

• Accelerate and Optimize AI/ML with VMware vSphere and NVIDIA GPUs [VI1322]
• Create, Automate, and Optimize a Windows Image for Horizon [EUS1549]
• Take Your Windows Deployment to the Next Level [EUS1335]
• Getting Started with NSX Infrastructure as Code [NET2272]
• Get Close to 100% Automation to Get to True Cloud Operations at Scale [MCL2023]

Еще один стимул посетить мероприятие - как и в прошлом году среди участников разыгрываются ценные призы, например, в 2020 можно было получить лимитированный рюкзак или футболку.

Летняя Академия VMware 2021

Открылась регистрация на серию вебинаров VMware "Летняя Академия 2021": https://via.vmw.com/EVD9 

Всего планируется провести вебинары по шести различным темам, включая End-User Computing, Multi-Cloud, Modern Apps и Virtual Cloud Network.

На освещение каждой темы выделяется два дня (два семинара по 2 - 2.5 часа). В этом году планируется немного поэкспериментировать с форматом, помимо выступлений с презентациями на Летней Академии будут показываться демо по работе с продуктами, а также проводиться интервью с сотрудниками глобального офиса VMware, заказчиками и партнерами.

Участие в мероприятии бесплатное для всех желающих, достаточно только зарегистрироваться по ссылке: https://via.vmw.com/EVD9

Нюансы подготовки NSX Advanced Load Balancer для vSphere with Tanzu

Начиная с 7.0 U2, при развертывании инфраструктуры контейнеров Tanzu появилась возможность использовать балансировщик VMware NSX Advanced Load Balancer (он же AVI Vantage). NSX ALB предоставляет множество продвинутых функций по сравнению с HAProxy, включая автоматическое развертывание балансировщиков Service Engine, их настройку и обновление, поддержку работы в HA режиме и Active-Active конфигурации, управление через GUI, CLI, Rest API, ведение детальной статистики подключений и многое другое.

Процесс настройки NSX ALB для работы с Tanzu имеет несколько нюансов, которыми я бы хотел с вами поделиться.

Смена редакции Advanced Load Balancer

NSX Advanced Load Balancer доступен в трех редакциях: Essentials, Basic и Enterprise. Редакция Essentials не требует покупки доп.лицензии и доступна в рамках подписки Tanzu Basic и Tanzu Standard. Сравнение редакций приведено на сайте: https://avinetworks.com/docs/20.1/nsx-license-editions/

При развертывании NSX Advanced Load Balancer автоматически активируется триальная Enterprise версия сроком на 1 месяц.

Если вы не планируете покупать редакцию Basic или Enterprise, то перед развертыванием Tanzu рекомендуется поменять редакцию на AVI Controller, чтобы избежать необходимости перенастраивать уже работающую систему. Сделать это можно из командной строки.

Для этого подключитесь к одному из контроллеров по SSH и войдите в систему под учетной записью admin. С помощью команды shell активируйте командную строку для управления балансировщиком.

Проверьте совместимость текущей конфигурации AVI с редакцией Essentials:

show configuration audit tier essentials

Если конфигурация несовместима, команда выдаст перечень настроек, которые потребуется изменить.

Для смены редакции выполните команды:

configure systemconfiguration

default_license_tier essentials

save

Дополнительная информация приведена в статье: https://avinetworks.com/docs/20.1/nsx-essentials-for-tanzu/

Замена сертификата

Перед развертыванием vSphere with Tanzu потребуется заменить самоподписанный сертификат на AVI Controller'ах.

В версиях AVI 20.1.4 и 20.1.5 есть баг, который не позволяет менять сертификат через GUI после смены редакции на Essentials (или менять редакцию, если вы уже заменили сертификат). Чтобы исправить ситуацию потребуется установить обновление 20.1.5-2p1 или выше.

Если вы установили AVI версии 20.1.5, то все что нужно будет сделать, это загрузить пакет обновления avi_patch-20.1.5-2p1-9017.pkg с сайта AVI. Если у вас установлена более старая версия, то предварительно потребуется обновить AVI до версии 20.1.5 с помощью пакета avi_patch-20.1.5-2p1-9017.pkg.

Установка обновлений выполняется из GUI. Загрузите пакет обновления на контроллер: Administration -> Controller -> Software -> Upload From Computer. Затем выберите и установите обновление Administration -> Controller -> System Update.

После установки обновлений откройте доступа к контроллерам: Administration -> Settings -> Access Settings -> 🖉.

В поле SSL/TLS Certificate удалите сертификаты указанные по умолчанию и в выпадающем списке выберите Create Certificate. Создайте новый сертификат, указав в полях Common Name и Subject Alternate Name (SAN) IP-адрес контроллера или Controller Cluster IP, если вы развернули контроллеры в отказоустойчивой конфигурации. Выберите тип Self Signed - если хотите, чтобы контроллер сам сгенерировал самоподписанный сертификат, либо создайте CSR запрос, если планируете подписать сертификат доверенным УЦ.

Планирование IP адресации при развертывании Tanzu

При развертывании Tanzu используется несколько типов сетей:

• Management Network сеть, к которой подключаются Supervisor Control Plane VM (должно быть зарезервировано не менее 5 IP адресов, три из которых назначаются трем ВМ, один используется в качестве VIP адреса для взаимодействия с кластером супервизоров, и еще один используется для Rollout обновлений супервизоров). Также к этой сети подключаются management интерфейсы для управления балансировщиками Service Engine. Опционально в этой сети могут размещаться другие серверы и служебные ВМ: vCenter Server, VMKernel интерфейсы ESXi, AVI Controller'ы и пр.
• Одна или несколько Workload Network сетей, к которым подключаются Supervisor Control Plane VM, а также ВМ с ролями Master и Worker Node кластеров TKG Cluster. 3 IP адреса из Workload сети выделяются Supervisor Control Plane VM плюс по одному адресу для каждого узла Master и Worker Node в TKG Cluster'е.
• Frontend Network или Data Network сеть, где размещаются VIP для балансируемых сервисов, используемые для подключения к кластерам Kubernetes.

Если вы планируете развернуть стандартную инсталляцию Tanzu в соответствии с официальной документацией VMware, то каждый балансировщик Service Engine будет подключаться к двумя сетям: Management и Frontend.

Настройка диапазона адресов для Management и Frontend сетей, из которых будут выделяться IP адреса для Service Engine и VIP, выполняется на вкладке Infrastructure -> Networks.

Важно, эти диапазоны адресов НЕ должны пересекаться с адресами, выделенными для Supervisor Control Plane VM и TKG Cluster'ов, которые вы указываете в мастере настройки Workload Management.

Выбор Frontend сети AVI контроллером осуществляется с помощью IPAM профиля. Для создания профиля в интерфейсе AVI выберите Templates -> Profiles -> IPAM/DNS Profiles -> CREATE -> IPAM Profile. Задайте произвольные имя профиля, укажите инфраструктуру и сеть, из которой будут автоматически выделяться адреса для VIP.

После создания назначьте IPAM профиль на инфраструктуру vSphere, в которой будут создаваться Service Engine: Infrastructure -> Clouds -> Default-Cloud -> 🖉 -> IPAM Profile.

Также требуется настроить статическую маршрутизацию для Service Engine, чтобы они могли принимать и перенаправлять запросы для балансируемых сервисов при обращении из других подсетей. Сделать это можно из Infrastructure -> Routing -> Static Route -> CREATE. Укажите Default Gateway, который используется во Frontend сети.

После подготовки NSX ALB можно запускать мастер настройки Workload Management.

Обновляем HAProxy для vSphere with Tanzu

С момента появления в конце 2020 поддержки балансировщика HAProxy в vSphere with Tanzu, для него успело выйти несколько обновлений.

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

Учтите, что обновление потребует небольшого простоя, поэтому лучше запланируйте данную процедуру на нерабочее время.

Перед обновлением загрузите актуальную версию HAProxy с Github: https://github.com/haproxytech/vmware-haproxy#download

Подключитесь к существующей инсталляции HAProxy по ssh и скопируйте файлы сертификатов из каталога /etc/haproxy:

• ca.crt
• ca.key
• ca.srl
• server.crt
• server.key

Опционально скопируйте также файлы конфигурации dataplaneapi.cfg и haproxy.cfg, если вы вручную вносили в них какие-либо изменения.

В консоли vSphere Client выберите ВМ с HAProxy, откройте вкладку vApp Options (Configure -> vApp Options) и запишите все настройки (Properties), которые задавались при развертывании исходного балансировщика.

Разверните новый экземпляр балансировщика из OVA шаблона с новым именем ВМ. Остальные настройки оставьте такими же, как и у старого балансировщика.

Выключите старую ВМ и запустите ВМ с новой версией HAProxy.

Подключитесь к новому балансировщику по ssh и остановите сервисы HAProxy и dataplaneapi:

systemctl stop haproxy

systemctl stop dataplaneapi

Замените файлы в каталоге /etc/haproxy на те, что вы скопировали со старого балансировщика. Запустите сервисы:

systemctl start dataplaneapi

systemctl start haproxy

В течение пары минут Supervisor Controlplane VM должен будет подключиться к новому балансировщику и обновить конфигурацию файла haproxy.cfg, добавив туда информацию о балансируемых сервисах.

Проверьте, что балансировщик работает корректно, подключившись к supervisor кластеру.

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

Серия весенний вебинаров от VMware Russia

С 16 марта 2021 стартует серия весенних вебинаров от компании VMware. Всего планируется провести порядка 30 сессий, посвященных как хорошо знакомым продуктам и решениям вроде vSphere, Horizon, vSAN и NSX, так и новым темам, таким как: безопасность, контейнеры.

Регистрация доступна по ссылке: https://via.vmw.com/EQ21

Для записи заполните два небольших опросника (ЧАСТЬ 1 и ЧАСТЬ 2) в верхней части экрана.

Для анонса мероприятий Михаил Михеев - сотрудник VMware, создатель vm4.ru и автор книги "Администрирование VMware vSphere 5" записал небольшое видеообращение.