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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
