Журнал Витуса

Обнаружил тут, что не существует удобного GUI для QEMU/KVM.
Есть virt-manager, но он во-первых, требует громоздких библиотек и демонов, да еще и слинкованных со всякими гадостями вроде policykit, во-вторых со снапшотами нифига работать не умеет, в третьих отказывается запускать виртуальную машину, если не находит USB-девайса который был к машине подключен в предыдущий раз.

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

Есть aqemu, но я вообще не понял какую задачу решщали авторы этой софтины. Там есть довольно развесистое управление созданием VM, но нет управления работой, что как раз гораздо важнее. Поскольку машина создается единожды, а работает годами.

Соответственно, возникла мысль написать свою управлялку. Благо развесить по менюшкам посылание команд в монитор qemu и приделать парсинг ответов, несложно. Такой тонкий-тонкий слой, который делает несколько полезных вещей удобными, не мешая делать все остальные имеющимися способами.

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

1. Поддерживать ли работу VM в бэкграунде? Ну то есть большую часть моих случаев покрывает режим, подобный VMWare Workstation - запускаем vm в рамках сессии, что-то с ней делаем, а потом шатдауним. Для этого подойдет режим -video sdl -monitor stdout. С него и надо начинать, как с самого простого.

Но иногда хочется иметь виртуальные машины, работа которых не прекращается с закрытием окна. Стоит ли возиться с монитором по tcp и vnc-дисплеем (кстати, по-моему использование vnc и spice дисплеи, единственный способ сделать, чтобы мышь спокойно пересекала границы окна виртуального экрана).

Или оставить это большим и толстым серверным системам виртуализации - proxmox, libvirtd etc?

Кстати spice отдельно от libvirt бывает?

2. Очевидно, что следует поддерживать операции управления питанием system_powerdown, system_reset, system_wakeup. (кстати, не нашел в документации действия, обратного к system_wakeup - подниматься из саспенда мы умеем, а попадать в него как?)

Не менее очевидно, что нужно уметь управлять removable устройствами - из-за этого проблема и возникла. usb_add/usb_del, eject, change diskdevice filename, Причин возиться с параллельными-последовательными портами и мышами-планшетами я пока не вижу. Хотя команд для управления ими в мониторе море.

3. Хорошо бы поддержать работу со снапшотами. Но для этого надо понять как она там делается.
В принципе мне бы хватило обертки вокруг qemu-img -b. Вообще про снапшоты написано много букв здесь и здесь.

Насколько я понимаю, основная задача под которую дизайнились эти снапшоты (управляемые через монитор) - бэкап работающей виртуальной машины, мне не слишком актуальна.

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

Потому что, как мы знаем, кнопка revert to snapshot - лучший антивирус.

4. В управление сетевыми устройствами и организацию виртуальных локальных сетей лезть не хочется. Для меня это не слишком актуальная задача, а наработок там много. Поскольку основной дизайн-идеей будет "если что-то можно сделать через параметры командной строки qemu, это по-прежнему можно сделать с аналогичным ситаксисом" я лучше сеть не буду трогать совсем. Хотя использование эмулятора, умеющего разные процессоры открывает интересные перспективны. Например запуска каких нибудь сборок конкретных OpenWRT под qemu-system-mips в качестве роутера виртуальной сети. Но вот пусть кому это надо, тот это и дописывает.

5. Формат файла описания виртуальной машины. Боюсь что без него обойтись нельзя. Пробрасывать все опции командной строки в запускаемый qemu и использовать в качестве файла конфигурации скрипт, вызывающий мой gui, как сделано в qemuctl, конечно, можно, но чем-то мне эта идея не нравится.

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

qemu `cat filename.vm`

запускала эту виртуальную машину без посредства нашего GUI. C дефолтным видео и дефолтным монитором, а все остальное точно так же.

Кстати, с таким форматом файлов, мы можем задачу GUI для создания виртуальных машин не решать совсем. Хотя написать простенький визард на уровне того же virt-manager-а - занятие на пару часов.

Upd Совсем забыл: 6. Отправка в виртуальную машину клавиш, которые родная GUI-среда хоста злобно перехватывает и к приложению не пропускает (Ctrl-Alt-F?, Ctrl-Alt-Backspace, Ctrl-Alt-Del)

Эксперименты показали, что в качестве дисплея надо использовать spice. Потому что clipboard sharing это сильно.
Ради этого стоит потерпеть и то, что при отсутствии в guest-системе соответствующих тулзов курсор будет ей захватываться и без нажатия специальной комбинации клавиш не отпускаться (у SDL такое поведение просто неотключаемо, а у VNC его нет вообще).

Правда, если использовать spice, писать придется на python с использованеием gtk для gui.

Был бы VNC, можно было бы на tcl/tk писать, tk widget vnc-viewer-а бывает. Правда, с другой стороны, разные реализации VNC очень сильно отличаются по производительности, и есть подозрение что у Кристиана Вернера - не самая быстрая и не самая фичастая.

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

Возникает идея - монитор цеплять к unix-domain-сокету, имя которого в файловой системе как-то тесно связано с именем машины (либо имеется общесистемная директория с этими сокетами, либо в директории где лежат все файлы виртуальной машины, имеется сокет monitor). Это соглашение, кстати, позволит иметь параллельный интерфейс для управления машинами из командной строки. Уж по крайней мере, system_powerdown туда сказать из скрипта всяко можно будет.

Соответственно, при желании присоединиться к работающей машине, мы коннектимся к ее монитору, лочим его (если не смогли - значит там кто-то другой уже работает), а потом спрашиваем у qemu на каком порту он ждет в гости spice/vnc клиента. Благо рассказать он об этом умеет. В принципе, конечно, tcp-порт монитора можно из файла конфигурации машины вычитывать. Но тогда придется его там хранить, а значит - оперативно редактировать этот файл конфигурации, если этот порт вдруг оказался занят. Впрочем, при создании снапшотов его все равно редактировать.

Интерфейс должен выглядеть как в левой полосе - элементы управления, а основное поле - экран гостевой системы.
Элементы управления сверху вниз removable диски, usb-устройства, снапшоты, а в самом низу кнопкки shutdown/reboot/etc. Над ними - окошко консоли монитора.
По верху окна вместо меню кнопки клавиш, которые можно туда послать.

Это если мы запустились с параметром "имя машины".

Если без него - то предлагаются варианты "открыть машину"/"создать машину".
При создании машины предлагается всего два варианта сети на выбор - подключиться к существующему бриджу или использовать user networking.

При подключении устройств и дисков должна быть предусмотрена опция "персистентное подклчение". В смысле пытаться при следующем запуске это устройство подключить обратно.

При закрытии GUI у нас должны быть варианты выбора - shudown, suspend, background.