[CentOS-devel] info about centos 7 cloud images and no_timer_check

Laurențiu Păncescu

lpancescu at gmail.com
Tue Mar 15 19:19:03 UTC 2016


Hello Gianluca,

On 3/15/16, Gianluca Cecchi <gianluca.cecchi at gmail.com> wrote:
> 1) I was not able to boot because the VM always remained stuck at boot at
> message:
>   ...trying to set up timer as Virtual Wire IRQ...
>
> I solved the boot problem using extra property for the C7 image:
> glance image-update --property kernel_extra_args="no_timer_check"

no_timer_check should be passed to the kernel in all virtualization
setups. Some virtualization setups do this automatically (if they boot
the kernel directly, instead of a boot manager like pv-grub - I
thought KVM implemented this sometime in 2014); if not, you should add
this yourself to the boot configuration of your guests.

This parameter disables a Linux kernel check, which tests that the
timer IRQ is routed correctly (or at all). This used to be a hardware
bug with some interrupt controllers, when they used to be separate
chips on the mainboard. I don't think you'll be able to find real
hardware exhibiting that bug any more, it's been many years. Nowadays
this check only annoys people using virtualization: depending on the
host load, the timer check sometimes produces false alarms and
occasionally guest kernel panics.

> 2) Just at first boot the VM uses much cpu because of this process:
>  root      3119  2024  4 12:42 ?        00:00:09 /bin/bash /usr/sbin/dracut
> --hostonly --hostonly-cmdline --hostonly-i18n -o plymouth dash resume ifcfg
> -f /boot/initramfs-3.10.0-327.10.1.el7.x86_64kdump.img
> 3.10.0-327.10.1.el7.x86_64
>

dracut produces initramfs images (minimal ones, containing only the
necessary modules for booting on that hardware, due to the --hostonly
parameter). I noticed this too when booting the CentOS image for the
first time via Vagrant, but it only generates IO load for me, no
overheating, and since it's over within some tens of seconds... Since
virtualization images tend to boot on a very limited subset of
hardware, perhaps this could be optimized away by splitting the kernel
modules in different packages, like Fedora does.

Regards,
Laurentiu



More information about the CentOS-devel mailing list