[libvirt-users] migrated RHEL7/CentsOS7 VMs fail to boot

[Daniel Pocock]

I migrated a CentOS7 VM (the fedrtc.org site) from an XCP environment to
a libvirt/KVM environment.

This involved using qemu-img to convert the image from VHD to qcow2 and
then using virt-install --import to define the VM in libvirt.

Three problems occurred during boot:

a) on the first boot, the BIOS screen and grub screen don't appear at
all, the screen is blank for a couple of seconds and then the message
about loading a kernel appears.  Hard reset and on the second and
subsequent attempts I see the grub screen and have the opportunity to
interact with it.  This actually happened with many of my VMs, not just
the CentOS7 VM.

b) with console=hvc0 in the grub config, the kernel refused to boot, no
error appeared on the screen.  I was able to remove that easily enough
by pressing "e" in grub.  Rather than halting, should the kernel fall
back to VGA perhaps when the console= argument is not valid?  Or could
KVM emulate the Xen console device to make migrations easier?

c) after that, the boot proceeds up to about the point where I see
systemd messages about starting basic system.  Then it sits there for a
few minutes and then these messages appear:
  warning: dracut-initqueue timeout - starting timeout scripts
and after that I see "A start job is running for dev-mapp...oot.device
(X min Ys/ no limit)
Rebooting and choosing the "rescue" image from the bottom of the grub
menu got me past that, I was able to log in and then I ran:

   dracut --kver 3.10.0-514.10.2.el7.x86_64 --force

and on the next attempt it was able to boot successfully.  The block
device for the root FS is an LVM volume (so the name should have been
constant) and the block device for the /boot filesystem listed in
/etc/fstab was mounted by UUID (the block device name itself changed
from xvda1 (XCP) to vda1 (KVM)).  All my Debian VMs were able to cope
with this device name changing.  The CentOS7 system was originally
installed using default settings for just about everything.

Why does dracut need to be re-run in this situation?  Should a bug
report be filed about this?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2017-03-19-fedrtc-centos7-boot-failure.png
Type: image/png
Size: 16100 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170320/5229cbf8/attachment.png>