libvirt users - Mar 2017 - migrated RHEL7/CentsOS7 VMs fail to boot

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?

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@redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users

On 20/03/17 15:02, Martin Kletzander wrote:
> 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.
> 
All my test migrations had worked successfully with "virt-install
--import ..." so I never looked into virt-v2v.  Thanks for pointing
this out though.

Nonetheless, is there a reason the RHEL/CentOS VM requires the dracut
command to be run but the Debian/Ubuntu VMs don't need
update-initramfs to be run?  Should I open a bug or feature request
against dracut to make this easier, or has it been discussed previously?

Regards,

Daniel