Hide Forgot
The CPU type is used by RHEV-M for compatibility - eg. Nehalem family, westmere, etc. A common issue from users is to understand what CPU they have and it's capabilities - eg. VT/SVM and NX being disabled are problem for us. We should provide CPU name (eg. "Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz") CPU Type (eg. Intel Westmere) Virtualization Extensions enabled (true|false) If XD(NX) is set for Intel machines or "Enhanced Virus Protection" for AMD machines Socket Count : eg 2 Socket Cores per Socket: eg 4 Hyperthreading enabled : Yes / no (only for AMD)
> A common issue from users is to understand what CPU they have and it's > capabilities - eg. VT/SVM and NX being disabled are problem for us. Libvirt 0.9.10+ now provides a standalone command expressly for validating the scenario fo VT/SVM being off in the BIOS. eg you can run # virt-host-validate qemu QEMU: Checking for hardware virtualization : PASS QEMU: Checking for device /dev/kvm : PASS QEMU: Checking for device /dev/vhost-net : PASS QEMU: Checking for device /dev/net/tun : PASS we don't check NX currently, but that could be added. The virt-host-validate command is intended to be used by users / admins to sanity check their hardware prior to running libvirt/KVM
(In reply to comment #4) > > A common issue from users is to understand what CPU they have and it's > > capabilities - eg. VT/SVM and NX being disabled are problem for us. > > Libvirt 0.9.10+ now provides a standalone command expressly for validating the > scenario fo VT/SVM being off in the BIOS. eg you can run > > # virt-host-validate qemu > QEMU: Checking for hardware virtualization : > PASS > QEMU: Checking for device /dev/kvm : > PASS > QEMU: Checking for device /dev/vhost-net : > PASS > QEMU: Checking for device /dev/net/tun : > PASS > > > we don't check NX currently, but that could be added. The virt-host-validate > command is intended to be used by users / admins to sanity check their hardware > prior to running libvirt/KVM Dan what's your thoughts on adding the virsh capabilities cpu vendor|model output there as well ? Alternatively we just parse that ourselves.
We could add a check that the host CPU model, is resolvable to one of the CPU models in cpu_map.xml - that would catch the NX problem nicely.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Test version: rhev-hypervisor6-6.4-20121212.1.el6 ovirt-node-2.5.0-11.el6 Tested as follows: 1. clean install rhev-h 2. Enter into status page 3. click the "<view cpu details>" button to view CPU Details Info CPU Details page provide the follow item info: CPU Name/CPU Type/Virtualization Extensions Enabled/Flag/CPU Sockets/CPU Cores so this bug has been fixed, change the the status into "VERIFIED"
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. http://rhn.redhat.com/errata/RHBA-2013-0556.html