qemoo, обертка для qemu для упрощения запуска виртуальных машин

[betcher]

-name \"$(basename "IMG")\"

Добавил.

Тем не менее, я скорее склоняюсь к QXL,

Вписал qxl

Для вас думаю удобнее была бы поддержка произвольного конфига передаваемого параметром или через окружение. Тогда программа могла бы сохранять настройки и использовать свои не трогая конфиг qemoo

QEMOOCFG=$HOME/.config/qemoo/config qemoo /dev/sda

Проверял мало, надеюсь не отвалится ничего.

[alex_q_2000]

QEMOOCFG=$HOME/.config/qemoo/config qemoo /dev/sda

Ок. Потом попробую что-нибудь сварганить. Спасибо.

Не знаю, на сколько это существенно, поскольку целевые дистры всё-таки линукс... Однако, если вздумают натягивать винду на глобус, то 10 ГБ это прямо-таки в обрез . Даже 7-ка требует не менее 18 ГБ (см. скриншот).



Это я на всякий случай, для справки т.с.

[ilfat]

С QXL иксы в ublinux не стартуют, но это скорее их проблема, чем наша

[ilfat]

Однако, если вздумают натягивать винду на глобус, то 10 ГБ это прямо-таки в обрез

Да, мы выбрали размер в 10 гигов по умолчанию, исходя из того, что большинству Линуксов этого будет достаточно. Для прочих вариантов добавили возможность задать размер через опцию. Только ради Винды увеличивать этот размер вдвое не очень хочется, если честно. Однако, не хорошо получается, что установка Винды через гуй может стать проблемой. Давайте думать

[betcher]

Давайте думать

В виртманагере это сделано через шаблоны настроек. Можно сделать подобным образом используя отдельные конфиги. В гуе надо будет выбрать конфиг из списка. Но, повторюсь. Так постепенно сделаем витманагер )))

[betcher]

Может в телеге чат заведем? Оперативнее будет. А сюда только результаты.

[alex_q_2000]

Давайте думать

qcow2 у вас - динамический.

Но, повторюсь. Так постепенно сделаем витманагер )))

Мда... дилемма...

Может в телеге чат заведем? Оперативнее будет. А сюда только результаты.

Это сегодня... А вообще все - кто где тусят.

[ilfat]

qcow2 у вас - динамический

Точно И сколько тогда сделаем? 30?

[betcher]

После разбивки на разделы и форматирования думаю разница в размерах будет, хоть и динамический.

[alex_q_2000]

Точно И сколько тогда сделаем? 30?

Думаю - 20ГБ пока хватит (минимальные требования для Win-10). На первых парах - это необходимый минимум на сегодня. Для линукса они тоже лишними не будут. Мнение субъективное конечно же.

После разбивки на разделы и форматирования думаю разница в размерах будет, хоть и динамический.

qcow2 с картинки выше раздулся на 9ГБ.

[ilfat]

alex_q_2000, при выборе образа для добавления показываются только iso и img, но qemu поддерживает и другие форматы виртуальных дисков, vdi, vmdk, vhd наверно тоже. Там нельзя добавить два фильтра, например iso, img, qcow2 и второй фильтр "все файлы"? Тоже самое можно сделать для поля, где выбирается с чего грузиться.

[alex_q_2000]

наверно тоже.

А я кстати спрашивал об этом выше, но betcher скромно умолчал об этом. Как показала практика, скармливать qemoo всё подряд (*.*) грозит появлением запроса polkit. Не могли бы Вы указать точно, с чем он работает на загрузке и на подключении?

[ilfat]

с чем он работает на загрузке и на подключении?

Загрузка и подключение ничем не отличаются, подключаются одним способом.
Полагаю qemu может грузиться со всех форматов, которые поддерживает qemu-img, а это:
QCOW2 (KVM, Xen) - .qcow2
QED (KVM) - .qed
VDI (VirtualBox) - .vdi
VHD (Hyper-V) - .vpc
VMDK (VMware) - .vmdk
raw - сюда относятся например .iso, .img, .raw и т.д.

qed ни разу не попадался, наверно можно проигнорировать, впрочем смотрите сами.
Итого я бы добавил расширения qcow2, vdi, vpc, vmdk, iso, img, raw (к примеру образ KolibriOS для флешки имеет расширение raw)

[alex_q_2000]

qcow2, vdi, vpc, vmdk, iso, img, raw

qcow2, vdi, vpc, vmdk, iso, img, raw для обоих, хорошо. Завтра добавим обязательно.

[betcher]

А я кстати спрашивал об этом выше, но betcher скромно умолчал об этом.

Ну вот, опять получил (.

Есть мысли по интерфейсу.
- Неплохо было бы запоминать папку для окошек выбора файла;
- Не нравится список "Режим загрузки", логичнее выпадающий список. А для EFI может даже чек батон. Но здесь не настаиваю;
- по шаблонам как в виртманагере по идее можно реализовать в gqemoo с использованием нескольких конфигов. То есть не делать в qemoo, а только для гуя. Выглядеть тоже может как выпадающий список "WIN7, WIN10, LINUX2022 типа такого. Можно и конкретные дистры вписывать. Надо только продумать что делать при противоречиях с другими параметрами.

[betcher]

Еще мысль. В порядке творческого бреда. Папка, к примеру /var/lib/gqemoo ( с возможностью поменять). В которой при запуске в режиме установки создаются образы для вирт машин. И эти образ также отображать списком в главном окне как источники для загрузки. То есть как для дополнительных устройств только не флажки, а переключатели. Хорошо бы с возможностью удалить и переименовать их прямо в окне.

[alex_q_2000]

Итого я бы добавил расширения qcow2, vdi, vpc, vmdk, iso, img, raw (к примеру образ KolibriOS для флешки имеет расширение raw)

...добавлены

Ну вот, опять получил (.

Мы все Вас очень любим и уважаем. А бэкенд - ну что бэкенд... Бэкенд в случае чего у Вас новый отрастёт.

- Неплохо было бы запоминать папку для окошек выбора файла;

...добавлено

- Не нравится список "Режим загрузки", логичнее выпадающий список. А для EFI может даже чек батон. Но здесь не настаиваю;

ЧекБокс EFI - добавлен, выбор режимов соответственно урезан

Надо только продумать что делать при противоречиях с другими параметрами.

Важно: Чем больше накрутим, тем больше будет проблем с конечным пользователем. Пусть поюзают. Этот вопрос, так же как и вопрос с шаблонами предлагаю оставить открытым. Напомню, что увеличение qcow2 в 2 раза фактически перекроет все потребности в ресурсах при элементарном тестировании и установке любых образов.

gqemoo-v0.7+efi+ext+initdir.tar.gz

Скриншоты: MgaRemix-9-Budgie, загрузка с флешки (EFI), подключена флешка с ROSA-2021 и образ MS DOS 6.22.iso, vga=virtio



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

[betcher]

Напомню, что увеличение qcow2 в 2 раза фактически перекроет все потребности в ресурсах при элементарном тестировании и установке любых образов.

Было 12, теперь 20.

gqemoo-v0.7+efi+ext+initdir.tar.gz

На гитхабе нет версии 0.7, мне удобнее проверить с гитхаба и сразу в контриб.

Еще идея по поводу интерфейса. Не обязательна к исполнению, просто мысли в порядке творческого бреда. ))
1. Выбор "установка/загрузка" и EFI перенести в верхнюю панель.
2. Левая панель, откуда убраны "установка/загрузка" и EFI будет - "выбор загрузчного устройства", выглядит также как правая в которой добавочные устройства, но здесь не флажки, а переключатель. В списке этой панели все подходящие найденные /dev/... и все подходящие образы в дефолтной папке, то есть той папке где создается ноый qcow2 в режиме Установки. Внизу панели также как и в правой выбор файла по фс.

