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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
