Bug 1122468

Summary:	Enforcing NX support
Product:	[Retired] oVirt	Reporter:	Simone Tiraboschi <stirabos>
Component:	ovirt-engine-core	Assignee:	bugs <bugs>
Status:	CLOSED WONTFIX	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.5	CC:	acathrow, alonbl, bazulay, dougsland, ecohen, gklein, iheim, lsurette, sbonazzo, yeylon
Target Milestone:	---	Keywords:	Improvement
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-26 18:52:01 UTC	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 Simone Tiraboschi 2014-07-23 10:35:43 UTC

Description of problem:
Investigating side effects of a previous bug (https://bugzilla.redhat.com/1103672), I found that KVM can have problems performing live migration between host with different status of the NX flags.

 There are some older Intel processors which don't support NX (or XD), which may
 cause problems in a cluster which includes NX-supporting hosts. To disable NX
 for a given guest, start it with such a parameter: -cpu qemu64,-nx

From http://www.linux-kvm.org/page/Migration

Now ovirt-host-deploy doesn't really check the status of the NX flags. Considering that NX is really often enabled by default, it could be good to enforce it just to avoid migration problem on host that doesn't enable it.


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

How reproducible:
100%

Steps to Reproduce:
1. add an host with NX flag disabled to a cluster with another host with NX enabled
2.
3.

Actual results:
The host will be added without any notice to the user and it could cause problems at VM migrations.

Expected results:
Alert the user to enable NX support

Additional info:

Comment 1 Alon Bar-Lev 2014-07-23 11:12:21 UTC

as written in bug#1103672, such cases should be detected post installation by vdsm or pre-installation based on cpu type.

not sure we should enforce nx flag to all hosts just because we have a problem with hosted engine.

Comment 2 Simone Tiraboschi 2014-07-23 11:59:37 UTC

http://gerrit.ovirt.org/#/c/29739/ it's indeed enough to solve bug#1103672.

This is for another issue: as far as KVM documentation says, potentially the user can have problems with live migration between an host with NX support and an host without it.
If we enforce the NX flag an all the host we can simply prevent it, otherwise the users can find strange behaviors within a cluster due to the status of the NX flag.
I'm not sure but I think that oVirt don't check that flag anywhere else.

Comment 3 Alon Bar-Lev 2014-07-23 12:19:11 UTC

(In reply to Simone Tiraboschi from comment #2)
> http://gerrit.ovirt.org/#/c/29739/ it's indeed enough to solve bug#1103672.
> 
> This is for another issue: as far as KVM documentation says, potentially the
> user can have problems with live migration between an host with NX support
> and an host without it.
> If we enforce the NX flag an all the host we can simply prevent it,
> otherwise the users can find strange behaviors within a cluster due to the
> status of the NX flag.
> I'm not sure but I think that oVirt don't check that flag anywhere else.

this is not infra domain to decide, and can be tested by vdsm within a cluster that supports that feature.

Comment 4 Sandro Bonazzola 2014-07-23 13:13:33 UTC

(In reply to Alon Bar-Lev from comment #1)

> not sure we should enforce nx flag to all hosts just because we have a
> problem with hosted engine.

I got the impression from discussing this with Itamar that engine is enforcing NX everywhere to prevent migration issues, it shouldn't be an hosted-engine only issue. If I got it right, I think we can avoid to duplicate validation code by having it in host-deploy.

Itamar?

Comment 5 Itamar Heim 2014-07-23 13:16:30 UTC

we don't block this in host-deploy. we move it in engine to non-operational.
reasons:
1. you can change this validation by changing the cpu flags config.
2. gluster hosts don't care about this.