Bug 838487

Summary:	[RFE] Allow setting of machine type per VM rather than cluster level
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Andrew Cathrow <acathrow>
Component:	RFEs	Assignee:	Michal Skrivanek <michal.skrivanek>
Status:	CLOSED ERRATA	QA Contact:	sefi litmanovich <slitmano>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.1.0	CC:	gklein, iheim, istein, lpeer, melewis, michal.skrivanek, rbalakri, sherold
Target Milestone:	ovirt-3.6.0-rc	Keywords:	FutureFeature
Target Release:	3.6.0	Flags:	sherold: Triaged+
Hardware:	Unspecified
OS:	Unspecified
URL:	http://www.ovirt.org/Features/Cluster_parameters_override
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1236049 (view as bug list)		Environment:
Last Closed:	2016-03-09 20:26:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1236049
Bug Blocks:	1302707

Description Andrew Cathrow 2012-07-09 09:00:42 UTC

Today the machine type (eg. -M 6.3.0) is taken from the cluster level.
We need the ability for a user to specify the machine type per VM.

We need to research if we just use the qemu machine type or if we have to extend this and have a compatibility schedule that encompasses more than just the -M flag.

Comment 1 Michal Skrivanek 2012-09-26 11:20:24 UTC

let's start with -M setting only.
currently in vdc_options per cluster level.
Need default selection in cluster dialog and override in VM dialog

Comment 2 Itamar Heim 2012-09-28 07:14:40 UTC

since we can't tell what's tested per -M level, i think the appraoch should be to specify the VM cluster compatibility level.
then for example, the list of allowed cpu's (there is another RFE to select this one) would be based on the vm compat level.
same for validation on operations (maybe we don't allow to hotplug a nic to a VM which is in an older cluster level).

i.e., not sure we should handle the -M directly, rather than the compat level.

Comment 3 Itamar Heim 2013-04-01 09:43:24 UTC

Andrew - please elaborate on reason for this feature and expected behavior.
there is quite a lot of complexity/risk around manging this wrt testing since we have no way to distinguish which features get tested at a specific cluster compatibility level based on -M of qemu-kvm.

Comment 5 Itamar Heim 2013-12-01 08:01:37 UTC

andrew, the default for VMs would be "cluster default", right?
so on change of cluster to 4.0, all VMs will boot with -M rhel7, unless admin specifically changes it to say "3.5"?
would we do this based on rhel versions, or rhev cluster compatibility versions?

Comment 6 Andrew Cathrow 2013-12-03 09:00:57 UTC

(In reply to Itamar Heim from comment #5)
> andrew, the default for VMs would be "cluster default", right?

Yes

> so on change of cluster to 4.0, all VMs will boot with -M rhel7, unless
> admin specifically changes it to say "3.5"?

Yes

> would we do this based on rhel versions, or rhev cluster compatibility
> versions?

IMHO rhev cluster compatibility levels

Comment 11 sefi litmanovich 2016-01-03 13:20:33 UTC

Verified with rhevm-3.6.2-0.1.el6.noarch according to attached test plan.
Test run:

https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=3_6_VIRT_Cluster_Parameters_Override_23122015

Comment 14 errata-xmlrpc 2016-03-09 20:26:48 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.

https://rhn.redhat.com/errata/RHEA-2016-0376.html