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

[Martin Kletzander]

On Mon, Mar 20, 2017 at 10:18:35AM +0100, Daniel Pocock wrote:
>
>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.
>

I have little to no idea how to help with the rest, but have you tried
using virt-v2v for the switch?  It could help you a lot with some of
these things.  I hope your use case is supported, I haven't really had
many use cases for if myself.

>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?


>_______________________________________________
>libvirt-users mailing list
>libvirt-users at redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170320/e574fe6b/attachment.sig>