Proxmox проброс usb в виртуальную машину
Proxmox проброс usb в виртуальную машину
Немного теории о usb:
Наша задача выяснить, на какой шине (bus) и к какому порту (port) подключены наши usb-устройства. В качестве примера приведён проброс двух ключей HASP 1С Предприятия 8 (серверный и клиентский)
Далее есть два способа выяснения связки шина-порт:
а) В консоли proxmox сервера выполняем “lsusb”. В результате выясним имя устройств и найдём среди них свои:
Искомое: 2 ключа Aladdin Knowledge Systems HASP v0.06 на шине 6
Как видим, устройства (Device) 2 и 3 на шине 6 находятся на портах 1 и 2. Соответственно, пробрасывать будем 6-1 и 6-2.
Выполняем “qm monitor НОМЕР_ВИРТУАЛЬНОЙ_МАШИНЫ”,
Теперь выполняем команду “info usbhost”
Вот они наши HASP-ключи, опять же на шине 6 и портах 1 и 2.
Выходим командной quit либо сочетанием Ctrl+C
Редактируем на сервере файл /etc(/pve)/qemu-server/NNN.conf (где NNN-номер виртуальной машины) и добавляем следующие строки:
Для версии proxmox 2.0 **
Перезагружаем виртуальную машину.
Проверить, подцепились ли устройства, можно снова зайдя в qm monitor (как в п. 2б) и выполнив команду “info usb”
P.S. Также usb-устройство можно подключить, добавив в конец NNN.conf такое:
Плюсы: при перемещении usb-устройства в другой порт не надо ничего перенастраивать;
Минусы: этот способ не годится, если у вас несколько устройств с одинаковыми device ID, как в указанном выше примере
USB Devices in Virtual Machines
Contents
Introduction
There can be good reasons to access to USB hardware directly from a guest as it would be part of the VM itself, e.g.:
The assignment of such devices can be predefined in the configuration file or «plugged» into the VM while it is running.
Simple Way: pass the USB device ID to the guest
Assigning an Alcor memory stick connected to the host to VM 804.
Figure out in the host the Device Type by
Assign it to the VM by
Shutdown the VM (if running) and start it again.
Alternate way: pass the USB port to the guest
Example
In order to demonstrate how devices, physically connected to the host can be identified it´s assumed the following 7 USB devices are currently connected:
Show Device Types
This is the simplest form and sufficient in most cases.
The numbers on the far right refer to the previously defined example. The other entries are the USB hubs of the system.
Note that the «Device» number is just a number assigned automatically by the host, independent where the device is connected to. If the device is removed and plugged in again it gets a new number.
Show Device Map and Types
Sometimes it is necessary to specify where a device is physically connected. This information can be obtained by
in case of our example it is
The devices behind the external hub have port addresses 1.2.x
This form shows also the currently used USB protocol (btw: even the device (6) calls itself «USB 2.0 10/100M Ethernet Adaptor» it works only as USB 1.1 device)
Just the map can be displayed by
but it´s sometimes not complete and not recommended.
Complete Information
Assigning Devices to VMs
Note that only «real» devices can be assigned, i.e. assigning of USB hubs is not possible.
In Configuration
General Remark
Using the below mentioned «qm set» command has the same effect as writing directly into the conf file. Moreover a preconfigured usb configuration file /usr/share/qemu-server/pve-usb.cfg could be adapted. But in order to avoid confusion this article recommends to use only the «qm set» command.
USB1.x, USB2.0
The syntax for assigning in configuration is (see also man page for qm)
According to the above example let´s say the Alcor stick and the Cruzer Edge connected to the external hub (which is device (4) from the example) should be assigned to VM 804:
For the Alcor stick (as already shown):
When the usb devices have to be removed from configuration the conf file has to be changed. In our example remove in /etc/pve/qemu-server/804.conf the following two lines:
USB3.0
since qemu-server package version 4.0-55 you also can set USB3 devices directly via the command line
it will automatically add the appropriate xhci controller at an available pci address
for any version 1 Device
The external Toshiba drive should be assigned VM 804 and work with USB 3.0 protocol on a USB 3.0 port.
Note that «addr=0x5» works only if there is no other device assigned to this address. If a failure occurs because of double use of this address choose another one.
When the usb device has to be removed from configuration the conf file has to be changed. In our example remove in /etc/pve/qemu-server/804.conf the following line:
More Devices
For one machine only one «-args» argument is possible. If already an «-args» advice was given giving another one overwrites the first. Moreover, the usb3 driver needs only to be defined once. In the following example 2 USB3 devices are assigned to the VM, the second one has the ID 1058:0820
Assign Devices to an already Running VM
How to connect devices to a running machine without shutting it down is demonstrated by the examples from above. If device is assigned in that way the assignment is valid until the machine stops. The assignment is independent of the actual status of the device (whether it´s currently plugged in or not), i.e. it can be plugged in and out multiple times and will be always assigned to the VM; regardless if the «Productid» or «busaddress» method is used.
USB1.x, USB2.0
Note that the «usb_add» command offered in «qm monitor» is NOT FUNCTIONING for this case!
someid and someotherid are ids of your choice, those can later be used to remove the usb device from the guest
USB3.0
anotherid is chosen by you, so the device can later be removed again
Reassign to Host
To remove an USB device from a guest do the following:
now your USB device should be removed from your guest and reappear on the host, until you stop and start the VM again
to remove the USB device from the config of a VM, do
where usbX is the id of the USB device
caution: this does not remove the usb device from a running VM
Проброс USB в Proxmox
На данный момент установлен Proxmox 3.4, но судя по официальной документации, данные инструкции верны начиная с 2,х версий.
Вроде бы, зачем еще что-то писать, когда есть официальная инструкция? Однако, здесь есть кое-что, чего там нет. Есть два вариант передачи USB-устройства в гостевую систему:
Проброс USB-устройств
Если имеется USB ключ защиты, или внешний накопитель, то удобней передавать в гостевую систему непосредственно само устройство, вне зависимости от того, к какому USB-порту это устройство подключено физически. Ведь при обслуживании, мы можем в следующий раз подключить в другой разъем.
Находим нужное нам устройство и берем его ID, который и будем использовать.
У меня стояла задача пробросить UPS-ы.
(Ситуация, на самом деле не типовая, скорее из серии как быть не должно: На сервер и сетевое оборудование поставлены 2 самый простых безперебойника для рабочих станций. UPS-ы оказались нежными и начинали голосить по поводу и без. Чтоб быстро подрезать им голос и пока не разбираться с управлением ИБП из Debian и было решено подцепить два безперебойника к Windows-гостям.)
На этом этапе я обнаружил, что оба нужных мне устройства имеют одинаковые ID… Но пробуем.
Пробрасываемые устройства прописываются в конфигурационном файле соответствующей виртуальной машины.
Перезагрузил. Устройство подцепилось, вроде бы все хорошо. Но тут вспоминаем, что второе устройство с таким же идентификатором. Как их различать? И действительно, опыт показал, что если в две виртуальные машины прописать один идентификатор, то они при включении будут отбирать друг у друга одно и то же устройство. Не смотря на то, что в host-системе есть несколько USB-устройств с таким идентификатором.
Вот тут то мы и вспоминаем, что есть другой способ проброса.
Проброс USB-портов
Необходимо определить к какому именно порту подключено нужное нам устройство.
Как позже выяснилось, нужные мне устройства сидят на шине 3, порты 7 и 8. Но пока нам это не очевидно и вот вариант второй:
Тут мы наглядно видим кто есть кто. И теперь смело:
Для полноты картины, дополню инструкцию примером из официальной документации.
Возможен такой вариант:
тогда в файле конфигурации ВМ надо писать следующим образом:
Теперь, зная все варианты, можем использовать тот, который лучше под текущую ситуацию.
USB проброс в Proxmox
Рассмотрим вариант подключения в виртуальную машину USB устройства. Вариаций этих устройств множество и все их можно без проблем подключить к требуемой виртуальной машине. В системе виртуализации Proxmox делается это быстро и просто.
Для 5 версии Proxmox
С выходом новой версии проброс USB устройств сильно упростился. Нам достаточно выбрать виртуальную машину, добавить устройство указав вариант его проброса по порту или id.
Для 4 версии Proxmox
С инструкцией по подключению USB устройств вы можете ознакомится на официальном сайте Proxmox.
Определение устройства
Подключим в систему Proxmox необходимое устройство и в консоли выведем информацию о подключенияx.
Видим подключенную флэшку.
Выведем информации о том на каких портах висят устройства.
Видим нашу флэшку которая села на Bus 01 — Dev 5 на Port 3.
Варианты проброса устройств
Существуют два вариант передачи USB-устройства в виртуальную (гостевую) систему:
Оба варианта имеют свои нюансы и решать каким пользоваться только вам. Мне больше нравится вариант с пробросим порта, так как он не вызывает непонятных проблем после перезагрузки.
Проброс осуществляются по номеру виртуальной машины. Папка с файлами для редактирования находится по адресу /etc/pve/qemu-server/ в ней вы увидите все ваши виртуальные машины.
Проброс USB устройства
Откроем необходимый файл и добавим нужные параметры.
Проброс USB порта
Для проброса по порту надо указать другую строчку в необходимом файле.
После перезагрузки устройства будут проброшены.
Результат
В новой 5-ой версии все упрощается но знать механизм как это работает изнутри всегда хорошо. Можно определять подключенные USB устройства командой «qm monitor НОМЕР_ВИРТУАЛЬНОЙ_МАШИНЫ» и после подключения вводить команду «info usbhost» или «info usb». Мне этот вариант показался не совсем логичным, так как требует указывать номер виртуальной машины, но при разных вариантах ввода номера машины показывает одинаковую информацию. Делая по рассмотренному способу, у меня всё работает. Главное не способы а результат!
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Читая их я получаю информацию которая позволяет мне улучшить качество написания статей. Кроме того, оставляя комментарии вы помогаете сайту получить более высокий рейтинг у поисковых систем. Давайте общаться.
2 комментариев для статьи “ USB проброс в Proxmox ”
Очень просто. Hyper-V это не умеет делать до сих пор 🙁
Наверно у него есть другие преимущества которых нет в Proxmox.
OpenVZ в Proxmox, заметки на полях
1. Проброс различных возможностей и устройств из гипервизора в контейнер OpenVZ
1.1.Проброс fuse
На гипервизоре выполнить:
Остановить контейнер OpenVZ
, где [VEID] номер контейнера, после чего монтирование в контейнере работает.
1.2. Проброс NFS
На гипервизоре:
Устанавливаем nfs сервер
например экспортируем /var/lib/vz для 10.1.1.2
перезапускаем nfs сервер
Добавляем поддержку nfs в контейнер
1.3. Проброс USB-устройств
Во всех случаях проброса устройств, если устройств более одного, лучше напрямую править конфиг контейнера, а не использовать vzctl, дело в том, что если вы не поместили все необходимые устройства сразу в одну строку, то vzctl затрет все предыдущие пробросы и установит только последний.
где b — блочное устройство, c — символьное. major:minor необходимо посмотреть в /dev/bus/usb для конкретного устройства.
Проброс по имени
Либо правкой конфига:
Для проброса USB-устройства в запущенный контейнер необходимо:
Смонтировать из хост-системы в контейнер
1.4. Проброс звуковой карты (как встроенной так и usb)
Во многом похоже на проброс обычного usb устройства, но с некоторыми отличиями.
На гипервизоре:
Ставим модули ядра для работы со звуком
Если USB звуковая, то еще
Убедимся что модули подключились
должен отобразиться список всех подключенных модулей для работы со звуком
Добавляем в конфиг виртуалки
Если это не первое пробрасываемое устройство, то команда затрет предыдущие, тогда
правим фаил
добавляем в него строку
Выводим список всех snd устройств
Заходим в контейнер
(Обращаем внимание что номера устройств и имена должны совпадать с таковыми на гипервизоре)
Теперь нужных пользователей контейнера добавляем в группу audio
1.5. Проброс X’ов
Заходим в контейнер через vzctl (не SSH)
делаем симлинк
Удаляем если установлен nscd
Ставим нужные пакеты
Приводим /etc/X11/xorg.conf к виду
1.6. Проброс раздела диска
Принцип аналогичен предыдущим, но сделаем это по имени, например пробросим sda4
1.7. Включение tun/tap
Если мы хотим использовать vpn внутри контейнера, то без этого не обойтись.
Проверяем подгружен ли модуль
Если нет подгружаем
С пробросами закончили, остальное делается примерно так-же.
Фаирвол
В стандартном варианте фаирвол для контейнеров очень урезан по функционалу, попробуем это исправить.
Комментируем текущую строку IPTABLES и вместо нее добавляем
сохраняемся и перезапускаем VZ
После этого внутри контейнеров мы сможем нормально настроить фаирвол.
Добавляем модули, касающиеся фаирвола, при загрузке ядра на гипервизоре (лишний шаг, но на всякий случай)
Фаирвол на самом гипервизоре
case «$1» in
start)
echo «Starting iptables»
;;
stop)
echo «Stopping iptables»
3. Разные мелочи
Правильный часовой пояс в контейнерах
Убираем бесполезное сообщение при входе в гипервизор через web-интерфейс.
В файле /usr/share/pve-manager/ext4/pvemanagerlib.js находим строку
Иногда с квотами возникает неприятность Proxmox: ‘exit code 60′ – corrupt quota file и виртуалка не стартует,
просто перезапустим квоты.
Команды управления OpenVZ
Старт [VEID] ОС
Подключаемся гостевой ОС
Если у кого-то возникали другие нестандартные ситуации при работе с контейнерами, буду рад пополнить свои заметки, вдруг столкнусь в дальнейшем.
Проброс виланов в контейнер делается в 2 этапа. Покажу на примере виланов 151,152,666
На гипервизоре:
В /etc/network/interfaces
Устанавливаем поддержку виланов
Затем применяем их
Проверяем что интерфейсы поднялись через ifconfig
Затем в вебморде выбираем нужный контейнер, идем на закладку сеть(network), добавляем сетевое оборудование, примерно как на скриене 
в качестве бриджа выбираем интерфейс с нужным виланом.
Просто настройки на интерфейсе, которые должны быть на вилане, пример для контейнера на debian
В /etc/network/interfaces.tail
Файл *.tail нужен для того, чтоб если мы изменим настройки сети в контейнере через web интерфейс, сохранить настройки виланов внутри контейнера.
Есть и другой вариант проброса виланов, но я использую такой, так-как при нем можно использовать удобно один и тот-же вилан в нескольких виртуалках, что часто нужно.