TL;DR: у ALT Linux отсутствует ova для p11, а тот, что есть в p10 мало того, что здоровенный (1.5G? зачем столько?), так ещё и не работает.

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

Disclamer: я знаю про terraform и packer, они использованы не будут. Причины не технические и выходят за рамки заметки. Я понимаю, что по хорошему стоило бы оформить всё это в скрипт, к сожалению, я этого не сделал. Sad, but true.

Начнём с простого — что я собираюсь делать и почему именно так.

мне нужен template в формате ova, чтобы можно было разворачивать виртуальные машины, кастомизируя их через cloud-init.
Данные для cloud-init будут подтягиваться по https во время установки.
Настройку сети будут обеспечивать VMWare tools.
поскольку мне нужен образ минимального размера, как основу я буду использовать JeOS.
так как VMWare tools не имеют ни малейшего понятия о системе Etcnet, используемой в ALT Linux, вместо неё я поставлю Netplan (потому что он мне нравится).
ну и, наконец, поскольку VMWare tools настраивают сеть через Netplan, если видят, что используется Debian/Ubuntu, то я добавлю костылей, благодаря которым во время установки образ будет прикидываться Ubuntu, а во время отработки cloud-init, костыли будут удалены (неочевидный плюс — если после разворачивания ВМ в консоли написано Ubuntu — значит что-то пошло не так. А если ALT Linux — скорее всего всё сработало как надо).

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

создаём отдельный vApp, а в нём ВМ, которую и будем кастомизировать.
качаем iso JeOS, грузимся с него, тип гостевой ОС я выбираю "Other 5.x or later Linux (64-bit)", потому что ALT Linux явно не относится ни к семейству Debian, ни к подвиду RHEL.
Размер диска я ставлю 10G, потому что с моей точки зрения для системного диска этого достаточно.
Размечаю диск (просто делаю /dev/vda1 для корня и всё. Если понадобится swap — всегда можно подключить его позже).
Ну и, собственно, всё.
сначала я воспользовался статьёй «JeOS VM noDHCP» и настроил сеть согласно её рекомендациям, но практика показала, что делать так не стоит.
Мы же всё равно собираемся использовать Netplan, так зачем делать двойную работу?
Поэтому берём и прямо руками поднимаем сеть:
```
ip a add 192.168.10.10/24 dev ens192
ip l set ens192 up
ip r add default via 192.168.10.1
echo 'nameserver 1.1.1.1' > /etc/resolv/conf
```
статья, тем не менее, полезная, как вы можете заметить, часть команд я из неё утащил.

включаем сервер ssh, заходим под root

systemctl enable sshd
vi /etc/openssh/sshd_config
systemctl restart sshd

обновляем систему и ядро до актуальных, набор софта выбираем по вкусу.
```
apt-get update && apt-get dist-upgrade
apt-get install update-kernel open-vm-tools sudo nano vim-console unzip zstd htop tmux bash-completion-util-linux
systemctl enable vmtoolsd
apt-get clean && reboot
update-kernel
apt-get clean && reboot
remove-old-kernels
```
отдельно отмечу, что очень рекомендую сразу настроить sudo (там по умолчанию дефолтный конфиг, в котором всё отключено) и обязательно поставить ca-certificates (столкнулся с тем, что cloud-init не подтягивали данные, т.к. считали сертификат от Digicert самоподписанным)

ставим netplan и отключаем Etcnet

apt-get install netplan systemd-networkd
systemctl disable --now network

ставим cloud-init и включаем сервисы

apt-get install cloud-init
systemctl enable cloud-init.service cloud-init-local.service cloud-config.service cloud-final.service

добавляем костыли, которые я обещал в самом начале:
```
rm -f /etc/system-release /etc/redhat-release /etc/fedora-release
mv -f /etc/os-release /etc/os-release.alt
echo 'Ubuntu 22.04.5 LTS \n \l' > /etc/issue; echo >> /etc/issue
cat << EOF > /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
EOF
```
теперь пара слов о том — что здесь происходит.
нам нужно, чтобы созданная из этого тимплейта ВМ автоматически получала IP-адрес, который ей выдаст VMWare. Для этого у нас установлены open-vm-tools.
Проблема в том, что open-vm-tools понятия не имеют о существовании ALT Linux (здесь надо отметить, что соответствующий issue в репозитории open-vm-tools есть, но движения по нему пока нет).
open-vm-tools, чтобы настроить сеть, пытаются определить — что за дистрибутив линукса используется. И, чтобы настроить сеть через netplan, нужно прикинуться Debian-based дистрибутивом (выше я прописываю строки от Ubuntu просто потому что она была у меня под рукой).
Честно говоря, я бы предпочёл менее костыльный способ, но я его не нашёл.
Если кто-то знает — подскажите, буду благодарен.
Вносим дополнительные правки в конфиги (если в этом есть необходимость) и выключаем ВМ.
Подготовка почти завершена.
Почти — потому что теперь нужно в VMWare в свойствах ВМ войти в "Guest OS Customization" и включить, что характерно, "Enable guest customization".
проверяем, что наш vApp находится в выключенном состоянии и скачиваем его.
Actions — Download.
получаем ova-файл. Подготовка завершена, приступаем.