[alex_q_2000]

На гитхабе нет версии 0.7, мне удобнее проверить с гитхаба и сразу в контриб.

GitHub: GQemoo-v0.7



+ Icons in the action selection menu
+ Double-click in the menu - start the action
+ Support: *.img;*.iso;*.qcow2;*.raw;*.vdi;*.vmdk;*.vpc
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

p.s. неплохо бы иметь доступ по сети, чтобы файлы закидывать по SFTP, т.е. соединение-мост по умолчанию. Или это гемор?

[ilfat]

Мне нравится идея Александра. Если делать как он предлагает, тогда логично было бы, чтоб при выборе подключаемых образов с ФС они добавлялись в список к подключаемым дискам. Как побочный эффект - добавление более одного виртуального диска к VM.

[alex_q_2000]

Господа, Вы будете иметь дело с обычными пользователями, которые возможно просто захотят участвовать в тестировании сборок/образов. Для обычного, простого, не искушенного в теме виртуализации пользователя требуется такое же простое понимание процесса тестирования. Для этого он должен видеть перед собой образ, который он грузит и чётко понимать действие, которое он желает совершить. Этих действий - 2: загрузка и установка. Напомню, как звучит генеральная концепция:

Это ни разу не аналог вирт-манагера, а всего лишь способ быстро загрузиться с исо, флешки, img, qcow2 без кипячения мозга и мышетыканья.

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

[betcher]

Я предложил поменять кнопки из левой панели наверх, а выбор устройства для загрузки сверху в левую панель. Из нового только qcow2 с установленными ОС в списке вместе с устройствами. Не выглядит усложнением.

[betcher]

GitHub: GQemoo-v0.7

Собрал.

[betcher]

p.s. неплохо бы иметь доступ по сети, чтобы файлы закидывать по SFTP, т.е. соединение-мост по умолчанию. Или это гемор?

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

[alex_q_2000]

Не выглядит усложнением.

Вот как тут понять, что случится, если пользователь нажмёт "Cтарт"? Мы либо образы тестируем/ставим, либо мы виртуалки создаём, список которых так же является источником загрузки (не установки).

[ilfat]

Вот как тут понять, что случится, если пользователь нажмёт "Cтарт"?

Мда ))
Вообще можно отказаться от пунктов Загрузка и Установка, добавив рядом с EFI галочку для "Установка".
А флешки (без выпадающего меню, сразу все) и образы, с установленными ОС, были в одной колонке, чтоб можно было выбрать что-то одно.

[alex_q_2000]

Мда ))

Вот. Можно опробовать живьём; просто распакуйте на РС и запустите gqemoo. Вроде бы учел третий источник загрузки (только загрузка). Можете пощёлкать, чтобы представить, что от чего зависит. Опрос после старта начинается с флешки, дальше загрузочный образ справа если опять нет - ищет указанное в списке установленных образов (qcow2, также можно запустить прямо из списка двойным кликом). Если этот вариант сочтете уместным, значит завтра допилю 0.8.

gqemoo-v0.8+InstalledImages.tar.gz

[alex_q_2000]

Ещё вчера грузил с EFI и устанавливал, затем запускал уже из qcow2 - всё работало. Сегодня при загрузке из qcow2 это:



И на винде и на линухе одинаково. У кого иначе?

Код: Выделить всё

[marsik@localhost ~]$ rpm -qi qemoo
Name        : qemoo
Version     : 0.9
Release     : 9
DistTag     : rosa2021.1
Architecture: noarch
...

[betcher]

Сегодня при загрузке из qcow2 это:

Фишка тут в том что инсталлятор прописывает пункт загрузки в ефи машины. Соответственно если ты установил и перегружаешь виртуалку этот пункт в ефи есть, а если выключить машину и запускать с qcow2, то пункта нет. Для себя обхожу костылем, копируя загрузчики по стандартному для ефи пути /EFI/BOOT/BOOTx64.efi сразу после установки. То есть загрузчик как в лайве нужно сделать. Как сие обходит виртманагер не знаю, видимо сохраняет для каждой машины что-то.

[ilfat]

Соответственно если ты установил и перегружаешь виртуалку этот пункт в ефи есть, а если выключить машину и запускать с qcow2, то пункта нет

Тоже об этом думал.
Вчера ставил Федору в EFI режиме, загружалась без проблем. Сегодня загружается без проблем. На всякий случай перезагрузил комп. Все равно загружается и пункт Федоры есть в UEFI. Пока не понимаю как так

[betcher]

Пока не понимаю как так

Возможно костыль как то что для Росы сейчас делаю. Загляни в /EFI/BOOT на ефи разделе.

[alex_q_2000]

Возможно костыль как то что для Росы сейчас делаю. Загляни в /EFI/BOOT на ефи разделе.

Ура! Для подобных случаев в инсталляторе Mageia на последнем шаге есть соответствующая галка:
"Install in /EFI/BOOT (removable device or workaround for some BIOS's)".



В Boot Manager её по-прежнему нет (если смотреть на скриншот Ильфата с Fedora), но работает.

Кстати, я стал привыкать к этому дополнительному списку с установленными образами qcow2. Из него удобно лишнее вычищать. Веселье продолжается.

p.s. Всё-таки комп ужасно тормозит на дисковых операциях, если идёт установка VM. Только что снизил приоритет потока запуска qemoo из гуя, может быть ещё какой-нибудь nice снаружи присобачить или не в коня корм?

[ilfat]

Возможно костыль как то что для Росы сейчас делаю. Загляни в /EFI/BOOT на ефи разделе

Ага, там есть загрузчик

[ilfat]

Можно опробовать живьём

Конечно так удобнее установленные ОС запускать, но как вы сказали, не сразу понятно что произойдет по кнопке Старт.
И вроде как переименование образов из гуи напрашивается

[betcher]

может быть ещё какой-нибудь nice снаружи присобачить или не в коня корм?

Это лишнее, мне кажется. Если интересно вот тут делал год назад запуск с разными приоритетами с zenity.
https://abf.io/import/runner-gui

[alex_q_2000]

И вроде как переименование образов из гуи напрашивается

Сделал, но как выяснилось, qemoo не умеет имена с пробелами для своих образов qcow2.

UPD: вообще то начал работать, нужно было комп перегрузить, поскольку писАл, что какой-то процесс exists... видимо что-то там у него подвисло... ок.

Если интересно вот тут делал год назад запуск с разными приоритетами с zenity.

Спасибо, ознакомился.

[alex_q_2000]

GitHub: GQemoo-v0.8



+ Added a list of installed images
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

Можно потестить на досуге.

UPD 28.12.2022:
GQemoo-v0.9
+ Stretch interface; LCL Scaling (Hi-DPI)
+ Improved renaming of images (replacement of characters)
+ Clearing the loading source when deleting an installed image
+ Clearing the source if an attempt is made to install an installed image
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

GQemoo-v1.0
+ DblClick - separate Start of already installed VMs
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

[betcher]

GQemoo-v1.0
+ DblClick - separate Start of already installed VMs
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

Летит в контриб.

[alex_q_2000]

Наставил я себе тут виртуалок разных, весь в виртуалках теперь сижу. Пытаюсь настроить Drag&Drop + Clipboard. Пробовал ставить spice-vdagent (в LUbuntu, кстати, он уже стоит), а в Win-7 ставил spice-guest-tools; пока не в коня корм. Может быть какой-нибудь волшебный параметр нужен или пакет?

[ans]

Наставил я себе тут виртуалок разных, весь в виртуалках теперь сижу. Пытаюсь настроить Drag&Drop + Clipboard. Пробовал ставить spice-vdagent (в LUbuntu, кстати, он уже стоит), а в Win-7 ставил spice-guest-tools; пока не в коня корм. Может быть какой-нибудь волшебный параметр нужен или пакет?

