Hi everyone,
I'm trying to convert a CentOS (5.5) xen virtual machine to a KVM based one. I exported the XML, copied it and the device data (LVM partitions on both boxes); adjusted the disk device path and the name of the bridge in the XML and then ran:
virt-v2v -f /etc/virt-v2v.conf -i libvirtxml mongo1.xml
My virt-v2v.conf is below.
The command exits with "virt-v2v: Didn't find a grub entry for kernel version 2.6.18-194.8.1.el5" -- how do I fix that?
The virt-v2v version is 0.4.0-1.
- ask
<virt-v2v> <path-root>/var/lib/virt-v2v/software</path-root> <iso-path>/var/lib/virt-v2v/transfer.iso</iso-path>
<app os='centos' name='kernel' major='5' minor='5' arch='x86_64'> <path>centos/5/kernel-2.6.18-194.8.1.el5.x86_64.rpm</path> <dep>centos/5/ecryptfs-utils-75-5.el5.x86_64.rpm</dep> <dep>centos/5/lvm2-2.02.56-8.el5_5.6.x86_64.rpm</dep> <dep>centos/5/device-mapper-1.02.39-1.el5_5.2.x86_64.rpm</dep> <dep>centos/5/device-mapper-event-1.02.39-1.el5_5.2.x86_64.rpm</dep> </app>
<!-- Networks --> <!-- The default Xen bridge name --> <network type='bridge' name='xenbr1'> <network type='network' name='default'/> </network>
<!-- The default ESX bridge name --> <network type='bridge' name='VM Network'> <network type='network' name='default'/> </network> </virt-v2v>
On Wed, Aug 04, 2010 at 04:06:45PM -0700, Ask Bjørn Hansen wrote:
The virt-v2v version is 0.4.0-1.
This is pretty old. Latest version is 0.6.something. What is the host OS?
Rich.
On Aug 6, 2010, at 10:18, "Richard W.M. Jones" rjones@redhat.com wrote:
The virt-v2v version is 0.4.0-1.
This is pretty old. Latest version is 0.6.something. What is the host OS?
Sorry; thought I included that! CentOS/RHEL 5.5 (both old host, new host and guest). I ran v2v on the new host after copying over the image.
I also tried installing the regular non-xen kernel first, then moving the image and running v2v, but it gave me the same "can't find grub entry" error.
Finally I tried just starting the system (after booting on the xen host, making the non-xen kernel the default and copying over the image). It looks like it'd just begin loading the kernel, but locks up using 100% of one of the host CPUs (the qemu-kvm process does).
- ask