Система доставки и эксплуатации виртуалок

Постановка задачи

1. Имеется несколько классов с компьютерами, чья мощность достаточна для запуска минимум одной виртуальной машины
2. Виртуальные машины (далее VE) запускаются путём выбора из образов, которые заранее разложены на компьютеры (возможно, для разных классов разные)
   • VE могут быть с сохранением состояния: после перезагрузки, в т. ч. хост-системы остаются проделанные изменения в гостевой системы

   • VE могут быть без сохранения состояния: после выключения гостевой системы все изменения в ней пропадают

   • Хост-система должна аутентифицировать пользователя
   • В гостевые системы может потребоваться пробрасывать персональные каталоги пользователей и/или подходящие файлопомойки
   • Гостевые системы бывают, как минимум, Linux-based и Windows8
3. Образы подготавливаются заранее (администратором или преподавателем) и заливаются на все подходящие машины

Структура

1. рабочее место администратора
2. torrent-сервер
3. сервер разделяемых каталогов
4. (?) сервер сетевой загрузки
5. Хост-машина

Рабочее место админа

• Задачи
  • приём и подготовка образов
  • выкладывание образов
• Как работает сейчас
  • Сейчас используется голый образ диска .vdi, который потом вручную обмазывается конфигом

  • Клиентский работающий VDI-образ конвертируется в RO, есть проблемы автоматизации для VB

• Как планируется делать
  • (Перейти на .ova/.ovf)

    • FrBrGeorge утверждает, что .ov[af] отлично импортируется в VirtualBox, при этом все хост-специфичные подробности конфигов меняются на специфичные для target-хоста

  • Сконвертировать в RO-образ
  • Запаковать в торрент и положить на торрент-сервер

Torrent-сервер

• Задачи
  • отдача подкаталогов с виртуалками
  • отдача плееров, репозиторий центрального управления

  • для VirtualBox: раздача конфигов.

    • FrBrGeorge что это, поясните!

• как работает сейчас и что не так

  • TODO (если длинный текст, лучше сделать подстраницу)

• Как должно работать
  • Образы: Torrent client+torrent tracker

    • формат образа

  • torrent client настроен таким образом, что не даёт скачать с себя много, после отдачи 2x объёма (каждого блока минимум дважды) пускай клиенты друг у друга тянут (защита от request storm).
    • возможно стоит больше, чем 2x, на случай если оба клиента, скачавшие некий блок, будут преждевременно выключены пользователем, например.
  • Иногда классы качают не одновременно, а сервер мог отдать 2х в другой класс, который сейчас выключен, поэтому cподручнее не переставать раздавать, а выжидать академическую пару. Также у админа должна быть возможность оперативно включить раздачу насильно (на совсем чёрный день). Такой режим ещё называют super-seed.
  • клиенты должны репортить, когда скачали образ, чтобы можно было централизованно наблюдать, кто обновился, а кто нет.

Прошивка

• Задачи
  • Поиск и запуск плеера по умолчанию (собственно, хост-системы)
  • Ручной выбор другого плеера (если есть)
  • Выбор другого плеера по общей команде из сети
  • По команде из сети делать дефолтным другой плеер
• Как должно работать
  • Прошивка грузится
  • Находит все имеющиеся на диске образа плеера
    • Если сеть есть: лезет по сети на сервер, видит там, какая версия считается актуальной, записывает себе на будущее
  • Показывает меню выбора плеера. если юзер не выбрал, то версия по умолчанию (из предыдущего пункта)
  • Запускает плеер
    • Зависит от того, в каком виде упакован плеер

    • 

TODO разобрать

Плеер (ОС машин в классах)

Задачи

• Запуск виртуалок из образов
• Хранение и обновление образов
• (на будущее) изготовление новых образов
• Всё вышеописанное — независимо от используемого гипервизора.

• Нужна возможность централизованной автоматической конфигурации классов.

• Скачивание по команде из сети свежих версий образов виртуалок и плеера (если идем по пути ro-образов)

Как распространяется на машины

Несколько путей с преимуществами и недостатками:

