Openstack nova live migration pain

Thomas Goirand zigo at
Sat Sep 11 13:49:21 UTC 2021

On 9/10/21 11:19 PM, hai wu wrote:
> I am new to the current environment. I just asked around, and you are
> correct: we had to use a mix of both buster-train-backports and
> buster, because some of the packages were breaking systems scripts,
> also there was one python-nova that caused the rabbitmq to get into an
> endless loop...


Could you be more precise please? What package is breaking what system
scripts? I never heard of something like this... I never heard about
what you wrote on "python-nova that caused the rabbitmq to get into an
endless loop" either.

We've been running Nova from the Train release for quite some time now,
and we never experienced this.

Also, we did have the issue you described with Nova from Rocky, but it
went away after upgrading to Train.

> Is it possible to just upgrade this package to some later package from
> Train, which does not have this bug, in order to work around this
> particular buggy state? we could do some tests here, we do have a test
> system, which is built the same way, and it is suffering from the
> exact same live migration issue ..

Yes you can upgrade, but not directly from Rocky to Train, you must
update your control plane to Stein first, do the db-sync (ie: upgrade
your db schema), then upgrade to Train and re-do the db-sync again.

In fact, we did this in production. While it took 6 hours, it worked
well, without a single issue.

BTW, it's nice that we get in touch, though I regret you didn't do it
earlier about the other issues you described. We (the Debian OpenStack
package maintainers) don't bite and are happy to help! :)


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list