Сейчас проверил через virt-viewer - работает

[alex_q_2000]

Сейчас проверил через virt-viewer - работает

Похоже, что так.

В общем, если проследить всё это хитросплетение qemu-костылей...
https://www.kraxel.org/blog/2021/05/qemu-cut-paste/
https://people.freedesktop.org/~teuf/sp ... 02s03.html

...то, чтобы работал Drag&Drop + Clipboard хозяин/гость, на хозяине должен быть поднят spice-server 127.0.0.1:3001, с которым на локалхосте коннектится spice-vdagent из гостя после его загрузки. В результате начинает работать буфер обмена и двустороннее таскание файлов, НО увидеть/работать с гостем можно только в окне remote-viewer, который должен быть подключен на 127.0.0.1:3001.

Запускается spice-server строкой -spice port=3001,disable-ticketing=on и в результате запуск VM вместе с remote-viewer выглядит примерно так (дисплей нужен ИСКЛЮЧИТЕЛЬНО qxl):

Код: Выделить всё

qemu-kvm \
-m 2048 -vga qxl \
-device virtio-serial -chardev spicevmc,id=vdagent,debug=1,name=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-cdrom ./Mageia-8-Live-Xfce-x86_64.iso \
-spice port=3001,disable-ticketing=on \
& remote-viewer spice://localhost:3001

После загрузки гостя, на нём можно посмотреть правильный статус spice-vdagentd (см. Set max clipboard в конце):

Код: Выделить всё

> systemctl status spice-vdagentd
● spice-vdagentd.service - Agent daemon for Spice guests
     Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indirect; vendor preset: enabled)
     Active: active (running) since Fri 2022-12-30 23:43:56 EST; 1min 17s ago
TriggeredBy: ● spice-vdagentd.socket
    Process: 2261 ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS (code=exited, status=0/SUCCESS)
   Main PID: 2262 (spice-vdagentd)
      Tasks: 2 (limit: 2328)
     Memory: 852.0K
        CPU: 152ms
     CGroup: /system.slice/spice-vdagentd.service
             └─2262 /usr/sbin/spice-vdagentd

Dec 30 23:43:56 localhost systemd[1]: Starting Agent daemon for Spice guests...
Dec 30 23:43:56 localhost systemd[1]: spice-vdagentd.service: Can't open PID file /run/spice-vdagentd/spice-vdagentd.pid (yet>
Dec 30 23:43:56 localhost systemd[1]: Started Agent daemon for Spice guests.
Dec 30 23:43:56 localhost spice-vdagentd[2262]: opening vdagent virtio channel
Dec 30 23:43:56 localhost spice-vdagentd[2262]: Set max clipboard: 104857600
Dec 30 23:43:56 localhost spice-vdagentd[2262]: Set max clipboard: 104857600

Вывод: Поскольку для клиента spice-vdagent (на госте) требуется коннект с spice-server (на хозяине), а дисплей ограничен QXL - наверное лучше больше ничего не трогать и остановиться на достигнутом. Либо костылить дальше и выводить гостя через remote-viewer spice://localhost:3001 с дисплеем -vga qxl. Тогда вместе с qemu нужно ставить пакет virt-viewer, а из GQemoo выкинуть переключатель дисплеев (default, STD, QXL, VIRTIO). Как-то так.

p.s. Всех с наступающим.

[alex_q_2000]

gqemoo+remote-viewer_ROSA.tar.gz (распаковать и запустить gqemoo)

Для пробы и шаролупия: GQemoo с поддержкой перетаскивания файлов и буфера обмена. Изменений в qemoo нет. Нужно доустановить пакет virt-viewer.

Используется связка spice-server (localhost:3001) <> spice-vdagent(Linux)/spice-guest-tools(Windows). Из GQemoo убран переключатель дисплея, используется только -vga qxl.

Будет ли работать всё это добро в других DE? Как мне показалось - общая производительность упала, может быть я ошибаюсь. Хотя Windows-10 + spice-guest-tools встал и работает. Больше пока ничего не грузил; в процессе...

[alex_q_2000]

GQemoo-v1.1: https://github.com/AKotov-dev/gqemoo/releases
---
+ Зависимости: добавлен пакет virt-viewer
+ Поддержка перетаскивания файлов + двунаправленный буфер обмена
+ Принудительный сброс всех процессов QEMU - [Ctrl+Q]
+ Панели управления с изменением размера (сплиттеры для удобства)
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

Примечание: Для поддержки перетаскивания и буфера обмена в гостевой системе должен быть установлен spice-vdagent (Linux, обычно уже стоит) или spice-guest-tools (Windows).

[betcher]

Чет не сработало (.

[betcher]

Думаю можно добавить в qemoo запуск демоном для подключения со СПАЙС. Ильфат, как считаешь? То есть ключик только запустит, а подключаться потом самому ремминой или remote-viewer. Вопрос только как потом останавливать qemu.

[alex_q_2000]

Чет не сработало (.

В Mageia-8/9 воркает:



Видимо в Росе какие-то грабли с gtk-3. Ну тогда вот... Вместо remote-viewer вывод в spicy (нужен пакет spice-gtk)

GQemoo+spicy: https://cloud.mail.ru/public/cPaJ/Gafs1TovY (распаковать и запустить gqemoo)

p.s. а если судить по скриншоту, он сервер spice поднять не может.

UPD:
Внутри виртуалки ROSA-XFCE_2021.3 на VirtualBox запущен GQemoo и установка Mageia-i568:



Или даже вот так: из GQemoo на хосте запущена VM ROSA-XFCE_2021.3 + внутри гостя запущена установка Mageia-i568:



Даже не знаю, что предложить. Может быть Вашей машине мало 5 секунд, чтобы поднять SPICE?

Тогда вот, с ожиданием 10 сек: gqemoo+remote-viewer+10sec.tar.gz (распаковать и запустить gqemoo)

[betcher]

распаковать и запустить gqemoo)

Работает. Пакета одного не хватало в системе. Правильно понял, что это теперь единственный способ запуска? Только spice имею ввиду.

Версия 1.0 летит в контриб. Добавил ключик -d | --daemon для запуска виртуалки в режиме сервера. Доп параметры спер в gqemoo )). В консоль выведет PID процесса qemu, порт для подключения по SPICE и завершиться. PID это чтобы его потом убить можно было, как сделать удобнее пока идей нет. Подключиться можно remote-viewer или remmina. 127.0.0.1:порт

[alex_q_2000]

Правильно понял, что это теперь единственный способ запуска? Только spice имею ввиду.

А почему нет, дорогой betcher? Это же естественно: VM открывается с единственным дисплеем QXL, который работает в SPICE и обеспечивает плюшки. GQemoo - GUI, хост - GUI, окно VM - тоже GUI. Между Хозяином и Гостем работает Clipboard и Drag&Drop. По моему всё логично + как и было заявлено - "без кипячения мозга".

Хочу отметить, что режим демона (-d) позволил избавиться от ограничения в виде одной запущенной VM. Т.е. теперь можно стоять на ушах и смело запускать несколько разных VM (пока ram не закончится), или даже одинаковых, но из ISO. 2 одинаковых машины из QCOW2 или с флешки запустить не получится по известным причинам: qcow2 сам по себе один и "стрелять в одну мишень из двух стволов" но из разных кустов (с разных портов) не выйдет, а флешка просто "locked" при запуске второго инстанса.

Ну и вся эта красота с напоминанием о монтировании шары в госте разумеется улетела в другой пайп, поскольку в режиме демона я отдаю статистику в ~/.gqemoo/log для выуживания $port и $pid. Думаю, что это тоже плюс, поскольку это служебная, неизменяемая инфа, которой в логе делать нечего. Её место в описании qemoo (мнение субъективное).

