Bug 867331

Summary:	Audio (at the very least) devices not updated when OS of a VM changes
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Tomas Jamrisko <tjamrisk>
Component:	ovirt-engine	Assignee:	Omer Frenkel <ofrenkel>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jiri Belka <jbelka>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	3.1.0	CC:	dyasny, iheim, lpeer, michal.skrivanek, ofrenkel, Rhev-m-bugs, sgrinber, yeylon, ykaul
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:	si23	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tomas Jamrisko 2012-10-17 10:34:13 UTC

Description of problem:

Changing OS version of a VM in user nor admin portal has no effect on devices with which the VM gets started -- e.g. -- a VM first created as XP will always start with AC97.

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

rhevm-3.1.0-18.el6ev.noarch

How reproducible:

always

Steps to Reproduce:
1. Create a VM
2. Start the VM
3. Notice the qemu parameters (it should have intel-hda, or AC97)
4. Stop the VM; Change its OS so something that should be started with a different device -- (AC97, Windows XP); (intel-hda, most others)
  
Actual results:
The device on command line doesn't change

Expected results:
It should

Comment 2 Simon Grinberg 2012-10-17 14:48:37 UTC

What is the behavior in 3.0? if it's the same then please remove the blocker request since this is not a regression and I don't see this as a gating item.

On the other hand I suspect that it may be a regression derived from the stable PCI feature. But still not sure it needs to be fixed if the fix is complex.

Reasoning,
Changing the OS is not trivial in any case, so why not remove and recreate the VM? 

The more annoying use case is a simple mistake in the initial creation, that will require remove and recreate.

Comment 3 Tomas Jamrisko 2012-10-18 09:02:03 UTC

It's working in 3.0 -> it's a regression. 

I proposed this as a blocker because you don't have to define OS at VM creation (Unassigned) and change it after the OS gets installed.

You're right about this not being a totally standard use case, so the blocker might be an overkill.

Comment 4 Omer Frenkel 2012-10-23 15:54:00 UTC

http://gerrit.ovirt.org/#/c/8747/

Comment 6 Michal Skrivanek 2012-10-26 06:27:18 UTC

merged u/s: 452379748aa6b76254ec359d44b43cfc6e6392fb