Description of problem: convert rhel4u8 guest from esx to kvm (libvirt and rhevm) modprobe.conf is incorrect the network and storage driver are not virtio Version-Release number of selected component (if applicable): virt-v2v-0.6.3-5.el5 libguestfs-1.2.7-1.el5.8 libguestfs-*-1.2.7-1.el5.8 libvirt-0.8.2-15.el5_6.1 febootstrap-2.6-1.el5.2 hivex-1.2.2-1.el5.1 augeas-libs-0.7.3-1.el5.1 virtio-win-1.0.1-2.52454.el5 RHEVM ic91 rhevh-5.6-8.1 How reproducible: always Steps to Reproduce: 1.# virt-v2v -ic esx://10.66.72.149/?no_verify=1 -op esx -n default ESX4.0-rhel4u8-32b unknown filesystem /dev/hdc unknown filesystem /dev/fd0 virt-v2v: No capability in config matches os='linux' name='virtio' distro='redhat-based' virt-v2v: ESX4.0-rhel4u8-32b configured without virtio drivers 2.check the modprobe.conf # cat /etc/modprobe.conf alias eth0 e1000 Actual results: alias eth0 e1000 Expected results: alias eth0 virtio Additional info: esx3.5 esx4.0 and esx4.1 all can reproduce this bug /boot/devive.map is not update if the guest is rhel4u9 ,everything is fine .
Created attachment 478589 [details] ESX4.1-RHEL4.8-64b.log
set Priority: low Severity:low sorry Matt , We install the wrong guest(redhat desktop 4u8 ) ,the "Red Hat Enterprise Linux 4u8" is fine ,but it is also a bug .
Note from the error message that the guest OS has been detected as 'redhat-based', which we don't have any config for: virt-v2v: No capability in config matches os='linux' name='virtio' distro='redhat-based' This seems to be an oversight in libguestfs's OS detection. I've moved this to to libguestfs and updated the title.
Huang, could you please let us know the contents of the file: /etc/redhat-release from *inside* the guest?
From guest: #cat /etc/redhat-release Red Hat Desktop release 4 (Nahant Update 8)
I see the problem. Cloning this bug for upstream and 6.2.
Damn I'd forgotten about this bug (or rather, have plans to fix it in 6.2). We're too late for 5.7 obviously, and unless we rebase libguestfs and virt-v2v in 5.x (not likely) we can't fix it very easily. Since this hasn't been reported by a customer and we are going to fix it in RHEL 6, I'm closing this. Please reopen if there is a reason to fix this in RHEL 5, but be aware that a fix could be disruptive.