В общем, будет примерно так: gqemoo-d.tar.gz (распаковать и запустить gqemo)

Скриншот: GQemoo-v1.2+qemoo + --daemon mode; Запущено 3 одинаковых VM из ISO.



GQemoo-v1.2: https://github.com/AKotov-dev/gqemoo/releases

[alex_q_2000]

betcher, у меня есть вопрос...

Я прилепил в GQemoo ещё одну кнопку 'Share', при нажатии на которую в буфер копируется длиннющая команда для вставки в терминал Гостя. В результате юзер без напряга может создать на госте шару ~/hostdir <> ~/qemoo_tmp (на хосте). Если использовать команду, которую отдаёт qemoo, то hostdir не появляется в фм, да и права на неё не выставлены. Я же расшариваю так (это команда, которая вставляется на Госте):

Код: Выделить всё

test -d /home/$(logname)/hostdir || mkdir /home/$(logname)/hostdir && mount -t 9p -o trans=virtio,msize=100000000 hostdir /home/$(logname)/hostdir && chown $(logname) -R /home/$(logname)/hostdir

Так подойдёт? Или есть ещё какие-нибудь варианты (fstab/автомонтирование, например)?

[alex_q_2000]

При монтировании шАры внутри гостя в ROSA возникает ошибка

Код: Выделить всё

mount: /home/live/hostdir: unknown filesystem type '9p'.

Проблема описана здесь...

В ROSA ядро собирается без поддержки файловой системы '9p'. Монтирование шАры внутри гостевой системы для ROSA недоступно. По крайней мере это справедливо для ROSA.FRESH.PLASMA5.12.3.x86_64.iso и ROSA.FRESH.XFCE.12.3.x86_64.iso.

Для сравнения - в Mageia...

Код: Выделить всё

> cat /boot/config-$(uname -r) | grep -i 9p
CONFIG_NET_9P=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_NET_9P_XEN=m
CONFIG_NET_9P_RDMA=m
# CONFIG_NET_9P_DEBUG is not set
# CONFIG_VIDEO_MT9P031 is not set
CONFIG_9P_FS=m
CONFIG_9P_FSCACHE=y
CONFIG_9P_FS_POSIX_ACL=y
# CONFIG_9P_FS_SECURITY is not set

> lsmod | grep 9p
9pnet_virtio           20480  0
9pnet                  90112  1 9pnet_virtio
virtio_ring            36864  3 virtio_console,9pnet_virtio,virtio_pci
virtio                 16384  3 virtio_console,9pnet_virtio,virtio_pci

В ROSA...

Код: Выделить всё

> cat /boot/config-$(uname -r) | grep -i 9p
# CONFIG_NET_9P is not set
CONFIG_VIDEO_MT9P031=m

> modprobe 9pnet
modprobe: FATAL: Module 9pnet not found in directory /lib/modules/5.15.75-generic-1rosa2021.1-x86_64
> modprobe 9pnet_virtio
modprobe: FATAL: Module 9pnet_virtio not found in directory /lib/modules/5.15.75-generic-1rosa2021.1-x86_64
> lsmod | grep 9p

Ок. В Mageia работает - значит оставляем, поскольку иметь доступ к каталогу на Хозяине из Гостя - это очень удобно.

GQemoo-v1.3: https://github.com/AKotov-dev/gqemoo/releases

[betcher]

В ROSA ядро собирается без поддержки файловой системы '9p'.

Это в образ 12.3 попало такое ядро. Если установить систему и обновиться будет работать. Бывает ).

[betcher]

test -d /home/$(logname)/hostdir || mkdir /home/$(logname)/hostdir && mount -t 9p -o trans=virtio,msize=100000000 hostdir /home/$(logname)/hostdir && chown $(logname) -R /home/$(logname)/hostdir

Если mkdir с ключом -p наличие папки можно не проверять. Chown точно нужен? Права на хосте не меняются при этом?

[alex_q_2000]

Если mkdir с ключом -p наличие папки можно не проверять.

В момент копипаста пользователь может быть в терминале под su -. Лучше проверять и работать именно с каталогом ~/hostdir, не затрагивая родителя (а родитель - хомяк). Считаю, что mkdir -p небезопасен.

Chown точно нужен? Права на хосте не меняются при этом?

Chown нужен. Опять же, чтобы не смотреть, с какими правами пользователь, предлагаю вот такой, работающий вариант, который просто вставляется в терминал под юзером или под рутом не важно. Скрипт монтирует пользовательский ~/hostdir и пишет автомонтирование в /etc/fstab. Повторный запуск скрипта - демонтирует hostdir и удаляет строку из /etc/fstab. Таким образом ~/hostdir не пропадёт и после перезагрузки:

Код: Выделить всё

pkexec bash -c 'clear; if [[ $(grep hostdir /etc/fstab) ]]; then umount -l hostdir; sed -i '/^hostdir/d' /etc/fstab; echo "/home/$(logname)/hostdir unmounted"; else test -d /home/$(logname)/hostdir || mkdir /home/$(logname)/hostdir && mount -t 9p -o trans=virtio,msize=100000000 hostdir /home/$(logname)/hostdir && chown $(logname) -R /home/$(logname)/hostdir && echo "hostdir /home/$(logname)/hostdir 9p trans=virtio,version=9p2000.L 0 0" >> /etc/fstab && echo "/home/$(logname)/hostdir mounted as hostdir"; fi'

...и права на хосте не меняются; там как был $USER так и остаётся на всё, включая новое содержимое из гостя, если создавалось.

p.s. Есть ли какие-нибудь новые, дополнительные мажоры для списка подключаемых устройств?

[alex_q_2000]

UPD: Как выяснилось, вариант с fstab не работает в Ubuntu. За то вариант с юнитом работает везде:

Код: Выделить всё

pkexec bash -c 'clear; if [[ -f /etc/systemd/system/hostdir.service ]]; then umount -l hostdir; systemctl disable hostdir; rm -f /etc/systemd/system/hostdir.service; else test -d /home/$(logname)/hostdir || mkdir /home/$(logname)/hostdir && echo -e "[Unit]\nDescription=GQemoo shared directory ~/hostdir\n\n[Service]\nType=oneshot\nExecStart=mount -t 9p -o trans=virtio,msize=100000000 hostdir /home/$(logname)/hostdir\n\n[Install]\nWantedBy=multi-user.target" > /etc/systemd/system/hostdir.service; systemctl daemon-reload && systemctl start hostdir && systemctl enable hostdir; chown $(logname) -R /home/$(logname)/hostdir; fi'

/etc/systemd/system/hostdir.service

Код: Выделить всё

[Unit]
Description=GQemoo shared directory ~/hostdir

[Service]
Type=oneshot
ExecStart=mount -t 9p -o trans=virtio,msize=100000000 hostdir /home/marsik/hostdir

[Install]
WantedBy=multi-user.target

...наверное его и оставлю.

GQemoo-v1.4
---
+ Universal script for mount/umount a shared directory ~/hostdir (systemd)
+ [ Ctrl+Q ] - Resetting all processes remote-viewer & qemu-system-x86_64
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

GitHub: https://github.com/AKotov-dev/gqemoo/releases

[betcher]

Собрал 1.4.
1. Не могу загрузить с флешки, в списке дополнительных устройств появляется, а там где загрузочное устройство только - "нет" можно выбрать.
2. Случается что файл устройства есть, а самого устройства нет. Не знаю с чем связано, но факт. На картинке как раз так. Устройства /dev/sdb физически нет. Test -b тут не поможет, в инсталляторе для бария делал такую проверку для устройств:

