rPman

И да и нет.

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

Если происходит смена версии дистрибутива с версиями компонент равными или новее тех, что использовались, то проблем быть не должно, приложения при запуске должны понимать что происходит обновление и умеют работать со старыми версиями (кстати все зависит от разработчиков этих компонент, возможны пределы разницы версий, когда ну очень старый конфиг может быть неверно понят, но чаще проигнорирован, новым приложением).

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

Использовать xvfb (X virtual frame buffer). Устанавливаешь одноименный пакет, настраиваешь его запуск, используешь. Таких серверов может быть запущено несколько, но rustdesk может этого не ожидать (я сильно не копал но обычно если запустить rustdesk приложение с установленным DESKTOP на нужную тебе сессию, для нее он и запустится)

p.s. linux + xvfb + rustdesk это худший способ настройки удаленного подключения
Рекомендую x2go, сервер все сам настроит, а клиенты есть по до все. Работает на порядок эффективнее (плавнее и менее требовательный к сетевому каналу).
Для игр не подходит.

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

Причина - нет адекватной поддержки проброса устройств, чаще всего она ограничена либо работает только при опредленных условиях и по разному на разных устройствах (в смысле компьютер), зависит от производителя процессора intel/amd, возможностей материнки и кучи других мелких нюансов (например десктопные материнки чаще всего ограничивают функционал в биосе). С момента активного использованиея EFI биосов, это еще сильнее усложнилось.

* Итак - проброс всего pci(-e) устройства вместе с контроллерами и соответственно устройствами, через него подключаемыми. Это самый удобный с точки зрения использования способ (потому как после запуска виртуальной машины контроллер уже доступен внутри и чаще всего без дополнительных движений видит устройство 'как родное'.

В linux мне известно что это поддерживает только qemu/kvm и поддержка требует соответствующие аппаратные возможности (IOMMU/VT-d плюс в принципе аппаратная виртуализация), даже некоторые gpu могут быть так проброшены внутрь виртуалки, производители видеокарт об этом знают и старательно ставят палки в колеса, так как такой функционал они хотят чтобы пользователи использовали только с их 10х дороже серверными вариантами видеокарт). Требует хорошего прогружения в настройки linux, хотя бы чтобы исключить инициализацию устройство самим linux (некоторые устройства не любят включаться два раза подряд без железной перезагрузки).

* Промежуточный вариант - проброс USB устройств. Это установка в гостевой операционной системе специального драйвера USB который по сети или каким-либо другим способом (например virtualbox usb при установке проприетарного guest additions) транслирует весь трафик, включая управляющий с хост машины для выбранного usb устройства или контроллера. Точно помню отдельные приложения для трансляции usb по сети между машинами даже без виртуализации, но лично сам не пользовался, гуглите решения обычно платные.

* Проброс 'блочного устройства' (читай дисков или отдельных разделов, и даже файлов), в этом случае гостевая ос не имеет доступа к самому устройству, но только к данным на нем. Формально это просто подключение диска из файла (потому как даже в windows диск и раздел это буквально файл, который можно открыть fopen по специальному имени). Разные системы виртуализации дают разный интерфейс и удобство. qemu с тем же libvirt - удобнее чем к примеру virtualbox (там нужно в консоли специальную 'скрытую' команду использовать)

p.s. Проброс видеоускорителя - есть еще протоколы spice но на сколько я знаю они не достаточно функциональны
Ну и проброс всякой мелочовки типа клавиатура, мышь, планшет/сенсорный экран, мониторы. Это все виртуальные сущности, реальное железо тут не пробрасывается.

p.p.s. драйвера windows для гостевых систем с каждым разом становятся все хуже и хуже, если я верно понял палки в колеса вставляет сама майкрософт, например windows 10 адекватно в virtualbox уже не работает gpu без глюков (я обхожу большинство проблем только с помощью rdp подключения)

Готового решения боюсь не будет, но написать свое под свою задачу будет не сильно сложно.

Покупаешь вторую клавиатуру (обычно usb, можно купить типа только расширенная цифровая), рисуешь на кнопках стрелки громкости или как то еще помечаешь какая кнопка громкость какого приложения будет менять, затем настраиваешь какого-нибудь демона на прослушивание клавиатуры (гугл говорит про actkbd (пример), но почему то в ubuntu по умолчанию его нет, возможно за эти годы его переименовали или функционал перенесли в другое приложение типа xbindkeys), как минимум в linux встроен функционал отвязывания клавиатуры от сессии (например с помощью loginctl я могу настроить отдельные рабочие места и привязать видеокарта+монитор+клавиатура каждому свое и соответственно просто отвязать дополнительную клавиатуру чтобы ее использовать в другом демоне или даже xhephir - это xserver в окне)

А там настраиваешь на каждую кнопку вызов команды смены громкости с помощью pulse-audio
pactl list
получаешь список всего, работающих со звуком (рекомендую поизучать, можно ограничить вывод, задать формат вывода, в т.ч. json), устройства, источники, получатели,

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

Дальше просто запускаешь команду

# изменить громкость
pactl set-sink-input-volume [sink number] [volume percent]
# переключить mute
pactl set-sink-input-mute [sink number] toggle
# bashcompletion по tab автоматом предлагает sink номера уже работающих приложений, это поможет тебе разобраться что именно из вывода pactl list тебе нужно

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

Это меню grub.
не помню про centos, но в современных версиях, по умолчанию он не показывается, и будет виден только если предыдущее завершение работы было не корректным.

Если что, в grub есть настройка, сколько времени показывать это меню по умолчанию и автоматически грузить какой пункт (остановить автозагрузку по нажатию ESC или стрелок)

В разных версиях grub это настраивалось по разному, гугли именно для своей centos grub timeout