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