Bug 950768 - Windows XP guest fails to start when enabling native USB support.
Summary: Windows XP guest fails to start when enabling native USB support.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.3
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: ---
: 3.3.0
Assignee: Roy Golan
QA Contact: Pavel Stehlik
URL:
Whiteboard: virt
Depends On: 984586
Blocks: 996127
TreeView+ depends on / blocked
 
Reported: 2013-04-10 20:13 UTC by Gordon Watson
Modified: 2018-12-03 18:40 UTC (History)
14 users (show)

Fixed In Version: is6
Doc Type: Bug Fix
Doc Text:
Previously users could edit the USB policy while the virtual machine was running, which could lead to errors in running the virtual machine. Now, the USB policy can only be edited when the virtual machine is down, preventing users from attaching a new USB device without detaching the old one.
Clone Of:
: 996127 (view as bug list)
Environment:
Last Closed: 2014-01-21 17:17:17 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0038 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.3.0 update 2014-01-21 22:03:06 UTC
oVirt gerrit 16811 0 None MERGED core: Edit USB policy only on down status 2020-11-03 07:13:15 UTC

Description Gordon Watson 2013-04-10 20:13:19 UTC
Description of problem:

A Windows XP VM cannot be started if native USB is added while the VM is running. It will have an additional extraneous USB device associated with it.


Version-Release number of selected component (if applicable):

RHEV 3.1.


How reproducible:

This was reproduced once.


Steps to Reproduce:

1. USB property is disabled at first.
2. Start VM.
3. When vm running, change USB to native.
4. Plug in USB device, then the additional usb device record appears in the 'vm_device' table.
  

Actual results:

The VM that cannot start has one more USB device than other VMS, as shown below;

-[ RECORD 5 ]+-----------------------------------------------------------------
device_id    | fa0087e8-ce58-4ef7-88de-1d47122f6459
vm_id        | e0d7d01e-7150-4a87-b173-784c50909105
type         | controller
device       | usb
address      | { domain=0x0000, bus=0x00,  type=pci,  function=0x2,  slot=0x01}
boot_order   | 0
spec_params  | {
             : }
is_managed   | f
is_plugged   | t
is_readonly  | f
_create_date | 2013-04-09 11:30:20.479786+08
_update_date | 2013-04-09 12:22:24.65634+08
alias        | 


When this record is deleted, the VM can be then be started.


Expected results:



Additional info:

Comment 1 Kevein Liu 2013-04-11 05:27:44 UTC
RHEV-M release version:
rhevm-3.1.0-43.el6ev.noarch

Comment 3 Kevein Liu 2013-05-08 01:47:54 UTC
Hi,
Any progress by now?
3.3 is too far away for customer. Could we backport it to 3.1.z ?

Thanks,
Kevein

Comment 4 Roy Golan 2013-05-08 09:02:48 UTC
Kevein pls attach rhevm.log so we would see why the engine fails.

