Since you can't reproduce when upgrading old system and even downgrading the package in a freshed system doesn't make the issue go away, this looks like a configuration issue. However, I'm not sure where to look. Matthew, do you have any idea?

The libvirt connection is made like this:

    my $vmm;
    eval {
        $vmm = Sys::Virt->new(
            uri => $uri,
            auth => 1,
            credlist => [
                Sys::Virt::CRED_AUTHNAME,
                Sys::Virt::CRED_PASSPHRASE
            ],
            callback => sub {
                my $creds = shift;

                foreach my $cred (@$creds) {
                    if ($cred->{type} == Sys::Virt::CRED_AUTHNAME) {
                        $cred->{result} = $self->{username};
                    }

                    elsif ($cred->{type} == Sys::Virt::CRED_PASSPHRASE) {
                        $cred->{result} = $self->{password};
                    }

                    else { die($cred->{type}, "\n"); }
                }
            }
        );
    };
    v2vdie __x('Failed to connect to {uri}: {error}',
               uri => $uri, error => $@->stringify()) if $@;

I'm going to go out on a limb and guess this is an authentication issue, which causes libvirt to fall through to attempting SSL cert authentication. Is that feasible?

Tingting, are you sure that the password in .netrc is correct? How about that leading '$'.

(In reply to Matthew Booth from comment #4)
> I'm going to go out on a limb and guess this is an authentication issue,
> which causes libvirt to fall through to attempting SSL cert authentication.
> Is that feasible?
> 
> Tingting, are you sure that the password in .netrc is correct? How about
> that leading '$'.

Yes,I am sure the password is correct.We have tried several newly installed machine and can always reproduce this issue.

Could you turn on libvirt debug messages

# export LIBVIRT_DEBUG=1
# export LIBVIRT_LOG_OUTPUTS="1:file:libvirt-client.log

and run the virt-v2v command on both the fresh system and the upgraded system and also run the virsh command on the fresh system. Once done, please attach the three libvirt logs.

Created attachment 802537 [details]
Log info on fresh system

Created attachment 802538 [details]
Log info on upgrade system

(In reply to Jiri Denemark from comment #6)
> Could you turn on libvirt debug messages
> 
> # export LIBVIRT_DEBUG=1
> # export LIBVIRT_LOG_OUTPUTS="1:file:libvirt-client.log
> 
> and run the virt-v2v command on both the fresh system and the upgraded
> system and also run the virsh command on the fresh system. Once done, please
> attach the three libvirt logs.

Related logs are attached refer to comment 7 and comment 8.

I tried running both virt-v2v and virsh commands in gdb and esxVI_Context_Connect() is called with exactly the same parameters in both cases (i.e., the same URI, username, and password). However, connecting to esx fails from virt-v2v in esxVI_RetrieveServiceContent() while from virsh the function successfully connects to esx and retrieves the desired data. The point where the two commands differ in execution is in NSS_InitContext called from curl's nss.c:892 with cerpath = "sql:/etc/pki/nssdb". I don't really know what that means but I assume virt-v2v must be changing the environment in some way...

I installed a new system with tree RHEL6.5-20130925.2,related version:
qemu-kvm-0.12.1.2-2.406.el6.x86_64
kernel-2.6.32-420.el6.x86_64
libvirt-0.10.2-27.el6.x86_64
virt-v2v-0.9.1-3.el6.x86_64

Retested the issue and the bug can not be reproduced anymore.

OK, I'm closing this bug. Feel free to reopen if it ever appears again.