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:
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.
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.
(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.
(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?
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.