live migration fails when use long hostname of a nova compute target host

[Michael Kazakov]

Nova don't do live-migration when used long hostname of target host

nova show ubuntu14.04
+--------------------------------------+-----------------------------------------------------------+
| Property | Value |
+--------------------------------------+-----------------------------------------------------------+
..................................................................................................................................
| OS-EXT-SRV-ATTR:host | compute2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | compute2.site.local |
..................................................................................................................................

nova live-migration ubuntu14.04 compute2.site.local
ERROR (BadRequest): Compute service of compute2.site.local is unavailable at this time. (HTTP 400) (Request-ID: req-f344c0bf-aaa3-47e6-a24c-8f37e89858e4)

but
nova live-migration ubuntu14.04 compute2
runs without error

Also if you try to do migration through horizon it always fails because horizon use long hostname fo target host.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/101096

[jiang, yunhong (yunhong-jiang)]

I'd think we should change the horizon to use host, instead of long hostname, or, if we really want to support target at specific one specific compute node, specify host/hypervisor_hostname?

--jyh

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Julie Pichon (jpichon)]

There's a Horizon patch up for changing the host name horizon is using (see bug 1335999 / https://review.openstack.org/#/c/103672/ ) though it's unclear to me if this will help with resolving this as well?

[melanie witt (melwitt)]

@Julie Thanks for linking the Horizon bug and review. That one will solve the problem of live migrate not working at all through Horizon, and it's anyway preferred to provide service host name. It won't however change the fact that we can't use hypervisor_hostname as a migration target argument. In the review of my patch, Yunhong pointed out that there isn't a unique constraint on hypervisor_hostname the way there is on service host name. But, in my patch I re-raise if more than one host is returned when I filter on hypervisor_hostname, so I think it should be okay i.e. it's better than nothing, at least we try.

@Yunhong What do you think? I was thinking also instead of re-raising I could raise something like "multiple targets found, use service host name."

[marvel (marvelliu)]

Yes, I met this problem, horizon give me nodes like "node1.expr", while the database has only "node1", causing live migration failure, a little fix is listed below:

 50 def populate_host_choices(self, request, initial):
 51 hosts = initial.get('hosts')
 52 current_host = initial.get('current_host')
 53 +host_list = [(host.service['host'],
 54 + host.service['host'])
 55 + for host in hosts
 56 + if host.service['host'] != current_host]
 57 -host_list = [(host.hypervisor_hostname,
 58 - host.hypervisor_hostname)
 59 - for host in hosts
 60 - if host.service['host'] != current_host]
 61 if host_list:
 62 host_list.insert(0, ("", _("Select a new host")))

[melanie witt (melwitt)]

This isn't really a bug, changing to Wishlist.

[melanie witt (melwitt)]

Removing horizon as it has its own bug and patch up for this bug 1335999

[melanie witt (melwitt)]

I lack permission to remove horizon (Ubuntu), so moving back to New.

[OpenStack Infra (hudson-openstack)]

Change abandoned by melanie witt (<email address hidden>) on branch: master
Review: https://review.openstack.org/101096

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Adam Spiers (adam.spiers)]

Hi Melanie, just wondering why this change was abandoned? Unless I misunderstood, it seemed that the only objections to Patch Set 4 were regarding implementation details, not against the approach. Your way of guarding against accidentally using the wrong non-unique hypervisor host seems good to me, but maybe I'm missing something? Thanks!

[Maciej Szankin (mszankin)]

First thing - title is confusing. Problem is not in hostname length that is provided as target in live-migration command. Maximum hostname length is 64, and verified, it works.

Second thing - providing FQDN (which usually is used for hypervisor hostname) in live migration does not work by design. I am not sure if anyone is interested in being able to give FQDNs instead of hostnames as targets of LM.

Despite above:
There was a small possibility that by changing rabbit host in nova.conf from IP to FQDN this would be fixed, but verified it, didn't work.

I think that item is invalid, but someone has to agree with me.