Open Stack

any `WARNING`s or `ERROR`s in the compute log?

does `nova host-list` tell you on which nodes the compute services are running?

gl, hf!

azq



At 2014-01-09 23:06:04,"Danny Roberts" <danny.roberts at reconnix.com> wrote:


I am running OpenStack Havana on CentOS 6.5 using 1 controller node and 6 compute nodes.

 

They are set up with shared storage for Glance, Nova & Cinder as well as shared Nova Networking (no Neutron in our environment).

 

When trying to boot an instance it goes into Building status for a few seconds before going into Error status.

 

Tailing the nova scheduler log shows this error each time:

 

2014-01-09 14:40:06.304 2239 WARNING nova.scheduler.utils [req-3f21465f-7ec6-4ea0-9a08-c3a7dcd3faff 5fc621f9f24941febb883f78d2d350ec c22af115b6a84dc78b1ae19385c6cd23] Failed to scheduler_run_instance: No valid host was found. Exceeded max scheduling attempts 3 for instance d1ff048b-6ddd-4589-b188-7606a047df23

2014-01-09 14:40:06.305 2239 WARNING nova.scheduler.utils [req-3f21465f-7ec6-4ea0-9a08-c3a7dcd3faff 5fc621f9f24941febb883f78d2d350ec c22af115b6a84dc78b1ae19385c6cd23] [instance: d1ff048b-6ddd-4589-b188-7606a047df23] Setting instance to ERROR state.

 

As I understand the "No valid host" error indicates that the scheduler could not find a compute host with the resources required in order to schedule the instance on any of the available hosts. However none of the hosts are running anything currently and have decent specs. Also it's only a tiny instance so doesn't require much anyway.

 

I tried setting 'scheduler_default_filters=AllHostsFilter' in '/etc/nova/nova.conf'� as how I read it in the Developers docs and on various forums this should mean that the scheduler does not checks for resources and just schedules the build on a connected host. However even with this option set the 'nova boot' still goes into Error status and gives the error shown in the above log snippet.

 

I have tried multiple images in case the image is at fault but none will launch (even the one we have in use in another OpenStack environment) so don't believe that it is that. I also updated all our boxes yesterday to the latest package versions and this hasn't changed anything.

 

Any ideas why this error might still be occurring or any advise on how we could debug the situation further?

 

Regards,

--

Danny Roberts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140110/148bc71e/attachment.html>