Bug 670725
| Summary: | Failed to conduct remote tls connection test via ipv6. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | wangyimiao <yimwang> |
| Component: | libvirt | Assignee: | Laine Stump <laine> |
| Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.1 | CC: | dallan, eblake, xen-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-01-22 19:39:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
1.On client host ping server host # ping6 -c 3 3ffe::102 PING 3ffe::102(3ffe::102) 56 data bytes 64 bytes from 3ffe::102: icmp_seq=1 ttl=64 time=0.204 ms 64 bytes from 3ffe::102: icmp_seq=2 ttl=64 time=0.236 ms 64 bytes from 3ffe::102: icmp_seq=3 ttl=64 time=0.242 ms --- 3ffe::102 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.204/0.227/0.242/0.020 ms 2.On server host ping client host # ping6 -c 3 3ffe::101 PING 3ffe::101(3ffe::101) 56 data bytes 64 bytes from 3ffe::101: icmp_seq=1 ttl=64 time=1.31 ms 64 bytes from 3ffe::101: icmp_seq=2 ttl=64 time=0.226 ms 64 bytes from 3ffe::101: icmp_seq=3 ttl=64 time=0.247 ms --- 3ffe::101 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 0.226/0.596/1.317/0.510 ms I'm not sure why this separate bug was filed; the issue seems to be exactly the same as bug 624626. The error message is identical, and as a matter of fact, the example program attached to that bug will also fail if uri.scheme is qemu+tls rather than qemu+ssh. I'm closing this as a duplicate of Bug 624626. If a separate bug is needed for tracking purposes, feel free to reopen this bug, but set the component to libxml2, because that's where the problem lies. *** This bug has been marked as a duplicate of bug 624626 *** |
Description of problem: Failed to conduct remote tls connection test via ipv6. Version-Release number of selected component (if applicable): libvirt-0.8.7-2.el6.x86_64 qemu-kvm-0.12.1.2-2.129.el6.x86_64 qemu-img-0.12.1.2-2.129.el6.x86_64 kernel-2.6.32-94.el6.x86_64 How reproducible: 5/5 Steps to Reproduce: Precondition: 1)2 host installed with kvm kernel 2)libvirtd service is running on both system 3)require package "gnutls-utils" installed 4)ipv6 configuration on client and server a) on client host: 1.Configure ipv6 global addr #ifconfig eth0 inet6 add 3ffe::101/64 # ip6tables -F 2.configure ipv6 hostname add the following line into /etc/hosts 3ffe::102 dhcp-93-206.nay.redhat.com dhcp-93-206 b) on server host 1.Configure ipv6 global addr # ifconfig eth0 inet6 add 3ffe::102/64 # ip6tables -F Steps: On server (3ffe::102) 1. Set up a Certificate Authority (CA) 1.1 # certtool --generate-privkey > cakey.pem 1.2 self-sign cakey.pem by creating a file with the signature details called ca.info containing: cn = 3ffe::102 ca cert_signing_key 1.3 # certtool --generate-self-signed --load-privkey cakey.pem --template ca.info --outfile cacert.pem 2. Create server certificates 2.1 certtool --generate-privkey > serverkey.pem 2.2 sign that key with the CA's private key by first creating a template file called server.info organization = Red Hat cn = 3ffe::102 tls_www_server encryption_key signing_key 2.3 # certtool --generate-certificate --load-privkey serverkey.pem --load-ca-certificate cacert.pem \ --load-ca-privkey cakey.pem --template server.info --outfile servercert.pem 3. Copy CA key and server key to correct directory 3.1 # cp cakey.pem cacert.pem /etc/pki/CA 3.2 # mkdir -p /etc/pki/libvirt/private 3.3 # cp serverkey.pem /etc/pki/libvirt/private 3.4 # cp servercert.pem /etc/pki/libvirt 4. Copy CA key to client(3ffe::101) into correct directory 4.1 # scp cakey.pem cacert.pem root@${Clinet host name}:/etc/pki/CA 5. Add a user named "fred", and setting his password as "redhat" # saslpasswd2 -a libvirt fred Password: xxxxxx Again (for verification): xxxxxx 6. Turn on libvird monitor listening in /etc/sysconfig/libvirtd -- uncomment LIBVIRTD_ARGS="--listen" 7. Edit /etc/libvirt/libvirtd.conf -- enbale listen_tls = 1 -- enable auth_tls = "sasl" 8. # service libvirtd restart 9. # service ip6tables stop On client (3ffe:101) 10. Create client certificates 10.1 # certtool --generate-privkey > clientkey.pem 10.2 Act as CA and sign the certificate. Create client.info containing: country = GB state = London locality = London organization = Red Hat cn = 3ffe::101 tls_www_client encryption_key signing_key 10.3 # certtool --generate-certificate --load-privkey clientkey.pem --load-ca-certificate /etc/pki/CA/cacert.pem \ --load-ca-privkey /etc/pki/CA/cakey.pem --template client.info --outfile clientcert.pem 11. Copy client key to correct directory 11.1 # mkdir -p /etc/pki/libvirt/private 11.2 # cp clientkey.pem /etc/pki/libvirt/private 11.3 # cp clientcert.pem /etc/pki/libvirt/ 12. Conect to server hypervisor using fred # virsh -c qemu+tls://[3ffe::102]/system error: unable to resolve hostname '[3ffe::102]': Name or service not known error: failed to connect to the hypervisor Actual results: Failed to conduct remote tls connection test via ipv6. Expected results: Remote connection must be successful. Additional info: Please refer to the bug 624626.