- Проброс USB устройств в виртуальную машину Hyper-V
- Особенности USB Passthrough в Hyper-V
- Проброс USB диска в виртуальную машину Hyper-V
- Проброс USB устройств через Enhanced Session Mode в Hyper-V
- Информационный портал по безопасности
- Проброс USB-портов из Windows 10 для удалённой работы
- Введение
- Вариант под актуальную версию Windows
- Грустная часть проверки: серверная часть
- Грустная часть проверки: клиентская часть
- Более весёлая часть: подготовка
- Заключение
Проброс USB устройств в виртуальную машину Hyper-V
Одним из существенных недостатков Hyper-Vперед другими гипервизорами (например, ESXi или Proxmox) являются отсутствие полноценной возможности пробрасывать USB устройства с хоста в виртуальные машины. Начиная с версии Hyper-V 2012 R2 появился ряд изменений, касающихся возможностей USB Passthrouth, однако этот функционал все еще уступает возможностям конкурентов. В этой статье мы расскажем об особенностях проброса USB устройств в Hyper-V.
Особенности USB Passthrough в Hyper-V
Под термином USB passthrough понимается возможность проброса USB устройства из хостового гипервизора (или по сети с другого сервера/устройства) в виртуальную машину. С помощью USB passthrough вы можете прокинуть внутрь ВМ токен, USB ключ, модем или любое другое оборудование, подключенное через USB порт.
Плохая новость в том, что в Hyper-V нет нормальной поддержки проброса USB устройств, вы не сможете пробросить любое USB устройство с физического хоста в виртуальную машину (в VMWare с этим на порядок лучше – см. статью USB passthrough в VMWare ESXi). Есть несколько встроенных возможностей использования USB устройства в Hyper-V, но у всех них есть существенные ограничения. На данный момент можно использовать следующие технологии для проброса USB устройства в Hyper-V.
- Проброс USB дисков с хоста Hyper-V;
- Расширенные возможности консоли Hyper-V — Enhanced Session Mode;
- Проброс USB устройства через RDP сессию;
- Использование программного/аппаратного средства для проброса USB по сети (USB over IP).
Проброс USB диска в виртуальную машину Hyper-V
Вы можете довольно просто пробросить подключенный к хосту USB диск напрямую внутрь любой запущенной виртуальной машины Hyper-V. Рассмотрим, как предоставить виртуальной машине Hyper-V прямой доступ к USB диску.
- Данная инструкция работает только для USB дисков, которые в системе видятся как fixed, т.е. флешки, смарт-карты и прочие removable-устройства прокинуть внутрь виртуальной машины не получится ( хотя есть небольшой трюк, позволяющий заставить Windows видеть сменное устройство как жесткий диск);
- Для таких дисков невозможно создать снапшот/чекпоинт.
- Подключите внешний USB диск к хосту Hyper-V (это может быть как любой хост с Windows и установленной ролью Hyper-V, так и Free Hyper-V Server). Диск появится в системе и ему будет назначена буква диска (если буква диска не назначилась, см. статью);
- Откройте консоль управления дисками Disk Management (diskmgmt.msc) на хосте Hyper-V. Щелкните правой кнопкой мыши по диску (левая колонка, в нашем примере USB диск размером 20 Гб имеет идентификатор Disk 1) и выберите Offline.
Все! Вы напрямую пробросили внешний USB диск внутрь виртуальной машины Hyper-V и можете его использовать.
Для безопасного извлечения USB диск можно открыть консоль Hyper-V Manager и перейти в окно настроек виртуальной машины. В разделе SCSI Controller выберите жесткий диск, который нужно удалить и нажмите Remove. Сохраните изменения. После этого жесткий диск можно физически извлечь из USB порта хоста Hyper-V.
Проброс USB устройств через Enhanced Session Mode в Hyper-V
В версии Hyper-V, представленной в Windows Server 2012 R2/ 8.1 практически любые USB устройства можно прокинуть внутрь виртуальной машины с помощью технологии Enhanced Session Mode (ESM). Для подключения используется утилита Hyper-V Manager vmconnect.exe . Она позволяет подключится к консоли виртуальной машины и выбрать USB устройства, которые нужно пробросить.
Сначала нужно включить Enhanced Session Mode в настройках сервера Hyper-V. Это можно сделать с помощью PowerShell:
Set-VMHost -EnableEnhancedSessionMode $true
Или в меню Hyper-V Settings -> Enhanced Session Mode.
Перезапустите службу Hyper-V Virtual Machine Management:
Get-Service vmms | Restart-Service
В разделе Integration Services настроек ВМ нужно включить опцию Guest Services.
Для проброса USB устройства через Enhanced Session Mode нужно запустить консоль Hyper-V, выбрать ВМ и нажать Connect. Либо вы можете запустить утилиту vmconnect.exe (Virtual Machine Connection), указать Hyper-V сервер и имя ВМ (утилита поддерживает некоторые параметры командной строки, поэтому вы можете отдавать пользователям настроенный bat файл).
Ели ВМ поддерживает Enhanced Session Mode, появится окно, похожее на свойства RDP подключения. Нажмите Show Option -> Local Resources -> Local device and resources -> More.
Выберите USB устройства на вашем компьютере, которое нужно пробросить в ВМ. Если устройства, которое вам нужно, сейчас не подключено, выберите опции Other supported Plug and Play (PnP) devices и Devices that I plug in later.
Теперь все подключённые к вашему компьютеру USB устройства будут автоматически доступны в консольной сессии виртуальной машины Hyper-V.
Основные возможности и ограничения Enhanced Session Mode
- В качестве гостевых ОС поддерживается только Windows (начиная с Windows 8.1/Windows Server 2012 R2);
- Вам не нужен прямой доступ к ВМ. Все подключения выполняются через Hyper-V хост (вы подключаетесь к нему через сеть по порту TCP 2179), а подключение к ВМ выполняется через шину VMBus;
- На компьютере пользователя должен быть установлен Hyper-V Manager
Методы проброса USB устройства через сеть (USB over IP или в RDP сессии) позволяют сохранить доступ к USB ключу при миграции виртуальной машины на другой хост (Hyper-V Live Migration /vMotion).
Информационный портал по безопасности
Проброс USB-портов из Windows 10 для удалённой работы
Когда человек много лет рыл бункер и запасал там продукты, он должен испытывать глубокое моральное удовлетворение, если бункер понадобился. Он будет довольный заявлять: «А я говори-и-и-ил!» То же касается и того, кто делал запасы продуктов в кладовой, когда все закупались в магазинах только на сегодня. А вот с нашим комплексом для удалённой работы Redd как-то и не хочется злорадствовать. Он проектировался для удалёнки в мирное время. И использовался задолго до первых новостей из Китая.
Давно я про него ничего не писал. Другие проекты отвлекают, да и интерес, судя по рейтингу последней из опубликованных статей, уже упал. Сил на подготовку статьи отнимают много, и это имеет смысл делать только если оно нужно достаточному числу читателей.
Но так как сейчас удалёнка у всех на устах, возникло желание поделиться одной наработкой, которая может кому-то помочь. Это не наша разработка, я проводил исследования в рамках работы над сервисом удаленной работы с отладочными платами All-Hardware. Вот их результаты сейчас и опишу. Проект USB/IP известен многим. Но он давно свёрнут авторами. Самые свежие драйверы были под WIN7. Сегодня я опишу, где скачать вариант для WIN10, и покажу, как я его проверял. Кроме того, разработчики современного аналога уверяют, что у них сделан не только Windows-клиент, но и Windows-сервер (правда, в этом режиме я тестирование не вёл: задача того не требовала). Но кому-то это тоже может оказаться полезным.
Разработка простейшей «прошивки» для ПЛИС, установленной в Redd, и отладка на примере теста памяти.
Введение
Сначала краткий рассказ, что такое USB/IP. Это комплекс программ, которые позволяют пробросить USB-устройство через сеть. Само устройство подключено к серверу. Клиент располагается на другой машине. При этом на клиентской машине имеется приложение, совершенно не рассчитанное на работу с сетью. Оно хочет настоящее USB-устройство. И оно получает информацию, что это устройство подключено. На это устройство встаёт штатный драйвер. В общем, клиент считает, что он работает с локальным USB-устройством.
Кто-то так пробрасывает ключи защиты. Мы же проверяли возможность удалённого доступа к JTAG-адаптеру.
Проект USB/IP активно развивался до 2013 года. Затем Windows-ветка остановилась. В целом, был выпущен даже двоичный подписанный драйвер. Но он был под Windows 7. Linux-ветка же продолжила развитие, и этот сервис оказался встроенным в саму операционную систему. По крайней мере, в сборку Debian он точно встроен. Причём для Linux имеется и клиент, и сервер, а для Windows исходно был сделан только клиент. Сервер под Windows сделан не был.
Существует очень хорошая статья на Хабре, которую можно использовать и как справочник по работе с данным сервисом, и как отзыв о работе с ним.
Вариант под актуальную версию Windows
Но как бы ни была хороша Windows 7, а она уже мертва. В рамках работ над All-Hardware мы рассматривали разные варианты решения одной из проблем, и надо было просто проверить ряд альтернатив по принципу «подойдёт — не подойдёт». Тратить много человеко-часов на проверку было невозможно. А переделка драйвера под Windows 10 могла затянуть в себя. Поэтому был проведён поиск в сети, который вывел на проект usbip-win. На момент его обнаружения свежий вариант был датирован 23 февраля 2020 года, то есть проект живой. Он может быть собран и под WIN7, и под WIN10. К тому же, в отличие от оригинального проекта, может быть собран не только Windows-клиент, но и Windows-сервер.
Я проверил, проект прекрасно собирается и устанавливается, поэтому дальнейшая работа велась с ним. В файле readme есть ссылка на готовый двоичный код для тех, кто не хочет самостоятельно производить сборку.
Грустная часть проверки: серверная часть
Сначала я расскажу, как проводилась проверка в рамках нашего проекта. Там всё кончилось не очень хорошо. Проверяли адаптер ST-LINK, установленный в корпус комплекса Redd, благо я уже отмечал, что в комплексе используется ОС Linux сборки Debian, а эта сборка содержит встроенный сервис USB/IP.
Согласно статье, устанавливаем сервис:
Дальше в статье подробно рассказано, как автоматизировать процесс загрузки сервиса. Как я разбираюсь в Линуксе, я уже многократно писал. Плохо разбираюсь. У меня нет привычки с умным лицом цитировать чужие тексты, слабо понимая суть. Поэтому я ещё раз напомню ссылку на замечательную статью, где всё рассказано, а сам покажу, что делал я при каждом старте ОС (благо всё было нужно только для проверки):
Назначение первых двух из вышеприведённых заклинаний мне неизвестно, но без них не создаются какие-то каталоги, а без этих каталогов потом не будет экспорта USB-порта. Каталоги создаются только до перезапуска системы. Так что создавать их надо каждый раз. Третья строка — с нею всё понятней, она запускает сервис.
Теперь смотрим, как зовут устройство:
Получается, что нам нужно устройство и busid, равным 1-5.4.1.3.
Всё, сервер готов к работе.
Грустная часть проверки: клиентская часть
В Windows устанавливаем драйвер (делаем это только один раз, дальше он будет всегда установлен). Для этого запускаем от имени администратора файл usbip.exe с аргументом install:
Теперь смотрим, доступно ли нам устройство:
Убеждаемся, что оно присутствует в списке. Ну, и подключаем его:
В менеджере устройств появляется новое USB-устройство, Keil его прекрасно видит…
Но на этом всё приятное кончается. Небольшая программа заливается во флэшку около минуты. Попытки шагать по строкам идут от 5 до 20 секунд на каждую строку. Это неприемлемо. Во время паузы в обе стороны идёт трафик примерно 50 килобит в секунду. Долго и вдумчиво идёт.
Честно говоря, ограничение по времени привело к тому, что я только предполагаю, почему всё было так плохо. Подозреваю, что там по сети бегает JTAG-трафик. А он бегает небольшими пакетами в обе стороны, отсюда и проблемы. Так было завершено исследование с результатом: «Для проекта не подходит».
Более весёлая часть: подготовка
Ещё тогда мне запало в голову, что я краем глаза видел, что в JTAG-адаптере CMSIS DAP по USB ходит не чистый JTAG-трафик, а команды. Сам JTAG-трафик формируется уже внутри адаптера. Давно хотел проверить это, да всё руки не доходили. Массовый перевод на удалёнку заставил это сделать (возникла задачка). Что такое CMSIS DAP? Это JTAG-адаптер, рекомендованный самой компанией ARM для контроллеров Cortex-M. Исходные коды для разных контроллеров выложены на GitHub, можно спаять адаптер на базе любого из них. Я сейчас дам ссылку на клон проекта, адаптированный под макетную плату «Голубая пилюля»: https://github.com/x893/CMSIS-DAP, но поисковые системы могут вывести и на официальный аккаунт ARM.
Чтобы не тратить на сервер целую PC, для проверки, я сделал этакий комплекс Yelloww (чисто по цвету пластика, из которого сделан корпус):
Роль сервера выполняет Raspberry Pi с установленной ОС Raspbian (это тот же Debian, а значит, там имеется требуемый сервер). Одна из «голубых пилюль» выступает в роли адаптера CMSIS DAP, вторая — в роли отлаживаемого устройства.
Точно так же ставим и настраиваем сервис. Разве что здесь список устройств, допустимых к экспорту, намного скромнее:
Понятно, что здесь экспортируем и импортируем устройство busid=1-1.4.
И вот тут конкретно с CMSIS DAP у меня периодически возникает небольшая проблемка. В менеджере устройств я вижу такую неприятность:
Напомню, что статья пишется по принципу «Лучше неплохая, но сегодня, чем идеальная, но завтра». Проблемы удалённой работы возникают прямо сейчас. Надеюсь, в обозримом будущем они уже будут не актуальны. А пока актуальны — показываю, как я обхожу данную проблему вручную. Сначала я отключаю устройство:
Затем сразу же включаю:
И оно начинает работать без проблем. В Keil меняем отладчик на CMSIS DAP:
При работе по локальной сети всё просто летает. Но понятно, что локальная сеть никому не интересна. Я попробовал пробросить порт устройства у себя дома, а затем удалённо зайти на машину на работе и потрассировать «прошивку» оттуда. Связь у моего домашнего провайдера весьма и весьма тормозная, особенно — от меня наружу. Прошивается контроллер примерно втрое медленнее, чем при прямом подключении к USB. Трассировка… Ну около секунды на строку, точно не больше. В общем, терпимо. С хорошими провайдерами, надеюсь, будет лучше.
Заключение
Проект usbip-win является современной заменой для проекта USB/IP. Он живёт и развивается. При этом он предоставляет для ОС Windows не только функцию клиента, но и функцию сервера. Совместимость с Linux-версией сохранена.
Устойчивость работы удалённого USB-устройства неожиданно поразила. Я был уверен, что возникнут таймауты. Возможно, где-то они и возникнут, но для JTAG-адаптеров не было замечено ни одного сбоя. К сожалению, не все USB-устройства могут быть проброшены через сеть по причине низкого быстродействия получившейся системы. Но в случае с JTAG-адаптерами можно рассмотреть альтернативные вещи. В частности, CMSIS-DAP вместо ST-LINK.
Оба рассмотренных проекта (usbip-win и CMSIS-DAP) могут быть скачаны с GitHub в виде исходных кодов.
Если это поможет кому-то организовать удалённый доступ к оборудованию, я буду рад. Использование Raspberry Pi позволит бросить оборудование в произвольных местах.
