Bug 707261

Sorry, I had mistake.

--
Actual results:
alias eth0 e1000
alias scsi_hostadapter virtio_blk
alias scsi_hostadapter1 virtio_blk
alias scsi_hostadapter2 virtio_blk

Expected results:
alias eth0 virtio_net
alias scsi_hostadapter virtio_blk

Hajime,

I suspect weirdness here relating to the uninstallation of vmware-tools. Could you please run the conversion again with LIBGUESTFS_TRACE=1, e.g.:

# LIBGUESTFS_TRACE=1 virt-v2v -ic esx://esx.server.host/?no_verify=1 -op default --bridge br0 RHEL5

and attach the full output to this BZ?

Could you also confirm whether the guest has vmware-tools installed and, if so, was it installed via RPM or tarball?

Thanks,

Matt

> and attach the full output to this BZ?

Yes.
I captured log via following script.

file: conv.sh
#!/bin/bash
LIBGUESTFS_TRACE=1 virt-v2v -ic esx://10.208.81.5/?no_verify=1 -op default --bridge br0 RHEL5 2>&1 | tee -a virt-v2v-rhel5.log

> Could you also confirm whether the guest has vmware-tools installed and, if so,
> was it installed via RPM or tarball?

I installed VMware-Tools via tarball (It is provided by ISO image of VMware).

And I found a clue about this problem.
ethX device entry had missing in the original modprobe.conf file.

Created attachment 500721 [details]
The original modprobe.conf file in RHEL5

I tried to add entry 'alias eth0 vmxnet3' to original /etc/modprobe.conf file.
And I check new /etc/modprobe.conf file. It is following.

Actual results:
alias eth0 virtio_net
alias scsi_hostadapter virtio_blk
alias scsi_hostadapter1 virtio_blk
alias scsi_hostadapter2 virtio_blk

Please change title of this issue.
"virt-v2v added 'alias eth0 e1000' device entry to /etc/modprobe.conf in RHEL5.5, but host environment had virtio capability."

To replicate this:

Install RHEL 5 on ESX
Install VMware tools from tarball
Edit /etc/modprobe.conf and remove the alias for eth0

After conversion, /etc/modprobe.conf will contain 'alias eth0 e1000' as reported above.

This happens because of a combination of 2 things:

Firstly, vmware tools doesn't do anything intelligent when it uninstalls itself. It made a backup of /etc/modprobe.conf at the time it was installed, and copies this backup over /etc/modprobe.conf when it is uninstalled. No attempt is made to preserve changes to /etc/modprobe.conf in the intervening period. This is a bug in vmware tools.

Secondly, virt-v2v scans modprobe.conf during initial inspection. At this point, modprobe.conf doesn't contain an eth0 entry. virt-v2v later runs vmware-uninstall-tools.pl, which copies the backup modprobe.conf into place. modprobe.conf now does contain an eth0 entry, but virt-v2v only iterates over the list of entries it found originally, so ignores the new eth0 entry. This is also why eth0 is correctly updated if it isn't manually removed from modprobe.conf

A couple of things to note on this:

It's a real weird edge case. If you don't make this unusual manual alteration to modprobe.conf, you'll never hit it.

For some reason I don't understand, the guest continues to use virtio networking correctly anyway. This means that, apart from having an untidy entry in modprobe.conf, the bug has no impact.

Verify this bug in virt-v2v-0.8.3-4.el6


#  virt-v2v -ic esx://10.66.72.79/?no_verify=1 -os r6 -b breth0  esx4.1-rhel5.7-x86_64-wl-vmtools  
esx4.1-rhel5.7-x86_64-wl-test_esx4.1-rhel5.7-x86_64-wl-test: 100% [================================================================]D 0h10m13s
virt-v2v: esx4.1-rhel5.7-x86_64-wl-vmtools configured with virtio drivers.

In the guest after conversion 

#cat /etc/modprode.conf
alias eth0 virtio_net 
alias scsi_hostadapter virtio_blk

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1615.html