Pull to refresh

Comments 16

UFO just landed and posted this here

У меня нет криптотокена, проверить не могу. В списке устройств, предлагаемых к пробросу, есть смарт-карты, но насколько оно работоспособно под линуксом, не знаю.

Присоединяюсь к вопросу. Общий буфер (copy|paste) и диски это легко решается и без RDP.
А вот проброс USB гостевую машину… (любой raw USB)
VirtualBox однозначно выигрывает тем что это делается "из коробки" и очень просто.


Какие тогда плюсы у Huper-V перед VirtualBox остаются (если нужно не хостевую Windows) — даже не знаю.
Может кто расскажет в чем лучше может быть Huper-V vs VirtualBox, если используется Linux в гостевой?

Как минимум тем, что не требует пользовательской сессии. Задача пробрасывания USB-токена достаточно специфичная (нам бы 1 запустить) и "колхозная" (без обид, сам заморачивался по причине жмотства конторы на USB-over-IP). МС исходно заявляли, что в случае корпоративного использования проброс USB небезопасен и именно поэтому не реализован. Но почему-то именно эта специфичная и узкая задача избирается, как критерий критиками. Если это, и правда, единственный недостаток Hyper-V, то, ИМХО, это лучшая реклама.

Virtualbox тоже не требует сессию — можно настроить запуск виртуалок в headless режиме.
Да, посмотрел — есть функция запуска из shell'а, то есть можно написать свой скрипт запуска ВМ со старта, но все «фишки», типа паузы машин при перезапуске гипервизора, восстановления состояния при неожиданном выключении, управления памятью гипервизора (как virtualbox будет «разруливать» память между 2-3-5мя ВМ.

Колхозная или нет. Это зависит от конкретных задач. Если ПО (которое только по Linux) нужно запускать/писать/отлаживать, которое активно пользует USB периферию. А основной комп — Windows…
А c opensource USB-IP-USB как то не очень (хоть самому писать.)


Не всем же нужен вариант webсервис. сайт… и тп. в виртуалке. Хотя допускаю, что это 99% случаев

хмм, ну да, ваш кейс (как мне кажется) не совсем типичный. более тго, ваша ситуация как раз требует пользовательской сессии, так что не необходимости в автозапуске ВМ.
UFO just landed and posted this here
Тем, что если hyper-v уже зачем-то нужен (докер, виртуалки с виндой), то virtualbox вместе с ним не запустится нормально.

Это то понятно. Что VirtualBox c Hyper-v одновременно не живет (даже останов и выключение Hyper-v как то не очень помогает).


Я про сравнение использование в чистом виде.


Мне VirtualBox показался как минимум удобнее для Linux server (не говоря уже Linux desktop). Но удобство вещь субъективная. А с точки зрения эксплуатации (надежность,… пр.) я четких сравнительных данных (не рекламных) на основе опыта эксплуатации не нашел.

Пробовал играться с Майкрософтовскими образами Ubuntu через Quick Create и наткнулся на такую проблему:
Ubuntu 18.04 нормально запускается в enhanced режиме через xrdp и все работает как надо.
Образ Ubuntu 19.04 вроде как имеет установленный xrdp, но работает без enhanced режима и не просит выбрать разрешение, а конектится по стандарту.
Как понять, почему xrdp не подхватывается на 19.04? Может в настройках что-то подкрутить?
Я просто даже не знаю, с чего начать копать.

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


К слову, в репозитории linux-vm-tools тоже обновили скрипт автоконфигурации, теперь он корректно устанавливает параметр port.


Пора обновить пост.

На днях пришлось прокидывать USB в гостевую Windows-виртуалку с Hyper-V, ищущих софт USB-over-IP (dth_apostle, mmMike), возможно, заинтересует. Не уверен, работает ли это в Linux. Работает при соблюдении двух условий:


  1. Гостем выступает Windows (опирается на фичу RemoteFX, не проверял, реализована ли в XRDP; впрочем, похоже, что нет).
  2. Доступ к виртуалке осуществляется по RDP из mstsc.exe с Windows.

Требуется:


  1. На RDP-клиенте включить групповую политику: Computer Settings -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client -> RemoteFX USB Device Redirection -> Allow RDP redirection of other supported RemoteFX USB devices from this computer, переставить ее в Enabled, запустить gpupdate и перезагрузиться.
  2. На госте включить групповую политику: Computer Settings -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Device and Resource Redirection -> Do not allow supported Plug & Play device Redirection, переставить ее в Disabled, перезагрузиться.
  3. При запуске mstsc.exe в локальных ресурсах выбрать нужные USB-устройства из списка.

Без пользовательской сессии, похоже, это организовать нельзя, но для моего кейса хватило.


Скриншот mstsc.exe

Скриншот

Sign up to leave a comment.

Articles