Не устаю повторять, типичный случай, когда обмазываются гуйками и вообще не рубят как работает qemu-kvm.

Это вообще возможно?

Это не только возможно, но и элементарно. Хочешь устройство, хочешь порт, а хочешь и целый хаб. Как? Почитай документацию qemu-kvm, а не костылей.

Делаю через virt-manager

Ничего не надо пробрасывать. В окне запущенной виртуальной машины делаешь «виртуальная машина -> переадресация USB» выбираешь свою флэшку.

элементарно, но не скажу как

Очень информативно с вашей стороны. Если бы документация дала ответ на мой вопрос, я бы здесь его не задавал. И о каких костылях речь, о virt-manager? Так это продукт RedHat. Если это костыль, следовательно qemu/kvm - тоже «костыль»?

А вот мой файл, который соответствует документации для проброса:

$ sudo cat /etc/libvirt/qemu/win7.xml | grep -i «'subsystem' type='usb'» -A 6
<hostdev mode='subsystem' type='usb' managed='yes'>
<source>
<vendor id='0x0781'/>
<product id='0x5567'/>
</source>
<boot order='2'/>
</hostdev>

В окне запущенной виртуальной машины делаешь «виртуальная машина -> переадресация USB» выбираешь свою флэшку.

Уточню. Подключаюсь через virt-manager удалённо по SSH. Если вставить флешку в компьютер, с которого подключаюсь, конечно «переадресация USB» работает. Но флешка вставлена в сервер, на котором крутятся виртуалки и она не отображается в списке предлагаемых для переадресации.

А вот мой файл
xml-лапша, привет из java мира

сравни, черт возьми, порт:

-device usb-host,hostbus=8,hostport=1

-usb -usbdevice host:04f3:0216

--device usb-host,vendorid=0x04f3,productid=0x0216

А вписывать-то это куда, после «qemu-system-x86_64-spice -enable-kvm» ? И так каждый раз? А всё остальное железо? И в результате командная строка длинной в километр?

Полный xml-конфиг виртуалки в студию - это раз. Два - как определяешь что ничего не видно в венде? А если загрузиться с live cd и проверить по lsusb?

Готовая виртуалка с Kubuntu. Добавлен USB Host Device в госте. Там же:

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

XML-конфиг

после «qemu-system-x86_64-spice -enable-kvm» ?

Да.

И так каждый раз?

Ну да, запускаешь файл виртуалки, например:

/mnt/vm/vm.sh

Вот команда запуска моей виртуалки:

qemu-system-x86_64 -enable-kvm -name Kubuntu16.04 -S -machine pc-q35-2.5,accel=kvm,usb=off -cpu Haswell-noTSX -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d77f8813-66e9-470f-954d-1d3e72c5d55d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-Kubuntu16.04/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x3 -drive file=/var/lib/libvirt/images/Kubuntu-16.04.x-x86_64-14GiB.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:55:f9:4d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device usb-host,hostbus=3,hostaddr=2,id=hostdev0 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on

Как видно строка:

-device usb-host,hostbus=3,hostaddr=2,id=hostdev0

присутствует. Но нет этого устройства в системе или оно не видно по какой-то причине.

pc-q35-2.5,accel=kvm,usb=off

usb=off

зачем это здесь?

-usb

    Enable the USB driver

зачем это здесь?

я незнаю почему virt-manager подставляет этот параметр, но с такой километровой командой, если вставить её в терминал, запускаться виртуалка не хочет:

qemu-system-x86_64: -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-Kubuntu16.04/monitor.sock,server,nowait: Failed to bind socket to /var/lib/libvirt/qemu/domain-Kubuntu16.04/monitor.sock: No such file or directory

я незнаю почему virt-manager

опять костыли? Конечно не знаешь, ведь не ты делаешь, это всё равно, что позволить чему-то генерировать ~/.bashrc, fstab и т.п., virt-manager и прочее что угодно могут тебе накостылять, наломать.

Для работы qemu-kvm вообще не нужны virt-manager, libvirt и прочее, только qemu-system-*.

Самый простой способ разобраться, дебажить и т.п. это начинать с простого:

#!/bin/bash

QEMU="/usr/bin/qemu-system-x86_64"

${QEMU} \
    -enable-kvm \
    -m 5120 \
    -machine q35,accel=kvm \
    -cpu host,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 \
    -smp 4,sockets=1,cores=4,threads=1 \
    -realtime mlock=off -rtc base=localtime \
    -drive if=pflash,format=raw,readonly,file=/mnt/vm/OVMF/OVMF-pure-efi.fd \
    -drive if=pflash,format=raw,file=/mnt/vm/OVMF/OVMF_VARS-pure-efi.fd \
    -nodefaults \
    -vga none \
    -cdrom /mnt/vm/img/drivers.iso

Нет, я конечно понимаю, что в идеале, чтобы всё понимать, нужно вообще выпилить и выбросить графику и сидеть в голом терминале. Но как если нужно сейчас и времени нет на дебаги и тем более постепенные доведения виртуалки до нужной кондиции?

Слушай, я сходил воткнул флэшку в сервер, сейчас подключился к серваку virt-manager-ом, добавил usb host device и виртуальная винда отлично увидела флэшку. virt-manager 1.2.1

Нет, просто чтобы разобраться что не так и почему не работает (это ведь смысл треда?) — нужно понимать, как работает qemu.

Я не могу найти соотв. пример, т.к. у меня температура 38.6 сейчас, но я думаю ты меня понимаешь.

