Hi Eric,
On 03-12-14 16:39, Eric S. Johansson wrote:
On 12/3/2014 3:52 AM, Hans de Goede wrote:
Eric are you using usb-host redirection, or Spice's usb network redir ?
This little bit of time this morning learning about spice and the network
redirection. It worked for about half an hour and then failed in the same way
the host redirection failed. The audio device would appear for a while, I would
try to use it and then it would disappear.
The spice model has some very nice features and that I could, in theory, have a working
speech recognition engine somewhere on my <air quotes>cloud</air quotes> and
then be able to use it via spice on any desktop I happen to be located in front of. it
would also work nicely with my original idea of putting a working KVM virtual machine on
and an e-sata SSD external drive and be able to bring my working speech recognition
environment with me without having cart a laptop.
I hope you can see that this could be generalized into a nicely portable
accessibility solution where the accessibility environment moves with the
disabled user and removes the need to make every machine have user specific
accessibility software and configuration. Yes, it does impose a requirement the
KVM runs everywhere but, we know that's the future anyway so why fight it :-)
Anyway, I think if we can solve this USB audio device problem then I'll be very
happy and can make further progress towards my goal.
Thank you so very much for the help so far and I hope we can fix this USB
problem.
To further figure out what is going on when the usb device disconnects we will
need some logs.
For starters lets look at the spice-client side, before starting virt-manager
or virt-viewer do the following in the terminal:
export LIBUSB_DEBUG=4
And then start the application from the terminal like e.g. this:
virt-manager &> virt-man.log
Then do what you want to do with the usb headset until it disconnects,
and once it has disconnected quit and attach the generated virt-man.log file to
your
next mail.
Regards,
Hans
p.s.
Below are instructions to gather logs on the qemu side. I do not need those
right now, first lets do the client side logs, but since I've already looked up
the instructions I thought it would be good to put them in this mail:
Standard the libvirt qemu logs under:
/var/log/libvirt/qemu/<vm-name>.log
Should contain some minimal usb logging.
If native usb is properly setup and a client connects which supports native
usb, one
would expect messages like this to show up there:
qemu-system-x86_64: usbredirparser: Peer version: spice-gtk 0.21, using 64-bits
ids
If a message like the above does not show up then there is a problem with the vm
config, and further more detailed debugging is not going to help.
If you're debugging problems with a certain device it may be helpful to enable
more verbose logging of usb traffic inside qemu, to do this, the vm's libvirt
xml
file needs to be edited like this:
<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
<devices>
...
</devices>
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.usbredir0.debug=4'/>
</qemu:commandline>
</domain>
Note the first line needs to be changed and the <qemu:commandline> section is
new. If there are more usbredir devices inside the xml (usually there are) then
additional -set device.usbredir1.debug=4, etc. arguments must be added, ie:
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.usbredir0.debug=4'/>
<qemu:arg value='-set'/>
<qemu:arg value='device.usbredir1.debug=4'/>
</qemu:commandline>
Note this kind of detailed logging is only useful when a certain device fails,
if
no devices work at all there usual is a general configuration problem.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
