Hello Gianluca,
On 3/15/16, Gianluca Cecchi gianluca.cecchi@gmail.com wrote:
- 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.
- 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