# dd if=/dev/sdb of=/dev/null bs=100 count=1 && echo ok
dd: не удалось открыть '/dev/sdb': Носитель не найден

при этом:
# ls /dev/sdb
/dev/sdb
# test -b /dev/sdb ; echo $?
0

[alex_q_2000]

Собрал 1.4.

Это потрясающе!

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

На скриншоте /dev/sda не имеет флага removable (третий столбец RM = 0), т.е. физической флешкой не является. Поэтому /dev/sda отсутствует в списке флешек, которые можно подержать в руках.

2. Случается что файл устройства есть, а самого устройства нет. Не знаю с чем связано, но факт. На картинке как раз так. Устройства /dev/sdb физически нет. Test -b тут не поможет, в инсталляторе для бария делал такую проверку для устройств:

/dev/sdb имеет размер "0B" и является removable (RM = 1). У меня так же отображается картридер (см. любой скриншот выше). Если "0B" устройства в списке не нужны - можно исключить, хотя криминала тут вроде бы нет. А вдруг кто-то захочет подключить виртуальную usb-дырку к своей виртуальной машине. Ну а при засовывании флешки в эту дырку, флешка автоматом прокидывается внутрь гостевой системы (в теории). Другое дело, что с картридером (0B) VM не грузится, но это к gui вроде бы не относится. Исключить?

[betcher]

На скриншоте /dev/sda не имеет флага removable (третий столбец RM = 0), т.е. физической флешкой не является. Поэтому /dev/sda отсутствует в списке флешек, которые можно подержать в руках.

Флага действительно нет, но это таки флешка (точнее токен с флэш памятью). И чего делать? В принципе редкость, можно забить.

Исключить?

Если так же отображается картовод, то пусть будет тогда.

[alex_q_2000]

Флага действительно нет, но это таки флешка (точнее токен с флэш памятью). И чего делать?

Например:

Код: Выделить всё

> lsblk -ldnp -I 8,11,65,66,259 -o NAME,MAJ:MIN,RM,SIZE,TYPE,MODEL

Здесь выводятся определенные мажоры (-I) и определенные столбцы. Мажор/Минор и removable у спорного девайса классифицируют его как обычный HDD (см. мой любой скриншот выше). Значит нужно найти дополнительный признак, по которому токены будут попадать в список физических флешек. Т.е. вывести ещё один столбец (для фильтра), который будет индивидуален именно для токена. Токена у меня нет, так что придётся Вам одному искать, что именно его отличает от HDD и от всего остального.

Список возможных столбцов из lsblk --help:

Available output columns:
ALIGNMENT смещение выравнивания
DISC-ALN discard alignment offset
DAX dax-capable device
DISC-GRAN discard granularity
DISC-MAX discard max bytes
DISC-ZERO discard zeroes data
FSAVAIL доступный размер файловой системы
FSROOTS mounted filesystem roots
FSSIZE размер файловой системы
FSTYPE тип файловой системы
FSUSED использованный размер файловой системы
FSUSE% использование файловой системы в процентах
FSVER filesystem version
GROUP название группы
HCTL Host:Channel:Target:Lun for SCSI
HOTPLUG съемное устройство или устройство с горячим подключением (usb, pcmcia, ...)
KNAME internal kernel device name
LABEL МЕТКА файловой системы
LOG-SEC размер логического сектора
MAJ:MIN major:minor device number
MIN-IO минимальный размер I/O
MODE device node permissions
MODEL идентификатор устройства
NAME имя устройства
OPT-IO оптимальный размер I/O
OWNER имя пользователя
PARTFLAGS флаги разделов
PARTLABEL МЕТКА раздела
PARTTYPE partition type code or UUID
PARTTYPENAME partition type name
PARTUUID UUID раздела
PATH path to the device node
PHY-SEC размер физического сектора
PKNAME internal parent kernel device name
PTTYPE partition table type
PTUUID partition table identifier (usually UUID)
RA read-ahead of the device
RAND добавляет случайное значение
REV ревизия устройства
RM съёмное устройство
RO устройство только для чтения
ROTA rotational device
RQ-SIZE запросить размер очереди
SCHED имя планировщика I/O
SERIAL серийный номер диска
SIZE размер устройства
START partition start offset
STATE состояние устройства
SUBSYSTEMS de-duplicated chain of subsystems
MOUNTPOINT куда примонтировано устройство
MOUNTPOINTS all locations where device is mounted
TRAN device transport type
TYPE тип устройства
UUID UUID файловой системы
VENDOR производитель устройства
WSAME write same max bytes
WWN уникальный идентификатор хранилища
ZONED zone model
ZONE-SZ zone size
ZONE-WGRAN zone write granularity
ZONE-APP zone append max bytes
ZONE-NR number of zones
ZONE-OMAX maximum number of open zones
ZONE-AMAX maximum number of active zones

Сейчас список флешек формируется так:

Код: Выделить всё

lsblk -ldnp -I 8 | awk '$3 == "1" && $4 != "0B" {print $1, $4}'

Нужен ещё один столбец для сравнения.

[betcher]

У меня два токена, у второго флаг на месте. Какой выхлоп показать по проблемному девайсу?

[alex_q_2000]

У меня два токена, у второго флаг на месте. Какой выхлоп показать по проблемному девайсу?

А почему один removable а другой - нет? Вероятно - это признак/свойство, прописанное на уровне железа, а значит - не является определяющим для токенов. Ну или один из токенов - кривой. Мне бы столбец заполучить или готовое условие для фильтрации.

[betcher]

Ну или один из токенов - кривой

Видимо так. Забей ).

[betcher]

Добавил в пакет с qemoo два юнита сиситемд. Один системный второй пользовательский. Можно использовать для запуска виртуалок при старте системы.
Для запуска под рутом делаем так:
systemctl enable qemoo@$(systemd-escape /path/to/your/img)

Под юзером так:
systemctl --user enable qemoo@$(systemd-escape /path/to/your/img)

Вместо образа можно любые из поддерживаемых устройств.
systemd-escape нужен для экранирования слэшей в путях.

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

ps aux | grep qemu
или
systemctl --user status qemoo@$(systemd-escape /path/to/your/img) --no-pager |less

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

[alex_q_2000]

Добавил в пакет с qemoo два юнита сиситемд.

А я вот заметил приятную плюшку. В новых Mageia-9 (Гость) дисплей масштабируется автоматически. Целых 5 минут не мог оторваться от растягивания попугая, он как резиновый: Просмотреть/Скачать анимированный GIF (11MB)...

[betcher]

как резиновый

Прикольно, интересно как сделано?

[alex_q_2000]

Прикольно, интересно как сделано?

Следуя этому: No Auto Resize with SPICE and virt-manager выяснилось, что масштабирование при изменении размеров окна VM устанавливается всего одной стройкой в терминале от юзера:

Код: Выделить всё

xrandr --output $(xrandr | awk '/ connected/{print $1; exit; }') --auto

Чтобы менять масштаб автоматически, мудрые люди лепят этот скрипт на событие udev "change" отдельным рулесом:
/etc/udev/rules.d/50-x-resize.rules

Код: Выделить всё

ACTION=="change", KERNEL=="card0", SUBSYSTEM=="drm", RUN+="/bin/x-resize"

Поскольку udev будет дёргать скрипт от root-а, в скрипт заранее передаются XAUTHORITY и DISPLAY:
/bin/x-resize (+x, исполняемый)

Код: Выделить всё

export DISPLAY=:0 #Может отличаться
xauth merge /home/$(logname)/.Xauthority
xrandr --output $(xrandr | awk '/ connected/{print $1; exit; }') --auto

Однострочник, который делает всё это + перегружает правила udev выглядит так (запускать под su):

Код: Выделить всё