Нет ничего проще qemu, а в терминал идут выхлопы, возможно там найдешь интересующую тебя инфу почему не работает.

Ты уже времени больше потратил на этот тред, чем запуск твоей машины вручную, серьезно. На порядок.

У меня virt-manager 1.3.2, откатиться что-ли...

virt-manager вполне себе удобный инструмент, а вся эта дичь с прямыми вызовами qemu нужна была мне один раз - проброс видеокарты в ВМ.

Ты заметил что ты не потратил время на изучение и в итоге делал это гораздо дольше, чем если бы ты прочел ман? Хорошо в тред зашел slon, а если бы у тебя инета небыло?

Порой конечно вхождение слишком тяжело дается и приходиться начинать с метода тыком... Пока тыкаешь узнаешь как примерно хотя бы рабоатет.

мой virt-manager про usb-флэшку в xml-конфиг добавил вот такой блок:

 <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x058f'/>
        <product id='0x6387'/>
      </source>
 </hostdev>

Какой конкретно мэнуал я должен был прочесть? Везде конкретно указывают править XML-файл с настройками виртуалки. Это я хорошо прочёл. И что я делал гораздо дольше и по сравнению с чем? Моя проблема до сих пор не решена. Что с чем сравнивать? P.S. И да, я рад, если вам хорошо от того, что кто-то зашёл в ветку.

У меня то (linux.org.ru) же самое добавляет. Так, сейчас буду откатываться с PPA.

Проблема не решена? Ошибки есть при старте? Девайс точно правильный пробрасываешь?

man qemu-system-x86_64

Если у тебя такой же конфиг генерит, то, по идее, откат вирт-манагера ничего не даст.

Алсо ты можешь их пробрасывать на лету.

Глянь мои скрипты, вдруг что-то полезное найдешь. Там есть add_mouse.sh и keyboard https://github.com/matrixd/kvm

ТС вроде как русским языком написал, что он хочет virt-manager-ом через libvirt.

ок ок, сваливаю из треда. Удачи вам там с угадыванием проблемы. Суде по всему ТС еще и логи не хочет смотреть.

Cпасибо, буду иметь ввиду и использую.

Там не только он, также и qemu, libvirt.

Так это продукт RedHat. Если это костыль, следовательно qemu/kvm - тоже «костыль»?

virt-manager управляет частью фичеров libvirt, который сам по себе не qemu-kvm а библиотека которая его (и другие гипервизоры) контролирует. Выше пропагандируют отбросить библиотеку и рулить qemu-kvm напрямую, что, имхо - полное красноглазие. Но вот понимать как что работает тем не менее надо. Простой дебаг - запустить машину, посмотреть на ps -ef |grep qemu ее реальный cmdline и сравнить с адресами usb из dmesg

люди отказались от такой наркомании почти 10 лет назад. libvirt-ом надо пользоваться, просто надо понимать что делаешь

Выше пропагандируют отбросить библиотеку и рулить qemu-kvm напрямую, что, имхо - полное красноглазие. Но вот понимать как что работает тем не менее надо.

Полностью согласен.

Простой дебаг - запустить машину, посмотреть на ps -ef |grep qemu ее реальный cmdline и сравнить с адресами usb из dmesg

Сравнил же. Там какая-то другая ошибка вылезает, если запускать из терминала, на файл сокета, который действительно отсутствует. Такое громадное кол-во опций дуплить очень долго придётся.

Откат не помог.

для начала просто запустить virt-manager локально, хотя бы через ssh -XY, a не подключаться удаленно локальным virt-manager-ом

Локально тоже ничего не происходит, когда я запускаю лежащую на моём локальном компе виртуалку и добавляю в неё USB Host Device. Припоминаю, однажды я уже это пробовал, оно вообще никогда у меня не работало. Поэтому я не понимаю что делать дальше.

а что в логах?

dmesg или какие конкретно смотреть?

Логи libvirt, выхлоп qemu monitor

Есть лог локальной виртуалки в /var/log/libvirt/qemu/, с которой сейчас пробую. Но там много всего. Как там можно разобраться? Как запустить этот qemu-monitor я не в курсе.

там как раз оно, логи нетривиальные, но если есть проблемы на уровне qemu то они видны.

вообще, где lsusb с хоста?

Немножко жаль тебя :)

логи

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Лог (ubuntu.com) из /var/log/libvirt/qemu/Kubuntu16.04.log

я вообще не вижу соответствия между lsusb и адресами в domxml.

Ну, лог я взял из хоста, а lsusb выполнял в госте. Правильно?

Я же писал - lsusb на хосте

Вот на хосте:

~$ lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0566:3002 Monterey International Corp. Keyboard
Bus 003 Device 002: ID 0781:5567 SanDisk Corp. Cruzer Blade
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

ну вроде все правильно, если не работает то может быть флешка уже занята хостовой OS, или же в дистре баг.

Что касается монтирования, то она точно не примонтирована - просто вставлена в порт. Что касается бага, я тоже так подозреваю и подозревал давно, потому что оно у меня ещё где-то год-два назад не работало. Тогда даже заводил репорт на родном трекере virt-manager`а, но его благополучно закопали, мотивируя это тем, что у всех работает - только у меня нет. В общем не могли подтвердить. Поэтому на сей раз завёл тут: https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1603558

В общем спасибо всем за внимание и посильную помощью. Остаётся теперь надеяться на разрабов. А мне это особенно важно, поскольку нужно HASP-ключ пробросить для 1C-баз.