10 a.m.
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
8:36 a.m.
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
2:36 p.m.
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
2:41 p.m.
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
5360
days inactive
5361
days old
3 comments
3 participants
participants (3)
-
Chris Lalancette -
Cole Robinson -
Kenneth Nagin