Для начала — что такое ova-файл?
Это обычный tar-архив, который содержит в себе три файла:
vmdk — образ диска нашей ВМ
ovf — как подсказывает нам википедия, открытый стандарт для хранения и распространения виртуальных машин
mf — файл с контрольными суммами файлов vmdk и ovf

Нам потребуется подготовить vmdk и создать новый ovf, который и будет делать то, что мне нужно (разумеется, я не писал его с нуля, а взял готовый от cloud-image ubuntu, после чего творчески его доработал). После чего нашёл проект debian-ova-creator, в котором то, что я сейчас описываю, завёрнуто в скрипт : ))
К сожалению, нашёл я его уже после того, как подготовил образ, поэтому я поленился адаптировать его для моей задачи.

итак:

# распаковываем скачанный из vApp ova-файл
tar xvf vmware-alt-template.ova
# преобразуем его в streamOptimized
qemu-img convert -f vmdk -O vmdk -o subformat=streamOptimized vmware-alt-template.vmdk alt-p11-cloud.vmdk
# скачиваем образец ovf
wget https://raw.githubusercontent.com/strannick-ru/alt-linux-ovf/refs/heads/main/alt-p11-cloud.ovf

как видим, наш ovf — это обычный xml
на что обратить внимание:

<File ovf:href="alt-p11-cloud.vmdk" ovf:id="file1" ovf:size="872791552"> — первое поле, имя нашего vmdk, второе — id, используйте любой, третье — размер файла vmdk в байтах, можно посмотреть обычным ls -l alt-p11-cloud.vmdk

<Disk ovf:capacity="10737418240"… — размер диска ВМ в байтах. Узнать тоже просто, qemu-img info alt-p11-cloud.vmdk | grep 'virtual size'

<VirtualSystem ovf:id="alt-p11-cloud-20250130"> <Name>alt-p11-cloud-20250204</Name>— название template, которое будет использовать VMWare после импорта.

<OperatingSystemSection ovf:id="101" vmw:osType="other5xLinux64Guest"> — id для типа гостевой ОС "Other 5.x or later Linux (64-bit)"

на этом месте отмечу, что если бы у VMWare была нормальная документация, то я мог бы не писать это всё. Но, либо я не умею искать (что, кстати, не исключено), либо VMWare зачем-то тщательно прячет данные о том же ovf:id, который мне пришлось откапывать в самых странных местах

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

запаковываем всё обратно в ova:

sha256sum --tag alt-p11-cloud.vmdk alt-p11-cloud.ovf > alt-p11-cloud.mf
tar cf alt-p11-cloud.ova alt-p11-cloud.vmdk alt-p11-cloud.ovf alt-p11-cloud.mf

и заливаем полученный alt-p11-cloud.ova в VMWare.

остался последний этап.
подготовим файл user-data и выложим его на наш веб-сервер, чтобы он был доступен по адресу vmalt.example.net/user-data (http или https — на ваше усмотрение).
имя домена роли не играет.

для примера я приведу свой.
как видите, в нём всё довольно стандартно — создаём пользователя, доустанавливаем пакеты, меняем пароль root.
и удаляем костыли, которые мы заботливо расставили при создании образа.

Финальный вопрос — а зачем всё это?
Ответ — вот ради такого:

создание новой ВМ из cloud-image в VMWare

т.е. буквально — выбрали при создании наш образ, прописали для него IP, опционально — прописали URL, откуда брать user-data (опционально — потому что можно и нужно прописать вариант по умолчанию) — и всё, ВМ выкатится.

Что хочется сказать (снова).
VMWare, с моей т.з., крайне неудобна как облачный провайдер.
Именно потому, что для банальных, в сущности, вещей приходится городить костыли и велосипеды.

Но работать можно и с ней.

P.S. надеюсь, команда ALT Linux всё-таки сделает свой вариант cloud-image для VMWare Cloud Director.

Создаём cloud-image ALT Linux для VMWare Cloud Director