I add 2 USB host devices to a Windows guest and when I run the guest it can access them.
However after I reboot the host and I try to access them again I get an error box saying:
Error starting domain: internal error: Did not find USB device 56d:2 bus:5 device:3
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1433, in startup
self._backend.create()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1029, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: Did not find USB device 56d:2 bus:5 device:3
and the only way to solve this is remove the 2 devices and add them back.
Do you see the same error if you shutdown the Guest completely, wait a few seconds and then power up again?
It would be interesting if a Guest suffers from a problem which used to be seen on physical machines where the USB device doesn’t shut down completely during the reboot and has to be remounted because rebooting doesn’t shutdown devices completely (you’d think that this normally hardware problem should not occur in software).
No. But it is the second time I notice something else: When I open YaST and click “Create Virtual Machines for Xen and KVM” - a waiting mouse cursor appears for a second and then nothing. Click again - same. Nothing. And nothing in journal too. Only host reboot solves this.
It would be interesting if a Guest suffers from a problem which used to be seen on physical machines where the USB device doesn’t shut down completely during the reboot and has to be remounted because rebooting doesn’t shutdown devices completely (you’d think that this normally hardware problem should not occur in software).
I am not sure I understand completely your doubts but the hardware works fine. I am using it with Windows on a dual boot too. These are actually my 2 monitors which have USB ports for controlling them from the computer (in case that matters).
BTW why do I have to be root in order to run VM guests (i.e. open YaST and then run them)? Is there a way to run a guest as user?
Am saying that the problem used to be a hardware mounting problem many, many years ago and not something wrong with your hardware. And, would not be expected in a pure software deployment like virtualization.
Managing your virtulaization is considered a serious security issue, not much different than logging into your session directly as root. Maybe worse.
But, it’s a commonly requested config which is easily accomplished by adding your specified User account to the appropriate User Group (which is authorized to launch the virtualization services). In your case, this is likely the kvm User Group.
If as you describe this happens only on reboot and not with a “power” (virtual) shutdown and then a cold start,
Then you should probably submit a bug to https://bugzilla.opensuse.org.
Actually it seems even this is not a good option as my mouse is connected to the USB port of the monitor and as soon as I add a PCI Host Device and start the guest I can no longer use the mouse (as all my other USB ports are already used for other devices). So my option is either to sacrifice another USB device or manually re-add USB Host Controllers after each reboot.
First,
I’d like to say that I agree completely with the bugzilla analysis that the problem is fundamentally that your USB device is changing its ID.
Without more information, I’d disagree (and you may have verified) that using a PCI pass-through would be a good workaround…
The main question I’d ask before anything else (which doesn’t seem to have been asked yet) is whether your USB mouse really has to be configured as a pass-through device. It seems to me that if the device is recognized on Guest boot up, it might load and mount the mouse as a new device without any problems associated with the fixed parameters of a pass through.
The next thing I’d recommend is to plug your USB mouse into a USB port on your computer itself, not through a USB port in your monitor. The USB controllers for each may be wired up differently… the USB ports directly installed in your machine likely connected to the PCI bus might behave differently than however the USB controller is on your monitor (my guess is that you have a dedicated USB cable between your monitor and your machine thereby creating cascading USB controllers?). Although theoretically you can do this, it’s well known that individual USB devices can behave erratically and your mouse passed to a virtual Guest may be one.
Without more information, I’d disagree (and you may have verified) that using a PCI pass-through would be a good workaround…
What information do you need?
The main question I’d ask before anything else (which doesn’t seem to have been asked yet) is whether your USB mouse really has to be configured as a pass-through device. It seems to me that if the device is recognized on Guest boot up, it might load and mount the mouse as a new device without any problems associated with the fixed parameters of a pass through.
It seems to me the actual pass through device is the PCI host controller?
The next thing I’d recommend is to plug your USB mouse into a USB port on your computer itself, not through a USB port in your monitor. The USB controllers for each may be wired up differently… the USB ports directly installed in your machine likely connected to the PCI bus might behave differently than however the USB controller is on your monitor (my guess is that you have a dedicated USB cable between your monitor and your machine thereby creating cascading USB controllers?). Although theoretically you can do this, it’s well known that individual USB devices can behave erratically and your mouse passed to a virtual Guest may be one.
It is not possible to plug the mouse directly. All my USB ports are already in use. Also as I explained it hardly makes any sense to plug the mouse directly and plug one of the other devices to the monitor’s USB port because that would give the exact same result - the device will become unavailable to the host and that is not desirable.
For the moment I can live with the re-adding of USB host controller (whenever the ID changes) but I was hoping there is a more intelligent solution. It really doesn’t make sense to reconfigure the guest every now and then for a small thing like this.
Architecturally,
PCI devices are considered “fixed”
Devices which aren’t “hot-plugged” – ie inserted and removed on the fly why the system is running, you need to open up the case, and insert or remove from whatever slot, and when installed, there is a PCI slot number.
PCI devices which can be hot-plugged are unusual, and require additional custom hardware.
USB devices aren’t considered “fixed”
Devices can be inserted and removed while the system is running,
This is why a device is always re-scanned on boot and insertion and assigned an unused ID when scanned.
There is nothing really that specifies or allows an ID to be “sticky” so the ID typically changes
This is why if you want “stickiness” you need to use something other than the ID… Maybe a device serial number.
Although the above is virtualized, they’re still for the most part replicating physical design to present a device with familiar characteristics to the Guest.
Now, back to configuring a “pass through”
You’re configuring based on a device ID
So, if the ID can’t be assured to be the same across reboots, you will have your problem
But, as I opined…
Although somehow mounting a USB device as a PCI device might work if possible (and I have a personal saying that “With Software anything is possible”) this would require all sorts of code that AFAIK doesn’t exist by default.
Even if you configured the USB Controller as connected to the PCI Controller (virtualized), it seems to be that would be the same as plugging in a physical USB hub into a PCI board. That doesn’t solve the problem that the USB device plugged into the USB hub is still going to be assigned a random ID.
Now,
I asked whether you are going down the wrong road doing a USB pass through in the first place.
If you <don’t> do a USB pass through and the Guest can see the USB mouse, it would be a virtualized mouse, shared across all Guests and the Host.
Or,
If you insist on doing a pass through, then maybe you should invest in an additional $5 mouse so that you can pass through one mouse to the Guest and the other would be configured for your Host.
If you need more USB ports, get another or replace with a larger USB hub… In theory, you can connect up to 254 devices through any port… You’re restricted only by the hardware you use. In practice, I’ve heard in some cases cascading hubs can inject instability. Personally, I control my use of USB because historically USB hasn’t been as reliable as other connections although today it’s vastly better.
Thanks for explaining all this. I am aware of what you say. I suppose I am actually looking for something like this:
Is that possible?
Just to clarify - my problem is not the mouse and I don’t need to pass it through. My concern is about the two monitors which are connected and controlled via USB. Unfortunately EIZO’s software which can control the gamma and other color settings (EIZO ColorNavigator) has no Linux version, so I am compelled to do all this using a virtual guest just to switch between different color modes which I use.
I don’t know if you noticed my question about what was suggested in the bug report:
BTW, please make sure that your host kernel includes VFIO support(Check it by searching ‘CONFIG_VFIO_PCI=m’ in your kernel config file)
How do I check that? Might that somehow be related to a potential solution?
Regarding USB and ID “stickiness” – Maybe I wasn’t clear… No, you can’t control how the USB device ID is assigned and that is important because that’s how the hardware pass-through is configured. I only mentioned the device serial id as a workaround that allows the OS to identify the device but that is a workaround which means that it’s still not going to solve your fundamental problem doing a USB pass-through. If you can’t fix the fundamental problem, then the pass through can’t work the way you want it to work.
See this forum thread, particularly the last post by me.
I don’t know that enough time has passed that the vfio/paravirtualization problem has been solved, most likely you would have to implement as QEMU full virtualization the way I describe and following the references I provided in the post.
It would have saved some time to know that your pass-through USB wasn’t a mouse (wasn’t that mentioned?)
Now, I’m re-visiting why you are even involving virtualization.
I assume you’re not accessing your machine locally? If you are sitting at the machine and can logon locally, I assume that accessing each monitor is trivial.
Does that mean that you are accessing your machine (and Guests) remotely from another machine?
Perhaps you should consider ssh into the Host which would support direct hardware access, including to your monitors.
I assume you’re not accessing your machine locally?
On the contrary. I am accessing everything locally.
If you are sitting at the machine and can logon locally, I assume that accessing each monitor is trivial.
Not necessarily. What ColorNavigator does is to access a local monitor calibration profile (which is created and stored in the Windows guest) which includes actual hardware settings for the monitor and calibration data. So simply pushing a button on the monitor itself can not load that data and cannot set all the monitor color curves which are built in that calibration profile. That’s why I actually need to run the software and change the profile from it. The switching of profiles using the software takes 2 seconds. However I need to spend at least 10 times more to re-add USB host devices which might have changed IDs and that makes the whole thing quite tedious. That’s why I was looking for a potential solution. Surely it is not some huge problem. I was just checking if I was missing something and thinking that computers should work for us, not the other way
If this is what you’re trying to run, there is supposed to be a RHEL package which has reasonable possibilities of running on openSUSE without an issue. Since you haven’t specified exactly what monitor and product you’re running I can’t cross-check to be certain but you should explore this http://www.eizo.com/products/coloredge/cn_nx/
Interesting! Thanks, I will check that out. For one of the monitors that might work. But the other one is an older model (not CG series but FlexScan) and runs older software (LCD ScreenManager). Anyway I will definitely have a look at that package. Thanks again.
Yes,
I noticed there is no current download,
But it’s interesting that the possibility is mentioned… which might mean that a RHEL version <was> available but not currently available.
Which might mean that you might need to contact them directly and ask if even an old version is available.
Or, if source might be available to compile, since a *NIX version is available (Apple Mac).
