Description of problem: Installing a Windows VM with "Console / USB Policy" set to "Native" will attach an USB2 controller to the VM. This USB2 controller will use the first available address, 0x05 in this case. Then, libvirt will create the virtio-serial controller and the virtio-balloon-pci device using the next addresses, 0x06 and 0x07 in this case. After the OS installation, if we start the VM with "Console / USB Policy" set to "Disabled", USB2 controller will not be present, the virtio-serial controller will use the address 0x05 and the virtio-balloon-pci device will use the address 0x06. This will trigger an unwanted new hardware detection/installation inside the Guest, with consequent request to reboot. The problem is worst considering large deployments of VDI, where the users are not allowed to provide admin credentials to complete the new hardware install. See attachment for full libvirt XMLs and qemu commands from a VM started with USB Policy set to Native and then started again with USB Policy set to Disabled. Version-Release number of selected component (if applicable): rhevm-3.4.1-0.31.el6ev.noarch vdsm-4.14.11-5.el6ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install a Windows VM with "Console / USB Policy" set to "Native". 2. Shutdown VM. 3. Start the VM with "Console / USB Policy" set to "Disabled". Actual results: You can observe the new hardware detected and then installed by windows, followed by a reboot request. Expected results: USB Policy cahnge should not trigger new hardware detection for other devices.
Created attachment 940834 [details] libvirt xmls and qemu commands
looks like a duplicate of bug 1028387 looking at the flags - so is 3.5 ok?
(In reply to Michal Skrivanek from comment #3) > looks like a duplicate of bug 1028387 > looking at the flags - so is 3.5 ok? Yes, duplicate indeed. In my case, this is a consequence of BZ#1080144. 3.5 is fine for now.
*** This bug has been marked as a duplicate of bug 1028387 ***