echo 'ACTION=="change", KERNEL=="card0", SUBSYSTEM=="drm", RUN+="/bin/x-resize"' > /etc/udev/rules.d/50-x-resize.rules; echo -e "#! /bin/bash\n\nexport DISPLAY=$DISPLAY\nxauth merge /home/\$(logname)/.Xauthority\nxrandr --output \$(xrandr | awk '/ connected/{print \$1; exit; }') --auto" > /bin/x-resize && chmod +x /bin/x-resize; udevadm control --reload-rules; udevadm trigger

Данный способ НЕ предназначен для GNOME/Budgie. GNOME и Budgie, а так же Linux Mint масштабируются сами, без костылей. Если этот скрипт применить в GNOME, то VM накроется медным тазом.

В LXQt резайц дисплея перехватывается чем-то другим и эффекта не будет. В Plasma и XFCE (Live) в том числе и в Росе - работает.

В случае с масштабированием всё зависит от DE и от конторы, которая собирает дистрибутив. В Fedora MATE, например, udev вообще не понимает такого рулеса (см. выше). 32-х разрядные Mageia-7 тоже.

Вывод: В любом дистрибутиве и DE масштабирование окна VM работает во всех случаях только ручным запуском этого от юзера:

Код: Выделить всё

xrandr --output $(xrandr | awk '/ connected/{print $1; exit; }') --auto

Разумеется, в системе должен быть установлен xrandr. В общем, всё как обычно, костыль на костыле.

UPD: универсальный скрипт включения масштабирования (установка/удаление при повторном запуске); требуется xrandr

Код: Выделить всё

pkexec bash -c 'if [ -f /bin/xresize ]; then killall xresize; rm -f /bin/xresize /etc/xdg/autostart/xresize.desktop; exit; fi; echo -e "#! /bin/bash\n\nwhile true\ndo\nxrandr --output \$(xrandr | grep \" connected\" | cut -f1 -d\" \") --auto\nsleep 2\ndone" > /bin/xresize; chmod +x /bin/xresize; echo -e "[Desktop Entry]\nName=XResize\nExec=xresize &\nType=Application\nTerminal=false" > /etc/xdg/autostart/xresize.desktop' && [ -f /bin/xresize ] && nohup xresize &

Сначала создаётся файл /bin/xresize (работает в цикле) и /etc/xdg/autostart/xresize.desktop - ярлык автозапуска при рестарте системы. Каждые 2 сек. /bin/xresize устанавливает текущий размер экрана VM, тем самым сохраняя масштабирование при изменении размера.

...после тестов будет добавлен в GQemoo-v1.5 для вставки через Clipboard, как и предыдущий скрипт для монтирования ~/hostdir.

[betcher]

...после тестов будет добавлен в GQemoo-v1.5 для вставки через Clipboard, как и предыдущий скрипт для монтирования ~/hostdir.

Может уже пора завести отдельную папочку со скриптами и пробрасывать аналогично hostdir? Мало ли чего еще насочиняешь )

P.S. За описание с ресайзом отдельное спасибо, может прикрутим в росу что-то похожее.

[alex_q_2000]

Может уже пора завести отдельную папочку со скриптами и пробрасывать аналогично hostdir? Мало ли чего еще насочиняешь )

Ок. Как выяснилось, для Росы всё не так радужно, как хотелось бы...

Углубленный тест VM:
---
1. Fedora-36-Plasma (Wayland - идёт в топку)/MATE х86_64 - XResize работает
2. Mageia-7/8/9 i586/x86_64 Plasma/Cinnamon/GNOME масштабируются сами, XFCE/MATE/LXDE/LXQt - XResize работает
3. LUBuntu-20.04 (LXQt x86_64) - XResize работает
4. Linx Mint-21 Cinnamon - масштабируется сам и c XResize работает

ROSA-12.3-Plasma/XFCE - С растягиванием экрана VM неправильно устанавливаются координаты курсора относительно объектов. Невозможно попасть мышью на кнопки открытия/закрытия окон. В других дистрибутивах проблем нет (см. выше). Менял в Росе темы, но с чем связано - так и не понял. Растянул экран влево на 5 см, он смасштабировался, но теперь мышиный клик срабатывает при наведении на кнопку на эти 5 см. влево. Другими словами он не пересчитывает координаты, как в других ОС.

В Mageia XResize работает во всех сборках, включая старые, поэтому оставляю.

GQemoo-v1.5
+ Universal script for automatic scaling of a Linux virtual machine window
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

GitHub: https://github.com/AKotov-dev/gqemoo/releases

[alex_q_2000]

Видео: Пример работы с GQemoo

В ролике показано:
---
1. Загрузка из образа SimplyLinux-10
2. Включение автомасштабирования через вставку скрипта в терминал
3. Подключение общей папки ~/hostdir (Гость) <> ~/qemoo_tmp (Хозяин)

Скачать для просмотра (вес - 14МБ): SimplyLinux+GQemoo.mkv

[ilfat]

В последних версиях GQemoo у меня, так как в конфиге qemoo прописан дисплей SDL, появляется два окна VM, одно SDL, другое Remote-viewer.
Я могу из конфига убрать SDL, но тогда при использовании qemoo без gui мне придется соглашаться на гтк окно или каждый раз руками прописывать SDL.
Если теперь в gqemoo remote-viewer это единственный вариант, то может пусть gqemoo из cmdline удаляет прочие display?

Внутри виртуалки ROSA-XFCE_2021.3 на VirtualBox запущен GQemoo и установка Mageia-i568

Сегодня тоже подобным образом извращался
Причем производительность то нормальная получается

ROSA-12.3-Plasma/XFCE - С растягиванием экрана VM неправильно устанавливаются координаты курсора относительно объектов.

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

[ilfat]

А почему один removable а другой - нет? Вероятно - это признак/свойство, прописанное на уровне железа, а значит - не является определяющим для токенов. Ну или один из токенов - кривой. Мне бы столбец заполучить или готовое условие для фильтрации

Мне кажется ориентироваться только на флаг Removable не стоит. У меня есть внешний SSD и HDD, у обоих нет этого флага.
Может быть по усб шине еще фильтровать? lsblk -o PATH,TRAN | grep usb | cut -d' ' -f1 покажет устройства подклченные через usb, что думаете?

[alex_q_2000]

Если теперь в gqemoo remote-viewer это единственный вариант, то может пусть gqemoo из cmdline удаляет прочие display?

GQemoo-v1.6
+ Saving settings if the OS was installed with EFI
+ User configuration --qemoocfg ~/.gqemoo/qemoo.cfg
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

GitHub: https://github.com/AKotov-dev/gqemoo/releases

Теперь GQemoo запоминает, как ставилась VM (c/без EFI). Это полезно при старте qcow2, чтобы галку режима не мучить. Так же отвязан от конфига /etc/qemoo.cfg благодаря --qemoocfg. Соответственно появилась возможность при установке VM задавать имя образа. В списке установленных VM с EFI - значки зеленого цвета, BIOS - серые, чтобы легче ориентироваться в пространственно-временном континууме.

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

Видимо нет. Интересно было бы почитать, только вот что искать не знаю.

Мне кажется ориентироваться только на флаг Removable не стоит. У меня есть внешний SSD и HDD, у обоих нет этого флага. Может быть по усб шине еще фильтровать? lsblk -o PATH,TRAN | grep usb | cut -d' ' -f1 покажет устройства подключенные через usb, что думаете?

Это Александр хотел вместо флешки - токен в usb запихать. Ведь все говорили: "Не суй. Не надо". А он всё равно взял и воткнул.

[betcher]

GQemoo-v1.6

Не успеваю за вами ). Ни один пакет в репах Росы так часто не обновляется наверное.

Теперь GQemoo запоминает, как ставилась VM (c/без EFI).

