[libvirt] error: internal error canonical hostname pointed to localhost, but this is not allowed
When trying to migrate a VM the destination libvirtd virGetHostnameLocalhost throws an internal error. I issue this command from the source host.
virsh migrate rel-vm1 qemu+tls://croton/system error: internal error canonical hostname pointed to localhost, but this is not allowed
The destination host throws the error: 14:14:57.914: debug : virDomainMigratePrepare2:3740 : dconn=0xed17e0, cookie=0x7f983a352d68, cookielen=0x7f983a352d74, uri_in=(null), uri_out=0xe8c360,flags=0, dname=(null), bandwidth=0, dom_xml=<domain type='kvm' id='1'> <name>rel-vm1</name> <uuid>c0c98fc9-8cd6-e246-a06e-b5ce37c4f05e</uuid> <memory>262144</memory> <currentMemory>262144</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc-0.11'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <source file='/share/images/nagin/rel-vm1/rel-vm1.img'/> <target dev='hda' bus='ide'/> <alias name='ide0-0-0'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='ide' index='0'> <alias name='ide0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes'/> <video> <model type='cirrus' vram='9216' heads='1'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> </devices> </domain> 14:14:57.914: error : virGetHostnameLocalhost:2372 : internal error canonical hostname pointed to localhost, but this is not allowed libvir: error : internal error canonical hostname pointed to localhost, but this is not allowed 14:14:57.914: debug : remoteSerializeError:141 : prog=536903814 ver=1 proc=108 type=1 serial=3, msg=internal error canonical hostname pointed to localhost, but this is not allowed The libvirt version is the tip of git: [root@croton rel-vm1]# virsh version Compiled against library: libvir 0.7.7 Using library: libvir 0.7.7 Using API: QEMU 0.7.7 Running hypervisor: QEMU 0.12.1 Changing qemudDomainMigratePrepare2 call to virGetHostnameLocalhost from: if ((hostname = virGetHostnameLocalhost(0)) == NULL) to: if ((hostname = virGetHostnameLocalhost(1)) == NULL) seems to fix the problem. But maybe this is only masking a another problem. --Kenneth Nagin
On 03/23/2010 11:00 AM, Kenneth Nagin wrote:
Changing qemudDomainMigratePrepare2 call to virGetHostnameLocalhost from: if ((hostname = virGetHostnameLocalhost(0)) == NULL) to: if ((hostname = virGetHostnameLocalhost(1)) == NULL) seems to fix the problem. But maybe this is only masking a another problem.
Yeah, you are masking another problem. The problem is that this portion of migration is running on the destination of the migration, and generating a string that the source of the migration will use to perform the migration. By passing the 1 flag to virGetHostnameLocalhost, you are allowing it to return "localhost" as the string. This means that when the source tries to migrate, it will actually try to migrate to "localhost", not the destination, and fail in complicated-to-debug ways. The actual problem you have is that the "hostname" command on your machine is returning a string that resolves to localhost, probably because of a misconfiguration in /etc/hosts. -- Chris Lalancette
On 03/24/2010 09:36 AM, Chris Lalancette wrote:
On 03/23/2010 11:00 AM, Kenneth Nagin wrote:
Changing qemudDomainMigratePrepare2 call to virGetHostnameLocalhost from: if ((hostname = virGetHostnameLocalhost(0)) == NULL) to: if ((hostname = virGetHostnameLocalhost(1)) == NULL) seems to fix the problem. But maybe this is only masking a another problem.
Yeah, you are masking another problem. The problem is that this portion of migration is running on the destination of the migration, and generating a string that the source of the migration will use to perform the migration. By passing the 1 flag to virGetHostnameLocalhost, you are allowing it to return "localhost" as the string. This means that when the source tries to migrate, it will actually try to migrate to "localhost", not the destination, and fail in complicated-to-debug ways.
The actual problem you have is that the "hostname" command on your machine is returning a string that resolves to localhost, probably because of a misconfiguration in /etc/hosts.
In this case, the destination is a host that the user already has a valid remote libvirt URI for: maybe if 'hostname' doesn't work, we can fallback to use the hostname portion of the remote URI? I can have a static mapping in my local /etc/hosts for some remote machine without 'hostname' output. - Cole
On 03/24/2010 03:36 PM, Cole Robinson wrote:
On 03/24/2010 09:36 AM, Chris Lalancette wrote:
On 03/23/2010 11:00 AM, Kenneth Nagin wrote:
Changing qemudDomainMigratePrepare2 call to virGetHostnameLocalhost from: if ((hostname = virGetHostnameLocalhost(0)) == NULL) to: if ((hostname = virGetHostnameLocalhost(1)) == NULL) seems to fix the problem. But maybe this is only masking a another problem.
Yeah, you are masking another problem. The problem is that this portion of migration is running on the destination of the migration, and generating a string that the source of the migration will use to perform the migration. By passing the 1 flag to virGetHostnameLocalhost, you are allowing it to return "localhost" as the string. This means that when the source tries to migrate, it will actually try to migrate to "localhost", not the destination, and fail in complicated-to-debug ways.
The actual problem you have is that the "hostname" command on your machine is returning a string that resolves to localhost, probably because of a misconfiguration in /etc/hosts.
In this case, the destination is a host that the user already has a valid remote libvirt URI for: maybe if 'hostname' doesn't work, we can fallback to use the hostname portion of the remote URI? I can have a static mapping in my local /etc/hosts for some remote machine without 'hostname' output.
Yeah, that's a pretty good idea. We still need to make sure that we don't eventually resolve to "localhost", but at least your suggestion would fix the situation you describe above. -- Chris Lalancette
participants (3)
-
Chris Lalancette -
Cole Robinson -
Kenneth Nagin