Уточненное ТЗ по qemu GUI

[vitus_wagner]

Эксперименты показали, что в качестве дисплея надо использовать 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.

Comments

[balu]

>clipboard sharing
От, кстати, да. Привык к нему в ВБ и не заметил его отсутствия на Qemu. Вы смотрели на коммерческую версию ВБ? Может еще что найдете, что захочется внедрить?

[vitus_wagner]

Ну почему же нет, когда при использовании Spice он есть?

Из коммерческих эмуляторов я использую VMWare. И собственно, именно ее функциональность (workstation или player) хочу воспроизвести, только без проприетарных ядерных модулей. Потому что с ними заколебешься - запускаешь виртуальную машину, и тут выясняется что у тебя ядро проапгрейдилось и эти модули больше не собираются.

Поэтому я ориентируюсь на kvm и lxc - у них все проапгрейтится вместе с ядром.

[balu]

Я не знаю, что это такое. И, главное, он интегрирован в qemu или опционален?

[vitus_wagner]

Кто это? kvm это Kernel Virtual Machine, ядерный драйвер позволяющпй выполнять код гостевой системы прямо на хостовом процессоре, если тот поддерживает аппаратную виртуализацию. Нынче еще надо поискать не то что десктоп - ноутбук, который ее не поддерживает.

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

lxc - это Linux Containers, вещь от QEMU совершенно отдельная, но крайне полезная, поскольку контейнеры куда менее прожорливы, чем виртуальные машины.

В результате у меня сейчас на ноутбуке есть три контейрера, и вместе с хостсистемой получаается матрица - два дистрибутива - jessie и wheezy и две архитектуры - i386 и amd64. А kvm-виртуальная машина всего одна, с виндой-семеркой.

Будет настроение - поставлю еще парочку - с FreeBSD и Solaris-ом.

[balu]

Про kvm я знаю, а про Spice - нет.

[vitus_wagner]

А вот. Оказывается есть у QEMU/KVM такой проткол доступа к виртуальной машине.

Умеет кроме клавиатуры/мыши/графики еще как минимум аудио, а также если немножко потрахаться с пересборкой клиента - и смарткарты. Вроде как даже умеет 3d-графику в каких-то объемах.

В общем, существенно интереснее VNC. В QEMU поддержка встроена. Правда, нужно три строчки опций командной строки указать. И это не считая тех, которые нужны для пробрасывания с клиента USB-устройств (с этим я еще не разобрался).

Cуществует Xspice, сервер, позволяющий ходить по этому протоколу к физическим машинам.

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

[balu]

спасибо, буду знать. Собственно, Spice можно использовать, как замену VNC?

[vitus_wagner]

Для работы с виртуальными машинами QEMU/KVM- точно можно. При этом получаются такие полезные плюшки, которых, насколько я знаю, нет в большинстве реализаций VNC, как clipoard sharing, проброс аудио, проброс USB-устройств.

Что из этого будет работать с Xspice, в смысле при доступе к физической машине по SPICE - не проверял.

[balu]

Просто интересно в качестве замены VNC и терминального решения, когда иксы дропнут

[vitus_wagner]

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

[prividen.livejournal.com]

"При создании машины предлагается всего два варианта сети на выбор - подключиться к существующему бриджу или использовать user networking." - эхехе, прям как у меня было до наконец-то перехода на libvirt, вспомню-вздрогну ;)

Кстати, а что за машинки планируется виртуализировать и зачем к их консоли подключаться? А то на практике как-то удобней бывает цепляться к гостю через ssh/rdp/Xvnc/Xspice.

[vitus_wagner]

Предполагается опенсурсный аналог vmware workstation - инструмент для разработчика кроссплатформных программ. Ну и иногда бывает нужно запустить приложение для более другой операционной системы. Например, для всего инструментария работы с SIM-картами линуксового аналога нет. А пробросит кардидер в KVM - никаких вопросов. Кстати, для этой цели, возможно данный прибамбас будет востребован и под Windows. Есть очень много программ которые не хотят жить в виндах свежее XP. Хотя те, у которых стоит проприетарная система, думаю, не будут испытывать отрицательных эмоций при необходимости использовать VMWare Player.

[amarao-san.livejournal.com]

Ещё одна вещь, которую я очень хотел бы видеть во многих системах виртуализации, и которая толком есть только в xen'е: это последовательный порт в виде текстовой консоли. В госте реализуется в пол-пинка (обычный getty на ttyS0), в хосте тоже (любимая терминалка, взаимодействующая с последовательным портом). Очень удобно, копипаст из коробки, возможность прозрачной и почти прозрачной интеграции с локальным шеллом и т.д.

[vitus_wagner]

В qemu оно есть. -chardev pty.

Только вот на самом деле оно не так уж с полпинка реализуется. Терминалки ожидают что у них там будет именно терминал. Поэтому и pty, а не pipe, socket или что еще из того, что имеет qemu.

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

А это настроить можно и через ту локальную консоль, которая будет отображаться через vnc/spice.