Была мысль рядом с .qcow2 образом создавать одноименный .cfg и при наличии такого файла использовать в качестве конфига qemoo его, а не конфиг из /etc. Может сделаю еще. Сейчас пока думаю как добить идею с системд юнитами. Надо параметры как-то передавать.

Это Александр хотел вместо флешки - токен в usb запихать. Ведь все говорили: "Не суй. Не надо"

Стесняюсь спросить, а куда их пихать? Ржевский молчать!!! А вообще загрузка ОС с токена это мои будни. И Ильфата, кстати,тоже )).

[alex_q_2000]

Не успеваю за вами ). Ни один пакет в репах Росы так часто не обновляется наверное.

Да, думаю пора завязывать. Шаролупие до добра не доводит.

GQemoo-v1.7
+ Added rpm dependency: rsync
+ Added *.qcow2 image cloning feature
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

Добавлена rpm-зависимость rsync. Теперь установленные образы *.qcow2 можно клонировать. Отмена клонирования - Esc. Это полезно, если предстоит нарезать несколько одинаковых VM, например, для жестких/летальных экспериментов или размножения с разными DE.

Пробовал клонировать запущенный образ с внесёнными изменениями и он их успешно сохранил. Чувствую, ему без разницы, запущена VM или нет.

GQemoo-v1.8
+ Request to cancel cloning when exiting the GUI
+ Improved the XResize script for scaling the VM window
+ RPM Packages for Mageia-8 (ROSA-2021.1) and Mageia-9

GitHub: https://github.com/AKotov-dev/gqemoo/releases

[betcher]

Пробовал клонировать запущенный образ с внесёнными изменениями и он их успешно сохранил.

Кажется мне, что тут как повезет. Остановленную клонировать надежнее.

[betcher]

В реп летит очередное обновление qemoo: 1.3-13
1. Добавлена страничка для термхелпера, будет отображаться при установке пакета.
2. Добавил привязанные к образам конфиги.

Имя такого конфига совпадает с именем образа + .conf. Такой конфиг используется только в случае когда в cmdline qemoo нет ничего кроме имени образа.
При установке (с ключом -i) для нового образа привязанный конфиг создается автоматом. Все это нужно для запуска виртуалок с systemd.

В итоге чтобы запускать виртуалку с системд действия такие:

qemoo -i ./my.iso

будет создан образ.qcow2 куда будем производить уcтановку и одноименный образ.qcow2.conf. Примерно такой:

Код: Выделить всё

ACTION=run
RAM="auto"
ADD=""
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"
PORT=""
REDIRUSB=""
LOSETUP=""
SPICE=""
SHARE="/home/betcher/Programming/ISO"
QEMOOADD="" 

После завершения установки открываете конфиг и меняете:

SPICE=yes (тоже что параметр -d)
PORT=6001 (если порт не указать задаст автоматом придется искать какой именно)

остальное по желанию.

Дальше уже systemd
systemctl start qemoo@$(systemd-escape /path/to/your/img.qcow2)

Если надо от юзера то:
systemctl --user start qemoo@$(systemd-escape /path/to/your/img.qcow2)

аналогично status, enable, disable и т.д.

[alex_q_2000]

В реп летит очередное обновление qemoo: 1.3-13

GQemoo-v1.9
+ Адаптация к qemoo >= v1.3-13 с поддержкой systemd
+ Учитываются конфигурации VM для запуска через systemd
+ Флаг/атрибут qcow2 "(NO)EFI" изменён на *.qcow2.noefi
+ Улучшены функции переименования, удаления и клонирования

Был введён более жесткий контроль имен устанавливаемых образов qcow2. Сомнительные спецсимволы, пробелы и запятые в новых именах заменяются на "_".

https://github.com/AKotov-dev/gqemoo/releases

Кстати, в порядке творческого бреда... Если мышиный вопрос так и не решится, можете использовать для вашего Бария более современное и удобное DE - Budgie. Масштабирование в нём автоматическое и он есть у вас в репах.



Потребуется немного шлифануть попугайский пакет, зато все домохозяйки сразу захотят Барий.

[betcher]

Попробуйте запускать с qcow2 с произвольного каталога. Что-то у меня ругается (

[alex_q_2000]

Попробуйте запускать с qcow2 с произвольного каталога. Что-то у меня ругается (

Запуск SLinux с "Рабочего стола". Проблем не наблюдается.



Проблемы есть с EFI *.vdi от Virtual Box. Но я не знаю, раcсчитан ли qemoo в принципе на загрузку образов из VB... Так что проблем с qcow2 не вижу.

p.s. тема GTK на Вашем скриншоте напоминает IceWM. При всём уважении - это ужас какой-то.

[betcher]

При всём уважении - это ужас какой-то.

Это i3 ).

[betcher]

Тут подробнее. Проверю с нормальным DE позже, может связано как-то.

[alex_q_2000]

Тут подробнее. Проверю с нормальным DE позже, может связано как-то.

Тут всё очевидно:
...
ожидаю spice-server на 127.0.0.1: а порт где?
...
Порт и PID забираются из ~/.gqemoo/log. Файл создаётся c выхлопом qemoo? Кстати, ещё хотел уточнить... Для перекрытия основного конфига у меня используется --qemoocfg. Однако, начиная с qemoo v1.3-13 появилась --config (-c). Чем это грозит?

[betcher]

--qemoocfg.

Этот не надо использовать. Он чисто для внутренних нужд, когда идет перезапуск с root, чтобы не сменился конфиг.

То что в --config перекроет все, даже то что в cmdline. Это для конфигов к конкретным образам. Как привязанный конфиг то есть, только можно указать путь.

Заменить стандартный /etc/qemoo.cfg можно через окружение QEMOOCFG=/новый/конфиг.cfg

Выбирай что удобнее ).

ожидаю spice-server на 127.0.0.1: а порт где?

Порта нет если нет ключа -d. Сейчас проверил консольно с тем же qcow2 - норм.

[betcher]

Ларчик просто открывался. Файлы образов принадлежали руту. Пардон за панику ))

[alex_q_2000]

Этот не надо использовать. Он чисто для внутренних нужд, когда идет перезапуск с root, чтобы не сменился конфиг.

Ок. Пока закоммитил v2.0. Опция похоже не критичная, ибо c --config тоже работает. Просто у Ильфата прошлый раз sdl не перекрывался, а --qemoocfg вроде как всё это добро перекрыло. У меня всего то три параметра перекрываются при запуске/установке(+имя_образа) в ~/.gqemoo/qemoo.cfg

Код: Выделить всё

QEMUADD="-vga qxl -smp 2"
SIZE='20'
QCOW2='имя_образа_для_установки.qcow2'

Такой вот мегаконфиг, чтобы вы там с Ильфатом ничего своего (из основного для gui) не вставили. Можно было бы указать память (auto), но такой опции вроде нет, да и вряд ли гуёвый пользователь полезет в /etc/qemoo.cfg. Скорее всего он вообще никуда не полезет, это уже для гурманов с i3 на борту. Релизить пока не буду; подожду, может быть ещё чего всплывёт.

[ilfat]

Но я не знаю, раcсчитан ли qemoo в принципе на загрузку образов из VB

Рассчитан, загружает и с EFI и без.

[alex_q_2000]

Рассчитан, загружает и с EFI и без.

Mageia и ROSA vdi+efi прекрасно устанавливаются/работают в VirtualBox. Но по причине, которую мы обсуждали 27 декабря (про костыли и загрузчики), не работает в qemu. Fedora может и работает, не проверял. Или всё-таки есть какая-нибудь волшебная опция для qemu+efi?

