Bug 1122468 - Enforcing NX support
Summary: Enforcing NX support
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: Pavel Stehlik
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-23 10:35 UTC by Simone Tiraboschi
Modified: 2014-07-26 18:52 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-26 18:52:01 UTC
oVirt Team: ---


Attachments (Terms of Use)

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.


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