Обнаружил тут, что не существует удобного 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)

This entry was originally posted at http://vitus-wagner.dreamwidth.org/1106342.html. Please comment there using OpenID. Now there are comments