Comment 5 Kevein Liu 2013-05-08 09:34:09 UTC
(In reply to comment #4)
> Kevein pls attach rhevm.log so we would see why the engine fails.

Now there's no engine.log available of that time. Could you please give me a check list what we should collect? I will contact customer and reproduce this issue.

Cheers,
Kevein

Comment 6 Roy Golan 2013-05-08 11:11:01 UTC
this is issues isn't reproducible on latest version. 

the core issue I presume is that you are able to edit the VM while its running.(pls confirm that). After you save, the VM has the new usb devices as well as the old device, which is continuously reported from the VDSM, because its the defacto usb device on the running VM

Comment 7 Kevein Liu 2013-05-10 07:37:09 UTC
(In reply to comment #6)
> this is issues isn't reproducible on latest version. 
> 
> the core issue I presume is that you are able to edit the VM while its
> running.(pls confirm that). After you save, the VM has the new usb devices
> as well as the old device, which is continuously reported from the VDSM,
> because its the defacto usb device on the running VM

Do you mean that we have resolve this problem?
Thanks,
Kevein

Comment 9 Kevein Liu 2013-06-13 02:34:39 UTC
Hi,

Since no voice for a long time, could anyone please confirm the last question in comment #7?
Thank you!

Kevein

Comment 10 Amador Pahim 2013-06-13 13:59:57 UTC
Ok, I've got the issue reproduced with upstream.

ovirt-engine-3.3.0-0.2.master.20130609231424.gitc493152.fc18.noarch
vdsm-4.11.0-28.git634b9f4.fc18.x86_64

NORMAL WORKFLOW

VM Down:
engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
(No rows)

VM started with USB Support = Disabled:
engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
(No rows)

After few seconds starting VM, engine adds to the database the unmanaged USB device, used by qemu[1] as default USB controller (piix3-usb-uhci):
engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
-[ RECORD 1 ]-----------
type        | controller
device      | usb
spec_params | {
            | }
is_managed  | f


Then, even with VM in Up state, changing USB Support to Native will work as expected. The unmanaged usb device will be removed from the database and the 4 usb devices related to USB redirection will take place:

engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
-[ RECORD 1 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-ehci1"
            | }
is_managed  | t
-[ RECORD 2 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-uhci1"
            | }
is_managed  | t
-[ RECORD 3 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-uhci2"
            | }
is_managed  | t
-[ RECORD 4 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-uhci3"
            | }
is_managed  | t


CORNER CASE:

The corner case happens when the USB Support is changed to Native AFTER VM start and BEFORE engine auto adding the default unmanaged usb controller device:

VM Down:
engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
(No rows)

VM started with USB Support = Disabled:
engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
(No rows)

At this moment, if we quickly change USB Support to Native, the 4 usb devices related to USB redirection will be recorded to the database, but no unmanaged usb devices are there to be removed.
After few seconds, engine will add the unmanaged USB controller device in use w/out checking the existence of another USB controller. Here the result:

engine=# select vm_device.type,vm_device.device,vm_device.spec_params,vm_device.is_managed from vm_device,vm_static where vm_static.vm_name = 'VM01' and vm_device.device = 'usb' and vm_static.vm_guid = vm_device.vm_id;
-[ RECORD 1 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-ehci1"
            | }
is_managed  | t
-[ RECORD 2 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-uhci2"
            | }
is_managed  | t
-[ RECORD 3 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-uhci1"
            | }
is_managed  | t
-[ RECORD 4 ]-------------------------
type        | controller
device      | usb
spec_params | {
            |   "index" : "0",
            |   "model" : "ich9-uhci3"
            | }
is_managed  | t
-[ RECORD 5 ]-------------------------
type        | controller
device      | usb
spec_params | {
            | }
is_managed  | f

With two USB controllers (RECORD 1 and RECORD 5), qemu is not able to start, exiting with "Duplicate ID 'usb' for device" message.

So, the issue here is the engine auto adding the unmanaged USB controller device w/out checking the existence of another USB controller in database.

[1] - http://www.linux-kvm.org/page/USB
--
apahim

Comment 12 Kevein Liu 2013-06-26 02:15:32 UTC
Hi team,

Is there any update? Anything need my assistance, please let me know.
Cheers,
Kevein

Comment 13 Itamar Heim 2013-06-26 03:23:48 UTC
(In reply to Kevein Liu from comment #12)
> Hi team,
> 
> Is there any update? Anything need my assistance, please let me know.
> Cheers,
> Kevein

matching flags/target version with the suspected dup bug, slated for 3.2.2.
amador - is there a workaround

Comment 14 Amador Pahim 2013-06-26 10:51:07 UTC
Yes, there is.

Workaround:
- Edit VM, changing USB Support to Disabled.
- Click OK.
- Edit VM, changing USB Support to Native.
- Click OK.
- Start VM again.

This will update the database with correct records.

Comment 15 Roy Golan 2013-07-08 13:31:42 UTC
If there's a workaround I suggest lowering the prio for this one

2nd - A Vm is editable if its UP or Down - this means the unmanaged usb has been reported after 1 minute of the VM powering up. Thats really a corner case . Amador did you use the REST for that?

I'll run some test locally to see when does devices get reported

Comment 16 Amador Pahim 2013-07-08 14:13:44 UTC
(In reply to Roy Golan from comment #15)
> If there's a workaround I suggest lowering the prio for this one
> 
> 2nd - A Vm is editable if its UP or Down - this means the unmanaged usb has
> been reported after 1 minute of the VM powering up. Thats really a corner
> case . Amador did you use the REST for that?

No, I did use Admin Portal. I had to be quick to edit Vm after the "start" click.

Comment 18 Michal Skrivanek 2013-07-12 11:27:57 UTC
see bug 922377 for proposed solution in 3.4

Comment 19 Michal Skrivanek 2013-07-16 08:40:23 UTC
for 3.3 forbid editing of USB Policy while the VM is running

merged to master:
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=a6824e730d0329a5db183c41725c6ff398fbddb8

Comment 21 David Botzer 2013-08-27 09:35:17 UTC
3.3/is11
1. Cannot Edit VM, while it's running, to have USB=Native
2. Stopping VM, Edit USB=Native, Starting VM correctly,
3. Adding new HW from cntrol Panel, USB all is ok,

Is that sufficient ?

Comment 22 Michal Skrivanek 2013-08-27 09:38:54 UTC
yeah, you're not allowed to change it while the VM is running

Comment 23 David Botzer 2013-08-27 09:41:14 UTC
So if the VM is running can i close this BZ ?

Comment 24 David Botzer 2013-08-27 09:48:57 UTC
Fixed, 3.3/is11

Comment 25 Charlie 2013-11-28 00:24:55 UTC
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Comment 27 errata-xmlrpc 2014-01-21 17:17:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0038.html


Note You need to log in before you can comment on or make changes to this bug.