I was trying to set up a simple hypervisor that would automatically suspend and resume a VM if the host was gracefully power cycled.
It was very easy to set up, all I needed to do was enable the ‘libvirt-guests’ service. Without changing any options, each VM would be put basically into hibernation when the host was rebooted or shut off. During the next boot, each VM would be resumed one at a time.
This was working just with my single ethernet interface, however when I set up a bridge to use instead I discovered the VM would not boot due to a VNC issue. The three messages below show that not only does this happen with the VNC and Spice servers, it also happens independent of libvirt-guests. The VM just will not start on host boot at all, whether it was autostarted or resumed via libvirt-guests.
Mar 29 01:16:54 blackbox libvirt-guests.sh: 2019-03-29T05:16:54.364291Z qemu-kvm: Failed to start VNC server on `127.0.0.1:0': address resolution failed for 127.0.0.1:5900: Address family for hostname not supported
Mar 29 01:22:22 blackbox libvirtd: 2019-03-29T05:22:21.905687Z qemu-kvm: Failed to start VNC server on `127.0.0.1:0': address resolution failed for 127.0.0.1:5900: Address family for hostname not supported
Mar 29 01:30:08 blackbox libvirt-guests.sh: (process:4988): Spice-WARNING **: 01:30:07.902: reds.c:2618:reds_init_socket: getaddrinfo(127.0.0.1,5900): Address family for hostname not supported
I’m usually pretty good and combing the internet for bug reports or other posts that are similar, then if one looks good I’ll just scroll to the bottom and work my way backwards. If there is no official solution, sometimes one is presented in the bug comments. This one was proving troublesome.
The workaround/solution came from this article: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1492621
Specifically calling out this bug as the probable cause: https://bugzilla.redhat.com/show_bug.cgi?id=721350
The solution was to set
::1 as the listen address. This is the ipv6 version of
127.0.0.1 in the display settings for the VM.
Clearly this is still an ongoing issue since I just hit it, and the comments for the Red Hat bug range from 2011 – 2018. It is important to note that this issue really isn’t with KVM, or VNC – its glibc. I’m sure this issue manifests itself in other equally confusing problems. I still don’t understand why this problem only happens after using a bridge interface for my main network. Perhaps a race condition between the network still coming up on the bridge adapter and the VM attempting to start.