Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Tuesday, December 30, 2014

ELRepo : kernel-ml

ELRepo : kernel-ml



kernel-ml

Kernel-ml for Enterprise Linux 7.

The kernel-ml packages are built from the sources available from the "mainline stable" branch of The Linux Kernel Archives (external link). The kernel configuration is based upon the default RHEL-7 configuration with added functionality enabled as appropriate. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-7 kernels and, as such, they may be installed and updated alongside the regular kernel.

To install kernel-ml you will need elrepo-release-7.0-1.el7.elrepo (or newer). Run:

yum --enablerepo=elrepo-kernel install kernel-ml

You can also Download manually from http://elrepo.org/linux/kernel/el7/ (external link)
(Or from one of our mirror sites, if one is more conveniently located closer to you.)

There is no need to install the kernel-ml-headers package. It is only necessary if you intend to rebuild glibc and, thus, the entire operating system. If there is a need to have the kernel headers installed, you should use the current distributed kernel-headers package as that is related to the current version of glibc.

Notes

These packages are provided 'As-Is' with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service.

If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker (external link) and, for our reference, to the ELRepo bug tracker. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole.

Kernel-ml for Enterprise Linux 6.

The kernel-ml packages are built from the sources available from the "mainline stable" branch of The Linux Kernel Archives (external link). The kernel configuration is based upon the default RHEL-6 configuration with added functionality enabled as appropriate. The packages are intentionally named kernel-ml so as not to conflict with the RHEL-6 kernels and, as such, they may be installed and updated alongside the regular kernel.

To install kernel-ml you will need elrepo-release-6-4.el6.elrepo (or newer). Run:

yum --enablerepo=elrepo-kernel install kernel-ml

You can also Download manually from http://elrepo.org/linux/kernel/el6/ (external link)
(Or from one of our mirror sites, if one is more conveniently located closer to you.)

There is no need to install the kernel-ml-firmware package. There are more firmware files contained within the distro package than in the kernel-ml-firmware package.

There is no need to install the kernel-ml-headers package. It is only necessary if you intend to rebuild glibc and, thus, the entire operating system. If there is a need to have the kernel headers installed, you should use the current distributed kernel-headers package as that is related to the current version of glibc.

Notes

These packages are provided 'As-Is' with no implied warranty or support. Using the kernel-ml may expose your system to security, performance and/or data corruption issues. Since timely updates may not be available from the ELRepo Project, the end user has the ultimate responsibility for deciding whether to continue using the kernel-ml packages in regular service.

If a bug is found when using these kernels, the end user is encouraged to report it upstream to the Linux Kernel Bug Tracker (external link) and, for our reference, to the ELRepo bug tracker. By taking such action, the reporter will be assisting the kernel developers, Red Hat and the Open Source Community as a whole.

Known Issues

(1) As of kernel-ml-3.10.5-1.el6.elrepo, kernel-ml installed as a KVM guest will panic upon booting (FATAL: Module scsi_wait_scan not found error). This is because virtio_blkis not in the initramfs. More details can be found in:

http://elrepo.org/bugs/view.php?id=401 (external link)
https://bugzilla.kernel.org/show_bug.cgi?id=60758 (external link)

A workaround is to rebuild initramfs with a "--add-drivers virtio_blk" option. For example:

dracut --add-drivers virtio_blk -f /boot/initramfs-3.10.5-1.el6.elrepo.x86_64.img 3.10.5-1.el6.elrepo.x86_64

(2) As of kernel-ml-3.12.2-1.el6.elrepo, the userland process acpid will fail. This was caused by a change in the upstream kernel source which dropped support for the acpid-1 interface, as used by RHEL-6. See the following links for more details:

http://elrepo.org/bugs/view.php?id=435 (external link)
https://bugzilla.kernel.org/show_bug.cgi?id=66681 (external link)

Users of the kernel-ml package are encouraged to install the acpid-2 package to restore system acpi functionality. (It is believed that the acpid-2 package will also work with the distribution kernel but this has not been fully verified.)



Page last modified on Monday 13 of October, 2014 10:02:47 MDT

Tuesday, September 23, 2014

Some research on performance KVM vs ESX

Case1: Tools: SPECvirt_sc2010 http://www.spec.org/virt_sc2010/results/specvirt_sc2010_perf.html Sames HW, ESXi 4.1 scores 3824 with 234 VMs, KVM 4603 and host 282 VMs, which is 20% higher. Case2: Tools: SPECvirt_sc2010 http://www.spec.org/virt_sc2010/results/specvirt_sc2010_perf.html 3894 vs 3723, KVM 4.5% higher. Case3: Tools: SPECvirt_sc2013 (New tools, as of 9/24/2014 only the below data avaiable) http://www.spec.org/cgi-bin/osgresults RHEL7 1614 with 90 VMs on a E5-2699v3 platform, which is much higher than last generation E5-2697v2 with 935 and 50VMs. KVM is clearly better on the performance side, and also the price side.