Created attachment 892300 [details] nova conductor log file output Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. install openstack using the latest RDO build using packstack (1 controller+2 computes) 2. try to live-migrate one instance from one host to another 3. Actual results: operation failed with errors in nova conductor file Expected results: live migration works smoothly Additional info:
Hmmm, not sure that this the best use of resources. There are a lot of other things that need resources too. Please provide data that shows that this is needed *and* that it will have little impact on everything else that runs there.
Mark, I was showing the log to the RH nova guys and they have pointed me to this issue. indeed, when I increased the # of workers, I got pass the issues I have seen in the conductor. Not sure what would be the affect of increasing the # of workers on other services though.
(In reply to Mark Wagner from comment #1) > Hmmm, not sure that this the best use of resources. There are a lot of > other things that need resources too. Please provide data that shows that > this is needed *and* that it will have little impact on everything else that > runs there. If, as posited, it's breaking live migration in basic environments then we need to fix it.
Dan, I am using you as a proxy for the "RH nova guys" mentioned in #2. Is setting conductor.workers as requested in this bz a recommended configuration? For the record, if this was at some point causing problems with live migrations, it no longer appears to do so. I am able to perform successful live migrations in a simple packstack-deployed multi-node environment without problems.
Yes. Leaving it unset should set it to the number of cores automatically, AFAIK. In general, the number of conductor workers needed depends on the deployment and the characteristics of the load (lots of instance create/destroy traffic, etc). So, setting it to the number of cores on an all-in-one is definitely a good idea. It's possible that it could be less if you have lots of machines running conductor in your deployment. You really need a lot of parallelism in your conductors because that is how (multiple pieces of) nova avoid blocking on the database. In general, if I had to choose a default, I would set it to at least the number of cores on each box, yes.
Thanks. Okay, since we are leaving this value unset in packstack, we're getting the default behavior which is number of workers == number of cpu cores, which is pretty much the original request in this bz.