| Summary: | hosted-engine --deploy does not check for NX flag | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Evgheni Dereveanchin <ederevea> | |
| Component: | ovirt-hosted-engine-setup | Assignee: | Simone Tiraboschi <stirabos> | |
| Status: | CLOSED ERRATA | QA Contact: | Nikolai Sednev <nsednev> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 3.3.0 | CC: | alonbl, bazulay, dfediuck, didi, dougsland, iheim, lveyde, nsednev, rbalakri, Rhev-m-bugs, sbonazzo, sherold, stirabos, yeylon | |
| Target Milestone: | --- | Keywords: | Triaged, ZStream | |
| Target Release: | 3.5.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | integration | |||
| Fixed In Version: | ovirt-3.5.0-beta1.1 | Doc Type: | Bug Fix | |
| Doc Text: |
Previously, if the NX flag was not checked in the BIOS of certain Intel CPU types, which require NX as well as VMX to support virtualization, the deployment script for the hosted engine would not accurately detect the CPU type and the deployment would stall. Now, the user is prompted to check the NX flag in the system BIOS if the CPU type is not accurately detected, and the deployment exits gracefully.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1119145 (view as bug list) | Environment: | ||
| Last Closed: | 2015-02-11 20:39:56 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: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1119145, 1142923, 1156165 | |||
|
Description
Evgheni Dereveanchin
2014-06-02 10:33:37 UTC
Hosted engine just ask libvirt (bug #1100326) for a list of compatible cpus and ovirt-host-deploy for virtualization support. So I think otopi.ovirt_host_deploy.hardware hardware.detect should do that check and report virtualization not available. A hint as "NX flag not enabled" exception would be useful for providing user more accurate information. Alon, feel free to take the bug if you have time for working on it. I am unsure I understand why NX is required for virtualization. The CPU should be detected and be usable anyway, just libvirt detect it as different CPU. caps._getCompatibleCpuModels() returns an empty set if cpu model is lower than Conroe. And without NX it's not detected as >= Conroe. (In reply to Sandro Bonazzola from comment #3) > caps._getCompatibleCpuModels() returns an empty set if cpu model is lower > than Conroe. And without NX it's not detected as >= Conroe. So what is the difference between this and having a different check? when you get empty, you state virtualization is not supported. (In reply to Alon Bar-Lev from comment #4) > (In reply to Sandro Bonazzola from comment #3) > > caps._getCompatibleCpuModels() returns an empty set if cpu model is lower > > than Conroe. And without NX it's not detected as >= Conroe. > > So what is the difference between this and having a different check? when > you get empty, you state virtualization is not supported. I mean virtualization is supported without nx with selected models, in hardware at host-deploy we do not check for cpu type nor interact with libvirt... (In reply to Alon Bar-Lev from comment #4) > (In reply to Sandro Bonazzola from comment #3) > > caps._getCompatibleCpuModels() returns an empty set if cpu model is lower > > than Conroe. And without NX it's not detected as >= Conroe. > > So what is the difference between this and having a different check? when > you get empty, you state virtualization is not supported. I can do like that, but I would have preferred an explicit check on the NX flag when vmx flag is available in order to tell user why virtualization is not available. But I guess that saying "Hardware virtualization support is not available: please check BIOS settings and turn on NX support if available" may be enough. Failed:
I've tested it on two Intel(R) Xeon(R) CPU E5420 @ 2.50GHz on RedHat 7.0 hosts and on one Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz on RedHat 7.0 host with these components:
vdsm-4.16.8.1-4.el7ev.x86_64
qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64
libvirt-client-1.2.8-10.el7.x86_64
sanlock-3.2.2-2.el7.x86_64
mom-0.4.1-4.el7ev.noarch
Linux version 3.10.0-217.el7.x86_64 (mockbuild.eng.bos.redhat.com) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Fri Dec 12 14:52:08 EST 2014
I've disabled NX flag on my Intel hosts and with installed RHEL7.0 on it, the hosted-engine deployment continued without detecting that virtualization actually turned-off/not supported:
[root@black-vdsb ~]# hosted-engine --deploy
[ INFO ] Stage: Initializing
[ INFO ] Generating a temporary VNC password.
[ INFO ] Stage: Environment setup
Continuing will configure this host for serving as hypervisor and create a VM where you have to install oVirt Engine afterwards.
Are you sure you want to continue? (Yes, No)[Yes]:
Configuration files: []
Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20141228163322-m5anhj.log
Version: otopi-1.3.0 (otopi-1.3.0-2.el7ev)
It has been detected that this program is executed through an SSH connection without using screen.
Continuing with the installation may lead to broken installation if the network connection fails.
It is highly recommended to abort the installation and run it inside a screen session using command "screen".
Do you want to continue anyway? (Yes, No)[No]: yes
[ INFO ] Hardware supports virtualization
[ INFO ] Stage: Environment packages setup
[ INFO ] Stage: Programs detection
[ INFO ] Stage: Environment setup
[ INFO ] Waiting for VDSM hardware info
[ INFO ] Waiting for VDSM hardware info
[ INFO ] Generating libvirt-spice certificates
[ INFO ] Stage: Environment customization
--== STORAGE CONFIGURATION ==--
During customization use CTRL-D to abort.
Please specify the storage you would like to use (iscsi, nfs3, nfs4)[nfs3]: nfs3
Please specify the full shared storage connection path to use (example: host:/path): 10.35.160.108:/RHEV/nsednev_ovirt_3_5_HE_for_disks
[ INFO ] Installing on first host
Please provide storage domain name. [hosted_storage]:
Local storage datacenter name is an internal name and currently will not be shown in engine's admin UI.Please enter local datacenter name [hosted_datacenter]:
--== SYSTEM CONFIGURATION ==--
--== NETWORK CONFIGURATION ==--
Please indicate a nic to set rhevm bridge on: (enp4s0, enp6s0) [enp4s0]: enp4s0
iptables was detected on your computer, do you wish setup to configure it? (Yes, No)[Yes]:
Please indicate a pingable gateway IP address [10.35.64.254]:
--== VM CONFIGURATION ==--
Please specify the device to boot the VM from (cdrom, disk, pxe) [cdrom]: pxe
Please specify an alias for the Hosted Engine image [hosted_engine]:
The following CPU types are supported by this host:
- model_Penryn: Intel Penryn Family
- model_Conroe: Intel Conroe Family
Please specify the CPU type to be used by the VM [model_Penryn]:
Please specify the number of virtual CPUs for the VM [Defaults to minimum requirement: 2]:
Please specify the disk size of the VM in GB [Defaults to minimum requirement: 25]:
You may specify a unicast MAC address for the VM or accept a randomly generated default [00:16:3e:59:69:97]: 00:16:3E:7B:B8:53
Please specify the memory size of the VM in MB [Defaults to minimum requirement: 4096]:
Please specify the console type you would like to use to connect to the VM (vnc, spice) [vnc]:
--== HOSTED ENGINE CONFIGURATION ==--
Enter the name which will be used to identify this host inside the Administrator Portal [hosted_engine_1]:
Enter 'admin@internal' user password that will be used for accessing the Administrator Portal:
Confirm 'admin@internal' user password:
Please provide the FQDN for the engine you would like to use.
This needs to match the FQDN that you will use for the engine installation within the VM.
Note: This will be the FQDN of the VM you are now going to create,
it should not point to the base host or to any other existing machine.
Engine FQDN: nsednev-he-1.qa.lab.tlv.redhat.com
Please provide the name of the SMTP server through which we will send notifications [localhost]:
Please provide the TCP port number of the SMTP server [25]:
Please provide the email address from which notifications will be sent [root@localhost]:
Please provide a comma-separated list of email addresses which will get notifications [root@localhost]:
[ INFO ] Stage: Setup validation
--== CONFIGURATION PREVIEW ==--
Bridge interface : enp4s0
Engine FQDN : nsednev-he-1.qa.lab.tlv.redhat.com
Bridge name : rhevm
SSH daemon port : 22
Firewall manager : iptables
Gateway address : 10.35.64.254
Host name for web application : hosted_engine_1
Host ID : 1
Image alias : hosted_engine
Image size GB : 25
Storage connection : 10.35.160.108:/RHEV/nsednev_ovirt_3_5_HE_for_disks
Console type : vnc
Memory size MB : 4096
MAC address : 00:16:3E:7B:B8:53
Boot type : pxe
Number of CPUs : 2
CPU Type : model_Penryn
Please confirm installation settings (Yes, No)[Yes]:
[ INFO ] Stage: Transaction setup
[ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation
[ INFO ] Stage: Misc configuration
[ INFO ] Configuring libvirt
[ INFO ] Configuring VDSM
[ INFO ] Starting vdsmd
[ INFO ] Waiting for VDSM hardware info
[ INFO ] Configuring the management bridge
[ INFO ] Creating Storage Domain
[ INFO ] Creating Storage Pool
[ INFO ] Connecting Storage Pool
[ INFO ] Verifying sanlock lockspace initialization
[ INFO ] Creating VM Image
[ INFO ] Disconnecting Storage Pool
[ INFO ] Start monitoring domain
[ INFO ] Configuring VM
[ INFO ] Updating hosted-engine configuration
[ INFO ] Stage: Transaction commit
[ INFO ] Stage: Closing up
[ INFO ] Creating VM
You can now connect to the VM with the following command:
/bin/remote-viewer vnc://localhost:5900
Use temporary password "0832PUaZ" to connect to vnc console.
Please note that in order to use remote-viewer you need to be able to run graphical applications.
This means that if you are using ssh you have to supply the -Y flag (enables trusted X11 forwarding).
Otherwise you can run the command from a terminal in your preferred desktop environment.
If you cannot run graphical applications you can connect to the graphic console from another host or connect to the console using the following command:
virsh -c qemu+tls://Test/system console HostedEngine
If you need to reboot the VM you will need to start it manually using the command:
hosted-engine --vm-start
You can then set a temporary password using the command:
hosted-engine --add-console-password
The VM has been started. Install the OS and shut down or reboot it. To continue please make a selection:
(1) Continue setup - VM installation is complete
(2) Reboot the VM and restart installation
(3) Abort setup
(4) Destroy VM and abort setup
(1, 2, 3, 4)[1]:
NX for some reason displayed as enabled in OS, although it was disabled in bios on all three hosts:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
stepping : 10
microcode : 0xa0b
cpu MHz : 2490.000
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 4987.44
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
(In reply to Nikolai Sednev from comment #8) > Failed: > I've tested it on two Intel(R) Xeon(R) CPU E5420 @ 2.50GHz on RedHat 7.0 > hosts and on one Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz on RedHat 7.0 > host with these components: > vdsm-4.16.8.1-4.el7ev.x86_64 > qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64 > libvirt-client-1.2.8-10.el7.x86_64 > sanlock-3.2.2-2.el7.x86_64 > mom-0.4.1-4.el7ev.noarch > Linux version 3.10.0-217.el7.x86_64 > (mockbuild.eng.bos.redhat.com) (gcc version 4.8.3 20140911 > (Red Hat 4.8.3-7) (GCC) ) #1 SMP Fri Dec 12 14:52:08 EST 2014 > > > I've disabled NX flag on my Intel hosts and with installed RHEL7.0 on it, > the hosted-engine deployment continued without detecting that virtualization > actually turned-off/not supported: Not sure that's a problem, based on comment 5 and 6. (In reply to Evgheni Dereveanchin from comment #0) > Description of problem: > when using a CPU with VMX flag present but NX flag absent in CPU features, > > Version-Release number of selected component (if applicable): > ovirt-hosted-engine-setup-1.1.2-5.el6ev.noarch > > How reproducible: > always > > Steps to Reproduce: > 1. install RHEL 6.5 on a server with VMX but without NX flag > 2. install ovirt-hosted-engine-setup > 3. run "hosted-engine --deploy" > > Actual results: > 4. CPU check succeeds > 5. libvirt does not detect the CPU family and installation is stuck on CPU > type selection for the cluster. Was it stuck? Doesn't seem so from your log. > > Expected results: > 4. CPU check fails, installation is aborted I guess that's the reason you decided it failed, but as Alon mentioned in comment 5, it might not always fail like that. > > Additional info: > we advertise NX support in docs, but the script does not check for it and > lets installation continue. > https://access.redhat.com/site/documentation/en-US/ > Red_Hat_Enterprise_Virtualization/3.2/html/Hypervisor_Deployment_Guide/chap- > Deployment_Guide- > Requirements_and_limitations_of_Red_Hat_Enterprise_Virtualization_Hypervisors > .html#idp19963536 We might actually want to do report "nx disabled" specifically, perhaps as a warning, because even if virtualization works, the user might prefer to enable nx before continuing. We might want to do that also in host-deploy, for that matter. (In reply to Yedidyah Bar David from comment #9) > (In reply to Nikolai Sednev from comment #8) > > Failed: > > I've tested it on two Intel(R) Xeon(R) CPU E5420 @ 2.50GHz on RedHat 7.0 > > hosts and on one Intel(R) Xeon(R) CPU E5-2603 v2 @ 1.80GHz on RedHat 7.0 > > host with these components: > > vdsm-4.16.8.1-4.el7ev.x86_64 > > qemu-kvm-rhev-1.5.3-60.el7_0.11.x86_64 > > libvirt-client-1.2.8-10.el7.x86_64 > > sanlock-3.2.2-2.el7.x86_64 > > mom-0.4.1-4.el7ev.noarch > > Linux version 3.10.0-217.el7.x86_64 > > (mockbuild.eng.bos.redhat.com) (gcc version 4.8.3 20140911 > > (Red Hat 4.8.3-7) (GCC) ) #1 SMP Fri Dec 12 14:52:08 EST 2014 > > > > > > I've disabled NX flag on my Intel hosts and with installed RHEL7.0 on it, > > the hosted-engine deployment continued without detecting that virtualization > > actually turned-off/not supported: > > Not sure that's a problem, based on comment 5 and 6. > > (In reply to Evgheni Dereveanchin from comment #0) > > Description of problem: > > when using a CPU with VMX flag present but NX flag absent in CPU features, > > > > Version-Release number of selected component (if applicable): > > ovirt-hosted-engine-setup-1.1.2-5.el6ev.noarch > > > > How reproducible: > > always > > > > Steps to Reproduce: > > 1. install RHEL 6.5 on a server with VMX but without NX flag > > 2. install ovirt-hosted-engine-setup > > 3. run "hosted-engine --deploy" > > > > Actual results: > > 4. CPU check succeeds > > 5. libvirt does not detect the CPU family and installation is stuck on CPU > > type selection for the cluster. > > Was it stuck? Doesn't seem so from your log. > > > > > Expected results: > > 4. CPU check fails, installation is aborted > > I guess that's the reason you decided it failed, but as Alon mentioned in > comment 5, it might not always fail like that. > > > > > Additional info: > > we advertise NX support in docs, but the script does not check for it and > > lets installation continue. > > https://access.redhat.com/site/documentation/en-US/ > > Red_Hat_Enterprise_Virtualization/3.2/html/Hypervisor_Deployment_Guide/chap- > > Deployment_Guide- > > Requirements_and_limitations_of_Red_Hat_Enterprise_Virtualization_Hypervisors > > .html#idp19963536 > > We might actually want to do report "nx disabled" specifically, perhaps as a > warning, because even if virtualization works, the user might prefer to > enable nx before continuing. We might want to do that also in host-deploy, > for that matter. I've checked on 3 hosts, on one of them it forked as expected, PSB: hosted-engine --deploy [ INFO ] Stage: Initializing [ INFO ] Generating a temporary VNC password. [ INFO ] Stage: Environment setup Continuing will configure this host for serving as hypervisor and create a VM where you have to install oVirt Engine afterwards. Are you sure you want to continue? (Yes, No)[Yes]: Configuration files: [] Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20141228184700-xrvly0.log Version: otopi-1.3.0 (otopi-1.3.0-2.el7ev) It has been detected that this program is executed through an SSH connection without using screen. Continuing with the installation may lead to broken installation if the network connection fails. It is highly recommended to abort the installation and run it inside a screen session using command "screen". Do you want to continue anyway? (Yes, No)[No]: yes [ ERROR ] Failed to execute stage 'Environment setup': Hardware does not support virtualization [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20141228184708.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [root@alma03 ~]# rpm -qa ovirt-hosted-engine-setup ovirt-hosted-engine-setup-1.2.1-8.el7ev.noarch But on two others it didn't quit the installation as expected, although virtualization was turned-off, I suspect that really old machines with virtualization support not properly supporting the NX flag, in that case I think that this should be taken with PM to decide if FAD (functions as designed) or should be investigated deeper and fixed. (In reply to Nikolai Sednev from comment #10) > > But on two others it didn't quit the installation as expected, although > virtualization was turned-off, NX off != virtualization off > I suspect that really old machines with > virtualization support not properly supporting the NX flag, in that case I > think that this should be taken with PM to decide if FAD (functions as > designed) or should be investigated deeper and fixed. But did it actually work? Did you notice any problems? As I wrote above, I am not sure about the details, but we *might* be able to detect that nx is available and turned off, and then *might* want to warn/alert the user that it might better be turned on. That's a separate issue, which affects also host-deploy. (In reply to Yedidyah Bar David from comment #11) > (In reply to Nikolai Sednev from comment #10) > > > > But on two others it didn't quit the installation as expected, although > > virtualization was turned-off, > > NX off != virtualization off > > > I suspect that really old machines with > > virtualization support not properly supporting the NX flag, in that case I > > think that this should be taken with PM to decide if FAD (functions as > > designed) or should be investigated deeper and fixed. > > But did it actually work? Did you notice any problems? > > As I wrote above, I am not sure about the details, but we *might* be able to > detect that nx is available and turned off, and then *might* want to > warn/alert the user that it might better be turned on. That's a separate > issue, which affects also host-deploy. I didn't managed to complete installation, as I aborted it at the part, where VM should be installed with OS for the engine, the problem was that it had to be stopped and additional problem is that I see nx flag on new host, although virtualization disabled on it for sure and deployment interrupted. (In reply to Nikolai Sednev from comment #12) > (In reply to Yedidyah Bar David from comment #11) > > But did it actually work? Did you notice any problems? > > > > As I wrote above, I am not sure about the details, but we *might* be able to > > detect that nx is available and turned off, and then *might* want to > > warn/alert the user that it might better be turned on. That's a separate > > issue, which affects also host-deploy. > I didn't managed to complete installation, as I aborted it at the part, I wouldn't call this "didn't manage", then... > where VM should be installed with OS for the engine, the problem was that it > had to be stopped Why did it have to be stopped? If because you, as user, knew that nx is (supposed to be) disabled and decided you want to stop and enable, fine - that's what I wrote above. But I want to know what would happen if you didn't stop: 1. Disable nx flag in the bios 2. hosted-engine --deploy 3. any problem found? > and additional problem is that I see nx flag on new host, Where exactly? > although virtualization disabled on it for sure What do you mean here? I thought you said that _you_ disabled it, in the bios setup. > and deployment interrupted. (In reply to Yedidyah Bar David from comment #13) > (In reply to Nikolai Sednev from comment #12) > > (In reply to Yedidyah Bar David from comment #11) > > > But did it actually work? Did you notice any problems? > > > > > > As I wrote above, I am not sure about the details, but we *might* be able to > > > detect that nx is available and turned off, and then *might* want to > > > warn/alert the user that it might better be turned on. That's a separate > > > issue, which affects also host-deploy. > > I didn't managed to complete installation, as I aborted it at the part, > > I wouldn't call this "didn't manage", then... > > > where VM should be installed with OS for the engine, the problem was that it > > had to be stopped > > Why did it have to be stopped? If because you, as user, knew that nx is > (supposed to be) disabled and decided you want to stop and enable, fine - > that's what I wrote above. But I want to know what would happen if you > didn't stop: > 1. Disable nx flag in the bios > 2. hosted-engine --deploy > 3. any problem found? > > > and additional problem is that I see nx flag on new host, > > Where exactly? > > > although virtualization disabled on it for sure > > What do you mean here? I thought you said that _you_ disabled it, in the > bios setup. > > > and deployment interrupted. During deployment NX should be detected, if turned off, then deployment have to be aborted. I see NX flag while running "cat /proc/cpuinfo" on host with disabled NX in bios! Deployment interrupted on newer hosts only, might be they support NX as should be, while old hosts has the NX in bios as disabled, but still with no effect on he-deployment, like nx disabled not being recognized at all. Hi, just to try to make it a bit more clear. The originating issue was this one: https://bugzilla.redhat.com/show_bug.cgi?id=1100326 With Intel(R) Xeon(R) X5450 CPU, and similar ones, having VT enabled and NX disabled no compatible CPU was found. And so hosted-engine prompted The following CPU types are supported by this host: Please specify the CPU type to be used by the VM []: Allowing no valid entries. hosted-engine doesn't really detect the CPU features, it simply get that information from VDSM which get it from libvirt. So the solution is just that, if libvirt doesn't find any compatible CPU, hosted-engine instead of showing an empty list shows an hint for the user about checking VT/NX support. Nothing more. (In reply to Nikolai Sednev from comment #14) > During deployment NX should be detected, if turned off, then deployment have > to be aborted. Not really: not all the CPUs require NX support for VT support. It should abort if no compatible CPU are found and continue otherwise. > I see NX flag while running "cat /proc/cpuinfo" on host with disabled NX in > bios! Maybe be it could be a bug in the bios or the bios could be smart enough to keep NX support on if the user requires VT support on a CPU where VT support requires NX support. > Deployment interrupted on newer hosts only, might be they support NX as > should be, while old hosts has the NX in bios as disabled, but still with no > effect on he-deployment, like nx disabled not being recognized at all. The proper way to verify it is founding a CPU where VT requires NX and a bios where you can really disable it. With # vdsClient -s 0 getVdsCaps you could ensure that getCompatibleCpuModels() returns an empty list. In that situation you could verify this path. Without it hosted-engine will prompt: The following CPU types are supported by this host: Please specify the CPU type to be used by the VM []: With it hosted-engine should show: Hardware virtualization support is not available: please check BIOS settings and turn on NX support if available Hi, just to try to make it a bit more clear. The originating issue was this one: https://bugzilla.redhat.com/show_bug.cgi?id=1100326 With Intel(R) Xeon(R) X5450 CPU, and similar ones, having VT enabled and NX disabled no compatible CPU was found. And so hosted-engine prompted The following CPU types are supported by this host: Please specify the CPU type to be used by the VM []: Allowing no valid entries. hosted-engine doesn't really detect the CPU features, it simply get that information from VDSM which get it from libvirt. So the solution is just that, if libvirt doesn't find any compatible CPU, hosted-engine instead of showing an empty list shows an hint for the user about checking VT/NX support. Nothing more. (In reply to Nikolai Sednev from comment #14) > During deployment NX should be detected, if turned off, then deployment have > to be aborted. Not really: not all the CPUs require NX support for VT support. It should abort if no compatible CPU are found and continue otherwise. > I see NX flag while running "cat /proc/cpuinfo" on host with disabled NX in > bios! Maybe be it could be a bug in the bios or the bios could be smart enough to keep NX support on if the user requires VT support on a CPU where VT support requires NX support. > Deployment interrupted on newer hosts only, might be they support NX as > should be, while old hosts has the NX in bios as disabled, but still with no > effect on he-deployment, like nx disabled not being recognized at all. The proper way to verify it is founding a CPU where VT requires NX and a bios where you can really disable it. With # vdsClient -s 0 getVdsCaps you could ensure that getCompatibleCpuModels() returns an empty list. In that situation you could verify this path. Without it hosted-engine will prompt: The following CPU types are supported by this host: Please specify the CPU type to be used by the VM []: With it hosted-engine should show: Hardware virtualization support is not available: please check BIOS settings and turn on NX support if available Bios issue. Very old bios appears to be installed or NX functionality not being disabled on my two old hosts, although they're reporting it as disabled. 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/RHBA-2015-0161.html |