• Использовать раздел на диске (как сейчас) и размножать его Clonezilla.
  • Минус: неудобно заменять хост-систему, но часто ли это необходимо?
  • Сейчас так на машину попадает первоначальная копия системы.
• Использовать раздел на диске (как сейчас) и распаковывать туда файлы.
  • Можно комбинировать с предыдущим (сейчас классы ровно так и тюнингуются по требованию)
  • Достоинство: простота устройства — система отлаживается на dev-машине (например, та, что в 762), файлы уходят на сервер, оттуда распаковываются на клиенты.
  • Недостаток — необходимо прикрутить контроль версий либо на уровне ФС (zfs? btrfs? у них свои недостатки, возможно, преувеличенные), либо использовать какой-нибудь rsync в транзакционном режиме. Сложно доказать отказоустойчивость.
  • Интересное наблюдение: с одной стороны, сейчас конфигурация (/etc/*) так и подкладывается (переносится tar-архив), с другой стороны некоторые выступают против wget -O- | tar -xf -.
• Использовать ro-образы систем.
  • Преимущество — полный контроль над состоянием машины и транзакционность.
    • Образы (как плееров, так и виртуалок) лежат на локальном хранилище.
    • Свежие образы систем можно хранить как поблочную разницу с предыдущим
  • Пути решения:
    • squashfs-root + kernel + custom initrd
    • iso-образ, подобный образу загрузочного CD/USB
  • Недостаток: сложно администрировать, готовое к деплою решение есть только в Альте, в других linux-системах задача решена частично как недостаточно ценная.

Как работает

Для заливки используется торрент, т. к. это помогает избежать request storm

• синхронизует все торрент-файлы с условленным местом
  • (на будущее) это место может для разных классов быть разным
• торрентом скачивает сам образ
• когда торрент готов:
  • разрегистрирует удалённые виртуалки
  • регистрирует виртуалку
  • обновляет меню образов
  • продолжает раздавать соседям (да и в другие классы)
• (?) авторизует пользователей, монтирует home
  • по опыту, проброс папки из хоста через VB shared folder в гостевой юникс к добру не всегда приводит;
• предлагает меню образов и запускает соотв. виртуалку с подкладыванием RW-дифференшиал поверх RO-исходного образа
• дифференшиал это временный, удаляется, например, при обновлении образа или при перезагрузке (можно вынести в опцию, спрятать в отдельное меню и менять поведение для пары юзер-машина)
• (на будущее) в отдельном меню позволяет из RO+differential сделать новый RO
• ?? как потом этот образ забирать? Множество способов, все одинаково подходят. Например, уведомлять администратора по почте, что на машине M в классе N лежит свежий образ V от преподавателя ABC.

Гостевая виртуалка

Задачи

• отлично работает, импортируется, и ничего уныло хакать не надо, что нужно преподу — софт, какая-то сеть и т. п.

Как работает

• Нужен какой-то стандарт на оформление настроек виртуалки, чтобы она из коробки сразу работала (вообще-то так и должно, но мало ли)
  • Выполняет ли эту задачу OVF? Проверить.

    • Преимущество OVF в том, что с ним дружат все гипервизоры в какой-либо мере, и готовить образ можно в том же VirtualBox.

• Нужно договориться, что делать с сетью.
  • ??? Сеть везде из коробки работает. Есть специфические запросы (например, проброс портов), с ними каждый раз надо решать новую проблему каждого препода (пока только один такой случай был — ВМШ)

TODO

• Другие не-VB гипервизоры: qemu{,-kvm}, xen
  • Ни тот, ни другой не проверялись на актуальном железе классов.
  • qemu успешно 100% раз запускается на личной машинке 5-летней давности, визуально не лагает, позволяет работать с типовыми учебными приложениями, собирать код на сях. Тестировался стартеркит Alt p8 со средой MATE и дебиан 8 с XFCE.
  • Преимущество qemu - простая архитектура управления, которая не мешает админу. Вся конфигурация виртуалки выразима в опциях командной строки, никаких служебных избыточных БД, никаких внезапных изменений прав. Нечему ломаться, кроме багов гипервизора и гостя.