Hello, I'm playing with an openstack lab environment based on Icehouse on CentOS 7 and nested virtualization. Some details about the infra.
L0 Host is on Fedora 23: my laptop with ssd disk and 16Gb of ram, using Qemu/KVM and virt-manager
L1 Host is CentOS 7 with 4Gb of ram and configured with IceHouse rdo repo (EOL7) (copy host cpu config in virt-manager of Fedora 23) and packstack allinone
L2 is Centos 7 cloud image configured with 1Gb of ram CentOS-7-x86_64-GenericCloud.qcow2 download by end of February 2016
I'm able to do all on this L2 guest (eg ssh login with centos user through key and attch floating ip) but I noticed 2 things:
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 found this https://bugzilla.redhat.com/show_bug.cgi?id=1175502
but actually my VM is nested with kvm command line run by L1 is:
qemu 31641 1 88 13:36 ? 00:05:47 /usr/libexec/qemu-kvm -name instance-00000006 -S -machine pc-i440fx-rhel7.0.0,accel=tcg,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid e0680ada-1fc8-4d7a-829b-ba581a6252ef -smbios type=1,manufacturer=RDO Project,product=OpenStack Nova,version=2014.1.5-1.el7.centos,serial=14603773-bb9a-46e3-b333-07e0b68e65ac,uuid=e0680ada-1fc8-4d7a-829b-ba581a6252ef -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-00000006/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/e0680ada-1fc8-4d7a-829b-ba581a6252ef/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/nova/instances/e0680ada-1fc8-4d7a-829b-ba581a6252ef/disk.local,if=none,id=drive-virtio-disk1,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/var/lib/nova/instances/e0680ada-1fc8-4d7a-829b-ba581a6252ef/disk.swap,if=none,id=drive-virtio-disk2,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=27,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c5:ff:fc,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/e0680ada-1fc8-4d7a-829b-ba581a6252ef/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:1 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on
I solved the boot problem using extra property for the C7 image: glance image-update --property kernel_extra_args="no_timer_check"
and now I'm able to boot without problems Is it ok my approach? In case is it possible to configure the image itself directly? Or is there any drawback in setting that parameter?
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
What is it? Can I avoid in any way? For about 5-10 minutes my L0 laptop runs at 80 degrees... ;-) Is the load normal during that phase due to my resource constraints or is it in any way caused by the extra setting in 1) ?
Thanks in advance!
Gianluca
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
-
Gianluca Cecchi -
Laurențiu Păncescu