Ошибка перенаправления usb kvm
Когда человек много лет рыл бункер и запасал там продукты, он должен испытывать глубокое моральное удовлетворение, если бункер понадобился. Он будет довольный заявлять: «А я говори-и-и-ил!» То же касается и того, кто делал запасы продуктов в кладовой, когда все закупались в магазинах только на сегодня. А вот с нашим комплексом для удалённой работы Redd как-то и не хочется злорадствовать. Он проектировался для удалёнки в мирное время. И использовался задолго до первых новостей из Китая.
Давно я про него ничего не писал. Другие проекты отвлекают, да и интерес, судя по рейтингу последней из опубликованных статей, уже упал. Сил на подготовку статьи отнимают много, и это имеет смысл делать только если оно нужно достаточному числу читателей.
Но так как сейчас удалёнка у всех на устах, возникло желание поделиться одной наработкой, которая может кому-то помочь. Это не наша разработка, я проводил исследования в рамках работы над сервисом удаленной работы с отладочными платами All-Hardware. Вот их результаты сейчас и опишу. Проект USB/IP известен многим. Но он давно свёрнут авторами. Самые свежие драйверы были под WIN7. Сегодня я опишу, где скачать вариант для WIN10, и покажу, как я его проверял. Кроме того, разработчики современного аналога уверяют, что у них сделан не только Windows-клиент, но и Windows-сервер (правда, в этом режиме я тестирование не вёл: задача того не требовала). Но кому-то это тоже может оказаться полезным.
Если устройств много и все они одинаковые
Вот тут появилась интересная задачка, как пробросить несколько одинаковых девайсов на разные ВМ?
При этом, стоит отметить, все устройства имеют одинаковую пару vendorid:prodid, а пара usbbus-usbaddr совсем не постоянна, стоит только вынуть и вставить устройство, так оно сразу поменяет свой usbaddr.
Я решил ее при помощи udev.
Кстати если вы не совсем понимаете как работает udev, на Debian Wiki есть классная статья о udev
И так приступим
Для начала нам надо узнать серийник нашего устройства, по которому и будем идентифицировать его в udev:
И вставим наше устройство, после этого мы сразу увидим список переменных этого устройства которые udev любезно инициализировал для нас:
Информацию о серийнике и других аттрибутах можно получить и другим способом, но стоит учитывать что для написания правил мы будем использовать именно переменные из команды выше, а не аттрибуты из команды ниже. В противном случае не будет отрабатывать триггер remove при отключении устройства.
Готово, теперь при подключении нашего устройства, оно будет автоматически шарится на нужный нам порт, а при отключении usbredirserver будет прекращать свою работу.
По аналогии добавляем и остальные устройства.
New or Quiet Penguin
Описание проблемы.
Для двух программ есть два электронных (лицензионных) ключа Guardant одной модели (у них одинаковые Vendor ID и Product ID). Чтобы не возникал конфликт, в libvirt в описании виртуальной машины такие ключи добавляются с указанием аппаратного адреса (bus, device). После перезагрузки может оказаться так, что номера устройств будут другие. А если переключить их в другой порт, то и номер шины может стать другим.
Запуск сервера
Пакет usbredirserver можно найти в стандартных репозиториях практически во всех популярных дистрибутивах linux.
Вставляем флешку в компьютер, смотрим вывод usb-устройств:
Видим что пара vendorid:prodid равна 125f:c82a, а ядро определило флешке 003-001 usbbus-usbaddr соотвественно.
Теперь давайте расшарим ее на 4000 порт:
Настройка виртуальной машины
- uhci — для USB1.0
- ehci — для USB2.0
- xhci — для USB3.0
Для qemu (без libvirt)
Добавьте опции в команду запуска виртуальной машины:
Для libvirt
В исходном файле конфигурации виртуальной машины в узле <devices> удаляем все USB контроллеры и добавляем следущий блок:
Кстати, если вы используете spice, то добавив к контроллерам еще 3 специальных девайса, станет возможен проброс usb-устройств с клиента spice на сервер.
Для qemu
Добавляем следующие опции в команду запуска виртуальной машины, помимо контроллеров определеных нами раньше:
Для libvirt
В исходном файле конфигурации виртуальной машины в узле <devices> добавляем следующие опции, помимо контроллеров определеных нами раньше:
Теперь все готово для осуществления проброса.
Заключение
Проект usbip-win является современной заменой для проекта USB/IP. Он живёт и развивается. При этом он предоставляет для ОС Windows не только функцию клиента, но и функцию сервера. Совместимость с Linux-версией сохранена.
Устойчивость работы удалённого USB-устройства неожиданно поразила. Я был уверен, что возникнут таймауты. Возможно, где-то они и возникнут, но для JTAG-адаптеров не было замечено ни одного сбоя. К сожалению, не все USB-устройства могут быть проброшены через сеть по причине низкого быстродействия получившейся системы. Но в случае с JTAG-адаптерами можно рассмотреть альтернативные вещи. В частности, CMSIS-DAP вместо ST-LINK.
Оба рассмотренных проекта (usbip-win и CMSIS-DAP) могут быть скачаны с GitHub в виде исходных кодов.
Если это поможет кому-то организовать удалённый доступ к оборудованию, я буду рад. Использование Raspberry Pi позволит бросить оборудование в произвольных местах.
Сервер виртуальных машин на GNU/Linux. Виртуальные машины Windows. Гипервизор QEMU-KVM.
Виртуальные машины запускаются автоматически.
Неудачное решение
Первое, что пришло в голову после изучения документации — указать в конфигурации виртуальной машины все возможные bus и device для этих одинаковых USB-ключей. Но это породило неудобство при просмотре и редактировании виртуальной машины в Virt-Manager.
Для начала несколько слов о вышеперчисленных решениях
- AnywhereUSB — довольно неплохое решение, но дорогое, и имеет неприятние глюки, например бывает если расшаренная флешка отваливается, то переподключить ее обратно можно только физически вынув и вставив ее.
- USB/IP — OpenSource проект. Вроде как был заброшен. По факту глючит довольно сильно. При разрыве соединения, машина частенько уходит в полнейший freezee, а windows показывает BSOD
- USB Redirector — Замечательная софтина. Для расшаривания устройств с linux на linux бесплатна, во всех остальных случаях уже стоит денег, не так много как AnywhereUSB, но и не бесплатно как хотелось бы :)
Подключение устройства к виртуальной машине
Через опции при запуске ВМ
Устройство которое нужно подключить к ВМ можно указать при запуске, добавив следующие опции в команду запуска
Для qemu
Для libvirt
Этот блок рамещается перед тегом </devices>, рядом с контроллерами определенными нами раньше:
Его так же можно исполнить командой virsh attach-device
Или через qemu-monitor
Заходим на гипервизор и в qemu-monitor нашей машины выполняем следующие команды:
Что бы отключить флешку достаточно такой команды:
На этом все, после данных шагов ваша ВМ увидит вашу флешку и сможет с ней нативно работать.
Окончательное решение.
Разбираться с UDEV желания не было. (Не знаю, можно ли в нём изменить номер устройства на шине USB, а изменить номер шины наверняка невозможно.)
Поэтому было применено максимально универсальное решение: в процессе загрузки после запуска виртуальной машины выполняется скрипт, который выясняет номера шины и номер устройства для каждого из одинаковых электронных ключей, формирует файл-описание устройств для libvirt (формата XML) и добавляет проброс этих устройств в виртуальную машину. Если в скрипте возникнет ошибка, она заносится в syslog и на stderr.
Чтобы не придумывать обработку start/stop/status и проверку зависимостей, скрипт добавлен в rc.local — он заведомо выполняется последним из стартовых скриптов.
Использование этого метода исключает переключение USB-ключей во время работы виртуальной машины — если вытащить ключ и вставить его в другой порт, он не будет подключен повторно. Для сервера это ограничение приемлимо.
Вывод lsusb (для справки), нужные устройства — пятое и шестое на третьей шине:
Пояснение к тексту.
Для простоты программа для AWK передаётся в командной строке. При этом, чтобы избежать сложностей с экранированием кавычек и "$", внутри awk-программы переменные шела не используются. Поэтому сделан переход в созданный временный каталог, а также параметры устройств заданы константами (Vendor ID 0x0a89 и Product ID 0x0008).
На сегодняшний день существет довольно много способов пробросить USB-устройство на другой компьютер или виртуалку по сети.
Из наиболее популярных — железячные такие как AnywhereUSB и чисто програмные продукты, из тех что я попробовал сам: USB Redirector и USB/IP.
Я бы хотел рассказать вам еще об одном интересном способе, который работает непосредственно с эмулятором QEMU.
Он так же является частью проекта spice, официально поддерживаемым RedHat.
UsbRedir, это открытый протокол для проброса usb-устройств по tcp на удаленный виртуальный сервер, разработанный при поддержке RedHat в рамках проекта spice. Но как оказалось им можно вполне успешно пользоваться и без spice. В роли сервера выступает usbredirserver, который шарит usb-устройство на определенный порт, а в качестве клиента сам QEMU, который эмулирует подключение экспортированного usb-устройства в определенный usb-контроллер вашей виртуальной машины. Благодаря такому подходу в качестве гостевой системы может использоваться абсолютно любая ОС, так как она даже не знает, что устройство является проброшенным удаленно, а вся логика ложится на QEMU.
Грустная часть проверки: серверная часть
Сначала я расскажу, как проводилась проверка в рамках нашего проекта. Там всё кончилось не очень хорошо. Проверяли адаптер ST-LINK, установленный в корпус комплекса Redd, благо я уже отмечал, что в комплексе используется ОС Linux сборки Debian, а эта сборка содержит встроенный сервис USB/IP.
Согласно статье, устанавливаем сервис:
Дальше в статье подробно рассказано, как автоматизировать процесс загрузки сервиса. Как я разбираюсь в Линуксе, я уже многократно писал. Плохо разбираюсь. У меня нет привычки с умным лицом цитировать чужие тексты, слабо понимая суть. Поэтому я ещё раз напомню ссылку на замечательную статью, где всё рассказано, а сам покажу, что делал я при каждом старте ОС (благо всё было нужно только для проверки):
Назначение первых двух из вышеприведённых заклинаний мне неизвестно, но без них не создаются какие-то каталоги, а без этих каталогов потом не будет экспорта USB-порта. Каталоги создаются только до перезапуска системы. Так что создавать их надо каждый раз. Третья строка — с нею всё понятней, она запускает сервис.
Теперь смотрим, как зовут устройство:
Получается, что нам нужно устройство и busid, равным 1-5.4.1.3.
Всё, сервер готов к работе.
Вариант под актуальную версию Windows
Но как бы ни была хороша Windows 7, а она уже мертва. В рамках работ над All-Hardware мы рассматривали разные варианты решения одной из проблем, и надо было просто проверить ряд альтернатив по принципу «подойдёт — не подойдёт». Тратить много человеко-часов на проверку было невозможно. А переделка драйвера под Windows 10 могла затянуть в себя. Поэтому был проведён поиск в сети, который вывел на проект usbip-win. На момент его обнаружения свежий вариант был датирован 23 февраля 2020 года, то есть проект живой. Он может быть собран и под WIN7, и под WIN10. К тому же, в отличие от оригинального проекта, может быть собран не только Windows-клиент, но и Windows-сервер.
Я проверил, проект прекрасно собирается и устанавливается, поэтому дальнейшая работа велась с ним. В файле readme есть ссылка на готовый двоичный код для тех, кто не хочет самостоятельно производить сборку.
Грустная часть проверки: клиентская часть
В Windows устанавливаем драйвер (делаем это только один раз, дальше он будет всегда установлен). Для этого запускаем от имени администратора файл usbip.exe с аргументом install:
usbip.exe install
Теперь смотрим, доступно ли нам устройство:
Убеждаемся, что оно присутствует в списке. Ну, и подключаем его:
В менеджере устройств появляется новое USB-устройство, Keil его прекрасно видит…
Но на этом всё приятное кончается. Небольшая программа заливается во флэшку около минуты. Попытки шагать по строкам идут от 5 до 20 секунд на каждую строку. Это неприемлемо. Во время паузы в обе стороны идёт трафик примерно 50 килобит в секунду. Долго и вдумчиво идёт.
Честно говоря, ограничение по времени привело к тому, что я только предполагаю, почему всё было так плохо. Подозреваю, что там по сети бегает JTAG-трафик. А он бегает небольшими пакетами в обе стороны, отсюда и проблемы. Так было завершено исследование с результатом: «Для проекта не подходит».
Введение
Сначала краткий рассказ, что такое USB/IP. Это комплекс программ, которые позволяют пробросить USB-устройство через сеть. Само устройство подключено к серверу. Клиент располагается на другой машине. При этом на клиентской машине имеется приложение, совершенно не рассчитанное на работу с сетью. Оно хочет настоящее USB-устройство. И оно получает информацию, что это устройство подключено. На это устройство встаёт штатный драйвер. В общем, клиент считает, что он работает с локальным USB-устройством.
Кто-то так пробрасывает ключи защиты. Мы же проверяли возможность удалённого доступа к JTAG-адаптеру.
Проект USB/IP активно развивался до 2013 года. Затем Windows-ветка остановилась. В целом, был выпущен даже двоичный подписанный драйвер. Но он был под Windows 7. Linux-ветка же продолжила развитие, и этот сервис оказался встроенным в саму операционную систему. По крайней мере, в сборку Debian он точно встроен. Причём для Linux имеется и клиент, и сервер, а для Windows исходно был сделан только клиент. Сервер под Windows сделан не был.
Существует очень хорошая статья на Хабре, которую можно использовать и как справочник по работе с данным сервисом, и как отзыв о работе с ним.
Can't redirect USB to QEMU-KVM guest.
Hi all,
Came across this email exchange that describes issue i'm having with USB redirection to guests: http://lists.opensuse.org/opensuse-v. /msg00000.html
This is from February of this year and issue is still present. So i was thinking before going and creating bug report on bugzilla i would try my luck here, who knows, maybe i'm missing something very obvious.
Basically what i'm trying to do is to redirect connected to my system (host) USB drive to (qemu-kvm) virtual guest machine. From virtual machine viewer menu i select "Virtual Machine" -> " Redirect USB". Immediately i get list of all present USB devices, and the moment i chose one i get pop up window "USB redirection error" with following information:
Can someone help me out here?
thnx in advance.
Administrator
On Mon 06 Oct 2014 01:56:01 PM CDT, cyclingGeorgian wrote:
Hi all,
Came across this email exchange that describes issue i'm having with USB
redirection to guests:
http://lists.opensuse.org/opensuse-v. /msg00000.html
This is from February of this year and issue is still present. So i was
thinking before going and creating bug report on bugzilla i would try my
luck here, who knows, maybe i'm missing something very obvious.
Basically what i'm trying to do is to redirect connected to my system
(host) USB drive to (qemu-kvm) virtual guest machine. From virtual
machine viewer menu i select "Virtual Machine" -> " Redirect USB".
Immediately i get list of all present USB devices, and the moment i
chose one i get pop up window "USB redirection error" with following
information:
Code:
--------------------
g-exec-error-quark: Could not redirect Polar Electro Polar RC3 GPS
[0da4:0006] at 3-6: Failed to execute child process
"/usr/bin//spice-client-glib-usb-acl-helper" (No such file or
directory) (8) --------------------
Can someone help me out here?
thnx in advance.
Hi
Are the libsplice-client files installed?
Flux Capacitor Penguin
According to your error,
You probably don't have the required spice libraries installed.
I don't re-direct USB devices, so I haven't set up what you're trying to do so I don't know if you only need to install client libraries or if a spice server has to be setup as well. So I can't specify exactly which files you need (maybe install many packages in a shotgun approach?).
But,
Before you proceed further you might want to consider whether you really should be setting up USB pass through. It's rarely used (eg support a USB fingerprint scanner). In general you want to avoid any kind of hardware pass through because only one "machine" can utilize that resource at a time, ie if you setup pass through, then that device won't be available for other Guests and the Host.
For things like USB storage, you want to set it up as a USB device recognized by the Host, and then that storage can be setup as normal storage (attach new disk in Guest properties).
If you do continue to use a device that utilizes spice, you might want to read up on what spice is, and what it can provide. One cool feature is that the spice protocol can piggy back on TCP/IP so you can connect to remote USB devices.
New or Quiet Penguin
thnx guys for replies and sorry for staying away from my own thread for so long.
@malcolm - no i don't have libspice installed, and i can't find it, not in the "standard" factory repos anyway.
@tsu - it probably was unfortunate use of "usb drve" on my count, but it's not about storage but about my Polar RC3 sports watch that needs to be synced with server. and that thing works only on windows machines (virtual in my case). I have successfully used it in this fashion on Fedora 19/20, but since i moved to factory i got this error . And i wouldn't even think of attaching usb flash drive (storage) to virtual
Flux Capacitor Penguin
First step probably is to identify how your watch is classified. Generally all device detection starts with a general classification of the type of device. From there, different methods are applied to either mounting or interfacing with specific types of services.
Maybe some documentation on what is happening when attached to any other OS can provide some hints what your watch connection requires. Besides, even if you mounted your watch using hardware pass-through, you'd still need some kind of app to do whatever is desired? ie, transfer files? Sync services?
New or Quiet Penguin
Well, i don't know why i didn't do this at the very beginning, and i don't know how i came up with idea that libspice was not in repos - i wasn’t drunk or anything . but i search for a provider of spice-client-glib-usb-acl-helper, it happens to be spice-gtk. After installing it error went away and it seemed that usb redirect was successful. But it is not, since sync application is not peaking up on the watch, which normally would happened automatically and sync process would be initialized.
Whet i look at systemctl status libvirtd it shows me another error:
failed to execute /usr/lib64/libvirt/libvirt_leaseshelper: Permission denied
Can anyone elaborate on that? Maybe that's a problem??
New or Quiet Penguin
well. just noticed something.
as soon as i try to redirect usb i get authentication window before me telling me that redirecting usb is a privileged process. Right after entering root pw i get following error:
Есть USB-ЦАП/АЦП и софтина к нему, под онтопиком ни то, ни другое не работает. Софтина шибко проприетарная, защищена HASP ключом. Я пытаюсь заставить всё это работать в виртуалке. Собственно, девайсы:
Проблема: оба девайса в госте видны, но не работают. ЦАП/АЦП должен определяться как USB носитель, так он и определяется, но как-то не совсем. Дрова на HASP ключ в гостя поставил, но софтина его всё равно не видит. ЧЯДНТ?
Как то сложно ты usb пробрасываешь, попробуй так:
-usb -usbdevice host:16b2:1001
У меня до этого был другой АЦП/ЦАП, от National Instruments. Он в виртуалку пробрасывался и работал, но только вот так, с прямым маппингом физического девайса.
Axon ★★★★★ ( 22.12.15 19:29:01 )
Последнее исправление: Axon 22.12.15 19:29:18 (всего исправлений: 1)
Виртуалка виснет в биосе. Если убрать первый девайс (16b2:1001), то загрузка идёт и ключ работает. Ok, как теперь заставить работать сам АЦП/ЦАП?
qemu же жутко тормозной. Не лучше ли VirtualBox?
В какой вселенной?
Предыдущий АЦП у меня в виртаулбокс не пробрасывался, только в qemu.
Так. Если девайс отключить, запустить виртуалку с -usb -usbdevice host:16b2:1001 , а потом подключить его обратно, то ничего не виснет, но результат такой же, как и с моим вариантом. ЧЗХ?
Попробуй прокинуть не сам девайс, а root hub в котором нужный usb-разъём, а потом уже вставляй hasp.
qemu же жутко тормозной. Не лучше ли VirtualBox?
Попробуй прокинуть не сам девайс, а root hub в котором нужный usb-разъём
Видел как такое советуют, но способ так и не нагуглил. Как это сделать?
Очень давно так не делал, но, помнится, что также, как и отдельный девайс, по ID.
? Если так, то его проброс вообще ничего не даёт. Правда, например, мышка, которая у меня к нему же подключена, от хоста не отваливается. Похоже, что проброс почему-то не работает.
на archlinux-м форуме пипл через vfio-pci usb-контроллеры кидает, попробуй:
Это может сработать, только если процессор vt-d поддерживает.
King_Carlo ★★★★★ ( 22.12.15 20:27:20 )
Последнее исправление: King_Carlo 22.12.15 20:28:00 (всего исправлений: 1)
Делаю как там пишут, получаю vfio: error no iommu_group for device . Пишу конфиг загрузки модуля с указанием PCI ID всех контроллеров, собираю initcpio со всеми нужными модулями, ребутаюсь, ничего не меняется.
У меня вот так работает проброс (нашел решение после долгого гуглирования)
в ключах запуска qemu -device usb-host,vendorid=0x0529,productid=0x0001 и -readconfig /opt/ich9-ehci-uhci.cfg
Всё то же самое: HASP работает, АЦП/ЦАП - нет.
У него accel=kvm
И эти люди работают в обсер-ватории.
тред не читай @ сразу отвечай
Надо ядро грузить с параметром intel_iommu=on для интеля и iommu=1 iommu=pt для амд. Но и чипсет и сама мать должны поддерживать vt-d(iommu) для интеля(amd). Без неё pci-устройство ты не пробросишь.
А qemu какой чипсет по умолчанию эмулирует? Может, стоит попробовать указать q35(-M q35 вроде)?
Надо ядро грузить с параметром intel_iommu=on для интеля и iommu=1 iommu=pt для амд.
Intel, флаги при загрузке:
А qemu какой чипсет по умолчанию эмулирует? Может, стоит попробовать указать q35(-M q35 вроде)?
Yeah, baby! Заработало! Окончательный вариант строки запуска:
Я припоминаю, что с дефолтным вариантом у меня мышь logitech с родным софтом не работала, но потом всё ок и с g600 и g13. Но это было в самом начале экспериментов с пробросами. Тогда с pci-stub не сложилось и я перешел на vfio, а в гайдах везде советовали q35. И проблем с usb больше не было.
PS А у тебя в /sys/kernel/iommu_groups что-нибудь есть? Скорее всего ты в биосе не включил поддержку vt-d. Или пытался что-то неподходящее пробросить.
PS А у тебя в /sys/kernel/iommu_groups что-нибудь есть?
Нет. Но это уже не актуально, так как всё заработало через проброс отдельных USB девайсов, и необходимость возиться с целым контроллером отпала.
мне больше что-то кажется, что у него просто плата с говно H-B чипом, там бывают такие проблемы.
Более весёлая часть: подготовка
Чтобы не тратить на сервер целую PC, для проверки, я сделал этакий комплекс Yelloww (чисто по цвету пластика, из которого сделан корпус):
Роль сервера выполняет Raspberry Pi с установленной ОС Raspbian (это тот же Debian, а значит, там имеется требуемый сервер). Одна из «голубых пилюль» выступает в роли адаптера CMSIS DAP, вторая — в роли отлаживаемого устройства.
Точно так же ставим и настраиваем сервис. Разве что здесь список устройств, допустимых к экспорту, намного скромнее:
Понятно, что здесь экспортируем и импортируем устройство busid=1-1.4.
И вот тут конкретно с CMSIS DAP у меня периодически возникает небольшая проблемка. В менеджере устройств я вижу такую неприятность:
Напомню, что статья пишется по принципу «Лучше неплохая, но сегодня, чем идеальная, но завтра». Проблемы удалённой работы возникают прямо сейчас. Надеюсь, в обозримом будущем они уже будут не актуальны. А пока актуальны — показываю, как я обхожу данную проблему вручную. Сначала я отключаю устройство:
Затем сразу же включаю:
И оно начинает работать без проблем. В Keil меняем отладчик на CMSIS DAP:
При работе по локальной сети всё просто летает. Но понятно, что локальная сеть никому не интересна. Я попробовал пробросить порт устройства у себя дома, а затем удалённо зайти на машину на работе и потрассировать «прошивку» оттуда. Связь у моего домашнего провайдера весьма и весьма тормозная, особенно — от меня наружу. Прошивается контроллер примерно втрое медленнее, чем при прямом подключении к USB. Трассировка… Ну около секунды на строку, точно не больше. В общем, терпимо. С хорошими провайдерами, надеюсь, будет лучше.
Читайте также: