Hide Forgot
Description of problem: I have libvirtd with tweaked "default" network on a system without IPv4 address (only loopback is available in IPv4). When I'm starting some guest, I'm getting traceback. Version-Release number of selected component (if applicable): libvirt-0.9.4-23.el6_2.4.x86_64 How reproducible: always Steps to Reproduce: 1. make sure you are on system with IPv6 address 2. remove virbr0 setup and alter "default" network (as seen below) 3. try to start guest Actual results: # virsh start virt01 error: Failed to start domain virt01 error: internal error Process exited while reading console log output: char device redirected to /dev/pts/2 getaddrinfo(127.0.0.1,5902): Name or service not known Expected results: Guest should be started. Guest should not be created with config forcing to listen on IPv4 localhost. Additional info: # ifconfig br0 Link encap:Ethernet HWaddr 00:23:7D:4C:9F:05 inet6 addr: 2620:52:0:221b:223:7dff:fe4c:9f05/64 Scope:Global inet6 addr: fe80::223:7dff:fe4c:9f05/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:994075 errors:0 dropped:0 overruns:0 frame:0 TX packets:288086 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:405614250 (386.8 MiB) TX bytes:457392180 (436.2 MiB) eth1 Link encap:Ethernet HWaddr 00:23:7D:4C:9F:05 inet6 addr: fe80::223:7dff:fe4c:9f05/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:1659090 errors:0 dropped:0 overruns:0 frame:0 TX packets:743493 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1391698044 (1.2 GiB) TX bytes:499968688 (476.8 MiB) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:275451 errors:0 dropped:0 overruns:0 frame:0 TX packets:275451 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:558730674 (532.8 MiB) TX bytes:558730674 (532.8 MiB) # virsh net-list Name State Autostart ----------------------------------------- default active yes # virsh net-dumpxml default <network> <name>default</name> <uuid>7ab87ca1-72c0-ce33-8045-e82950c81d9e</uuid> <forward mode='bridge'/> <bridge name='br0' /> </network> # virsh dumpxml virt01 <domain type='kvm'> [...] <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> <listen type='address' address='127.0.0.1'/> </graphics> [...] When I `virsh edit virt01` and edited '127.0.0.1' to '::1' in '<graphics...' it worked. OR when I have reconfigured guest to use bridged br0 directly and restored configuration of 'default' network to default config (nat-ed virtual network with virbr0)
See /etc/libvirt/qemu.conf: # VNC is configured to listen on 127.0.0.1 by default. # To make it listen on all public interfaces, uncomment # this next option. # # NB, strong recommendation to enable TLS + x509 certificate # verification when allowing public access # # vnc_listen = "0.0.0.0" You need to set vnc_listen = "::1" if you want IPv6 only setup. BTW, spice has similar configuration option there.
Oh, that explains things! So it did not worked because network of the guest was bridged through IPv6-only bridge, right? Thanks, Jan.
I'm switching component to qemu. This error message is reported by qemu in early starting phase and libvirt just passes it through. It would be great if qemu could print a more descriptive error message.
(In reply to comment #5) > I'm switching component to qemu. This error message is reported by qemu in > early starting phase and libvirt just passes it through. > > It would be great if qemu could print a more descriptive error message. How about add this error? getaddrinfo(::1,5923): Name or service not known Failed to start VNC server on `127.0.0.1:5902'
The actutal bug is in glibc, see also Fedora bug 808147. The getaddrinfo(127.0.0.1) and getaddrinfo(::1) should *never* fail.
Any information available? This bug was not really easy to fix so I would like to see the actual fixes to know if they are valid or not.
Reproduced on qemu-kvm-0.12.1.2-2.295.el6.x86_64. Steps: 1. Boot a guest with virsh (using bridge network). 2. Shutdown guest and flush all the ipv4 addr of the host network interface (eth*,bridge,virbr0) 3. # virsh start $domain Result: virsh # start vm error: Failed to start domain test error: internal error process exited while connecting to monitor: char device redirected to /dev/pts/6 getaddrinfo(127.0.0.1,5900): Name or service not known Verified pass on qemu-kvm-0.12.1.2-2.337.el6.x86_64 with the same steps. Result: # virsh start test error: Failed to start domain test error: internal error process exited while connecting to monitor: char device redirected to /dev/pts/6 getaddrinfo(127.0.0.1,5900): Name or service not known Failed to start VNC server on `127.0.0.1:0' As Amos mentioned in comment 19, in the qemu-kvm side of this bug only add a useful error prompt. So verified pass in the qemu-kvm side.
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/RHBA-2013-0527.html