# Revision history [back]

THANKS SO MUCH! Just hearing a voice in the wilderness gave me hope :)

So, none of those were the answer -- and sadly - as is the case with ALL of the "no valid host" posts ... each one is seemingly unique.

BUT! WANDERING SUFFERERS READ BELOW FOR TROUBLESHOOTING TIPS!

What was the case for me is that I'm using some older 2950s ... which probably DO have hardware acceleration (they passed the egrep -c '(vmx|svm)' /proc/cpuinfo test...) but my guess is that there's a BIOS twiddle on these older boxes that is not set correctly - so even though it reports "vmx or svm" are present -- they aren't "active" in some way.

But once jdiaz let me know that I'm not alone in a wasteland of CPU pain ... I took a look and found that ... (I checked /var/log/nova-conductor.log on the controller and found could not find capabilities for domaintype=kvm ... which was a new string, searching on THAT lead me to the MOST VALUABLE COMMAND virt-host-validate, which lists all the success/fails for the virtualization host. From there, I foudn that /dev/kvm was failing ... so I set nova-compute.conf to use qemu (in the [libvirt] section on compute1).

Anyway -- props to jdiaz for just being supportive. But like I promised, since I'm a veteran who just lived through this, I'm gonna write a LOT of troubleshooting steps you can take to try and fix this VERY ambiguous error message ... I can't guarantee these will work, but if you are diligent and poke around - you'll potentially find what you need.

STEPS TO TAKE WHEN YOU GET THE NO VALID HOST ERROR MESSAGE

1. Don't panic, it's in there - if dashboard is up and running in a sane way, you're not nuts

2. Understand the difference between what the controller needs and what the compute machine needs. If you've gotten the dreaded message on the dashboard, that means that the controller is complaining. But odds are good that it's complaining about the compute node.

3. There are three main areas where the compute node can let you down: A - the HARDWARE is not compatible B - the IMAGE FORMAT is not compatible C - the environment is not compatible
4. Go to the compute node and run virt-host-validate -- do it, do it NOW! This will tell you if your hardware is compatible for things like hardware acceleration (that's what got me), whether various extended services are running, and so forth. This powerful command will let you know whether the MACHINE, the METAL, is doing it's job.
5. If that doesn't spawn a solution, go to your image, and your image "spawning" command (openstack image create "[imagename]" --file [image file] --disk-format [qcow2, e.g] --container-format bare --public) and confirm that it has the right disk-format (apropos of what jdiaz said above)
6. If THAT doesn't work - it's quite possible that you aren't allocating enough disk, ram or other environment details to allow the VM to start. (For example, if you are trying to run openstack on a VM, did you make sure that the "host" VM is big enough to spawn baby VMs?) ... on the dashboard, you CAN log in with admin and check the available resources of the hypervisor ... does it have enough RAM, VCPU, DISK, etc? If not, you're gonna have to figure out how to give it more.
7. Like jdiaz said - run nova service-list on the controller ... you should see at least ONE service (nova) running on the compute node ... if you don't see ANY services running on the compute node - it isn't talking to the controller -- find out why -- maybe it's something as simple as the ACTUAL (normal) network IP setup ... maybe you firewalled them, who knows ... don't always think it's "openstack magic" -- it could be something "simple" too

## IF ALL ELSE FAILS

These next two steps are cumbersome because they involve MANY files -- only flag the ones that matter to you

8. Do all of this as admin ( . ~/admin-openrc) and as root (sudo -i)

9. On controller: in /var/log/nova, /var/log/keystone and /var/log/neutron, edit nova-api.log, nova-conductor.log, nova-consoleauth.log, nova-manage.log, nova-scheduler.log, keystone-manage.log, keystone-wsgi-admin.log, neutron-server.log, l3-agent.log, dhcp-agent.log, neutron-linuxbridge-agent.log so that the LAST LINE has a flag in it ... this will help you see when your test is starting. You can do this by typing \$ echo 'xxxxxxxxxxxxyournamexxxxxxxxx' >> /var/log/[directory]/filename for each file you want to flag ... it's ugly, but it puts a tag in so you know WHERE in the log file you started searching.
10. On compute: in /var/log/nova and /var/log/neutron ... flag the similar files there.
11. Create another instance - just like that - one you know won't work. Do it! It'll be ok.
12. For every file you flagged, copy it to your homedir and/or desktop -- now you have a captured log of everything that happens when your failing VM is created

Now, no joke ... run your fingers through all of those files ... look for unique strings (not the UUIDs, those are useless) and put those strings into google: If you use this answer, post the strings that worked for you here as well as a comment.

Some that worked for me: No valid host was found. There are not enough hosts available. (ok, that didn't -- but it's included as the original monster) could not find capabilities for domaintype=kvm Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization

...AND FINALLY Look ... you may find that you have to go through the online docs and "redo" your install -- makes your blood run cold, right?

Here's a few pointers from a veteran:

• ANY TIME you are going to edit the original config, cp config.file.conf config.file.conf.dist, that makes a "pristine" copy for you to reference and fall back to
• ANY TIME you edit a line in your config, if you are changing it - copy it, comment out the original, and put a comment of your username, the date, and why you changed it:

For example:

If I want to change

foo=bar


I make it into

#mgmead mitaka 052816 - http://url-that-made-me-do-it.com/stepwhatever.html
#foo=bar
foo=changed

• as you go over your online install, use history | grep [command string] to find whether you did that step and typed it correctly. This will save you LOTS of pain from accidentally running the same command twice (ugh, let me tell you a story about creating nova service entries in the database twice
• Do yourself and everyone else a favor. Download mysql-workbench (https://www.mysql.com/products/workbench/) and actually watch what the server is doing to the various databases ... it helps a TON for understanding how the services talk to each other.

Ok -- I'm done. I hope this helps ... if ONE person bumps into this makeshift foxhole guide and gets joy from it, it will be worth it to me. If not, hats off to you jdiaz - you're my hero! You gave me water when I was thirsty :)