Тоже об этом думал.
Вчера ставил Федору в EFI режиме, загружалась без проблем. Сегодня загружается без проблем. На всякий случай перезагрузил комп. Все равно загружается и пункт Федоры есть в UEFI. Пока не понимаю как так

[alex_q_2000]

То что в --config перекроет все, даже то что в cmdline. Это для конфигов к конкретным образам. Как привязанный конфиг то есть, только можно указать путь.

--config не перекрывает EFI_FIRMWARE, --qemoocfg перекрывает. Откатываюсь к --qemoocfg.

[betcher]

--config не перекрывает EFI_FIRMWARE, --qemoocfg перекрывает. Откатываюсь к --qemoocfg.

Не должно быть такого. Что вы писали в конфиг? Надо
EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"
Чтобы сделать правильный конфиг с нужными значениями можно запустить

qemoo par1 par2 par3 -e -d bla-bla и т.д. --config несуществующий_файл.conf

Создаст конфиг и все туда запишет.
Тут немного не красиво в том плане что, --config прикручен позже и там внутренние переменные. Местами отличаются от того что пишем в /etc/qemoo.cfg

[alex_q_2000]

EFI="-bios /usr/share/OVMF/OVMF_CODE.fd"

Вот дефолтный /etc/qemoo.cfg: https://abf.io/import/qemoo/blob/rosa2023.1/qemoo.cfg

Код: Выделить всё

# efi firmware emulator for current architicture
#EFI_FIRMWARE='-bios /usr/share/OVMF/OVMF_CODE.fd'

[betcher]

Внутри скрипта если указан параметр -e переменной EFI присваивается содержимое EFI_FIRMWARE по этому в конфиг который передается как --config надо писать EFI=. Согласен, не красиво, но пока так.

[alex_q_2000]

Внутри скрипта если указан параметр -e переменной EFI присваивается содержимое EFI_FIRMWARE по этому в конфиг который передается как --config надо писать EFI=.

Ок. В общем я не нашёл способа заставить qemu работать с EFI так же хорошо, как VB. Может быть убрать "Режим EFI", чтобы не вводить пользователя в заблуждение? А то он просидит минут 40 в процессе efi-установки, а загрузить VM не сможет и будет ругаться матом.

[ilfat]

Fedora может и работает, не проверял.

Федора работает, потому что при установке в виртуалку она прописывает загрузчик как в директорию /EFI/fedora так и в /EFI/BOOT.
То есть qemu, в принципе, работает с VDI образами, в том числе и при загрузке с EFI. Другой вопрос как сделать, чтобы загрузочная запись сохранялась. Посмотрел в Вирт-Менеджере, он сохраняет nvram в отдельный файл. Значит и мы можем это делать. В общем подумаем на досуге.

[betcher]

Федора работает, потому что при установке в виртуалку она прописывает загрузчик как в директорию /EFI/fedora так и в /EFI/BOOT.

Аналогично будет в росе со следующего релиза.

[alex_q_2000]

Посмотрел в Вирт-Менеджере, он сохраняет nvram в отдельный файл.

В VirtualBox, VM с названием rosa-efi представлена каталогом, в котором есть файлы:

Код: Выделить всё

rosa-efi.nvram  rosa-efi.vbox  rosa-efi.vbox-prev  rosa-efi.vdi

присутствует rosa-efi.nvram И ROSA нормально ставится/грузится с EFI.
А в каталогах VM без EFI файлы *.nvram отсутствуют.

А здесь что-то похожее про nvram (наверное):
Вопрос: https://archlinux.org.ru/forum/topic/1871/
Ответ: https://aur.archlinux.org/cgit/aur.git/ ... xe-netboot

Это не про то?

Аналогично будет в росе со следующего релиза.

Костыль?

[ilfat]

А здесь что-то похожее про nvram

Да, оно и есть. В cmdline Вирт-Менеджера такое же примерно.

Вопрос по gqemoo, могу ли я как-то через конфиги или переменную окружения указать другую папку для qemoo_tmp?

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

Screenshot_20230120_153758.png (21.9 КБ) 19976 просмотров

[alex_q_2000]

Да, оно и есть. В cmdline Вирт-Менеджера такое же примерно.

Значит для EFI необязательно делать костыль в самОм дистрибутиве, о котором выше написал Александр (про следующий релиз)?

Вопрос по gqemoo, могу ли я как-то через конфиги или переменную окружения указать другую папку для qemoo_tmp?

Нет. ~/qemoo_tmp задаётся один раз и постоянна всегда для всех VM. Рабочая директория qemoo задаётся по факту запуска GUI без переназначения и без возможности изменить - SetCurrentDir(GetUserDir + 'qemoo_tmp'). Изменение рабочей директории из гуя повлечет за собой изменение скрипта авто-монтирования шАры ~/qemoo_tmp <> ~/hostdir в гостевой системе.

Засунул сегодня кучу флешек и понял, что выпадающее меню для флешек не слишком то информативно.

Можно добавить модель, но это растянет список флешек на половину формы.

[betcher]

о котором выше написал Александр (про следующий релиз)?

Этот костыль в основном для сменных устройств, плюс помогает с кривыми EFI как у MSI.

[alex_q_2000]

Этот костыль в основном для сменных устройств, плюс помогает с кривыми EFI как у MSI.

Установка и запуск VM с EFI+NVRAM в qemoo без костылей



Важно: если вы уже пробовали подставлять /usr/share/OVMF/OVMF_VARS.fd в процессе экспериментов, скорее всего они повреждены. Их нужно перезаписать заново из соответствующего пакета в /usr/share/edk2/ovmf/*. OVMF_VARS.fd - это всего лишь шаблон, который нужно копировать в "имя_машины.nvram" или в другое имя, но с указанием его в коде запуска.

Нужно скопировать "имя_машины.nvram":

Код: Выделить всё

cp -f /usr/share/OVMF/OVMF_VARS.fd ~/qemoo_tmp/имя_машины.nvram

Запуск/установка с EFI+NVRAM будет уже НЕ:

Код: Выделить всё

EFI_FIRMWARE='-bios /usr/share/OVMF/OVMF_CODE.fd'

а...

Код: Выделить всё

EFI_FIRMWARE='\
-drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive if=pflash,format=raw,file=~/qemoo_tmp/имя_машины.nvram'

На уровне GUI это уже работает (см. пробник GQemoo ниже), т.е. нет проблем с загрузкой и установкой ROSA/Mageia и остальных с EFI. Всё работает без костылей. Было бы хорошо сделать это на уровне бэкенда, а то у меня в гуе много лишней работы вылазит: копирование/переименование/удаление/клонирование - всё надо учитывать с "имя_машины.nvram". В теории qemoo должен сам хотя бы файлы *.nvram создавать в CurrentDirectory.

Я могу ВСЁ реализовать через GQemoo, но при этом в самом qemoo не будет правильного функционала для EFI, а это не красиво.

Тесты с EFI+NVRAM в ROSA-12.3, Mageia-7/8, Fedora-36 - passed.

Примечание: Загрузка внешних образов *.vdi из VirtualBox не проверялась. Вероятно для образов с EFI нужно будет присобачивать их "имя_машины.nvram", но это не точно.

Полезные статьи:

• About Secure Boot with libvirt on RHEL type distributions

• QEMU/KVM non persistent nvram on uefi virtual machine

Пробник GQemoo-v2.0 с EFI+NVRAM (распаковать и запустить gqemoo, всё под юзером): https://cloud.mail.ru/public/CyjC/FZLbrXYZb

[betcher]

Спасибо. Подумаем как прикрутить.

[betcher]

Отправил собираться следующую версию. С поддержкой этого nvram. Сохраняет рядом с образом, прописывает в конфиг. Это все только в режиме установки, в остальном как раньше. Надеюсь ничего не отломал ). Надо бы уже собраться и порядок там навести.