View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012632||CentOS-7||qemu-kvm||public||2017-01-10 19:01||2017-01-24 20:57|
|Summary||0012632: Unable to boot nested guest using OpenStack Mitaka and seabios-bin-1.9.1-5.el7.noarch|
|Description||This initially showed up in the TripleO Mitaka CI jobs, but I've since reproduced it locally. When using the current versions of qemu-kvm and seabios-bin in CentOS 7 base our unaccelerated nested instances fail to boot. This was first reported here: https://bugs.launchpad.net/tripleo/+bug/1654615|
These were my findings from that bug:
It appears to have something to do with the newer seabios-bin package that came in since this job was working. The current failing version is seabios-bin-1.9.1-5.el7.noarch. If I download the older seabios-1.7.5-11.el7.x86_64.rpm from http://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ then booting the vm works as expected and it pings correctly. This is also the version of seabios-bin that was in the last passing mitaka job I can find.
I also tried going back to 1.9.1 to verify it wasn't the vm reboot alone that fixed the problem. It hung again on the newer package.
I've since also discovered that using qemu-kvm from the rdo-qemu-ev repo (http://mirror.centos.org/centos/7/virt/\$basearch/kvm-common/) does not have this problem either. I believe that's why TripleO CI on later releases of OpenStack is still working. It uses rdo-qemu-ev by default.
|Steps To Reproduce||Deploy OpenStack Mitaka using TripleO in a virtual environment. Try to boot a nested vm without acceleration. It will hang on the initial boot screen at an iPXE line.|
|Additional Information||Logs from an affected CI run can be found here (note that they will expire after a month or two): http://logs.openstack.org/29/418129/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha-mitaka/9de9c4d/logs/overcloud-novacompute-0/var/log/|
|Tags||No tags attached.|
Which exact qemu-kvm version are you using?
AFAICT this should be reported in RHEL bugzilla.
Oops, the qemu-kvm version is qemu-kvm-1.5.3-126.el7.x86_64 According to yum info it comes from the base repo.
I don't know whether this happens on RHEL. Should I report it there anyway?