Уточненное ТЗ по qemu GUI
Jul. 16th, 2015 11:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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.
Ради этого стоит потерпеть и то, что при отсутствии в 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.
no subject
Date: 2015-07-20 05:50 pm (UTC)Умеет кроме клавиатуры/мыши/графики еще как минимум аудио, а также если немножко потрахаться с пересборкой клиента - и смарткарты. Вроде как даже умеет 3d-графику в каких-то объемах.
В общем, существенно интереснее VNC. В QEMU поддержка встроена. Правда, нужно три строчки опций командной строки указать. И это не считая тех, которые нужны для пробрасывания с клиента USB-устройств (с этим я еще не разобрался).
Cуществует Xspice, сервер, позволяющий ходить по этому протоколу к физическим машинам.
Ну то есть я довольно давно обратил внимание, что такая штука вообще-то есть. Но только сейчас сподобился разобраться как ей пользоватбся.
no subject
Date: 2015-07-21 07:50 am (UTC)no subject
Date: 2015-07-21 08:33 am (UTC)Что из этого будет работать с Xspice, в смысле при доступе к физической машине по SPICE - не проверял.
no subject
Date: 2015-07-21 09:04 am (UTC)no subject
Date: 2015-07-21 09:50 am (UTC)Для терминального решения может как раз оказаться интересным предоставлять доступ не к хосту, а к виртуалкам на нём.