Description of problem:


Below are the queries from Cu configuring Instance Migration and Resize, and also the required data that we have from the internal discussion on the case:


1) Is it required to execute the steps described in "1.2.1. Configure Secure Libvirt" in document [1] in a Director based deployment after applying the updates from CVE-2017-2637 [2]?

--> No, it is not required, unless you want to use TLS instead of SSH. We use SSH with OSP-d for this and the director configures the nova ssh keys using the information in /etc/nova/migration

However, in our support document, there is still the step that states to perform the steps.



2) Is it required to execute the steps described in "1.2.3. Configure Block Migration" in document [3] in a Director based deployment as block migration seams to work out of the box?

--> no see above, also from 
`https://docs.openstack.org/releasenotes/nova/newton.html`

~~~
The ‘live_migration_flag’ and ‘block_migration_flag’ options in libvirt section that were deprecated in Mitaka have been completely removed in Newton, because nova automatically sets correct migration flags. New config options has been added to retain possibility to turn tunnelling, auto-converge and post-copy on/off, respectively named live_migration_tunnelled, live_migration_permit_auto_converge and live_migration_permit_post_copy.
~~~


3) Is it recommended to set 'allow_migrate_to_same_host=True' as described in "2.3.1. Configure SSH Tunneling between Nodes" [4]?

--> Not found the deprecated message, but that option seems to be gone in OSP10

# grep -R allow_migrate_to_same_host /usr/lib/python2.7/site-packages/nova

We need to confirm this step in 2.3.1


4) Are the steps described in "2.3.1. Configure SSH Tunneling between Nodes" [4] still required after installing openstack-tripleo-heat-templates-5.2.0-12 and deploying the overcloud as described in [5]?

--> No

But, still, we have it mentioned.


5) Is it recommended to set "allow_resize_to_same_host = True" as described in "3.1.4. Resize an Instance" [6]?

--> Yes, but it does not guarantee that the resize will be on the same host. it only does not exclude the local host as a destination for the resize migration.

We should add the note as above in the 3.1.4 section in document


[1]: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/migrating_instances/#configure_secure_libvirt
[2]: https://access.redhat.com/solutions/3022771
[3]: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/migrating_instances/#configure_block_migration
[4]: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/migrating_instances/#configure_ssh_tunneling_between_nodes
[5]: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/director_installation_and_usage/#sect-Migrating_VMs_from_an_Overcloud_Compute_Node
[6]: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/instances_and_images_guide/#section-resize-instance


These are the queries related to migration process:


1) Using the openstack client it does not work. Why is it trying to do a shared storage migration when I try to do a block migration? 

~~~
$ openstack server migrate 34ca4f9f-8ad3-4295-89aa-ae470d5acd7e --live overcloud-compute-1.localdomain --block-migration 
overcloud-compute-0.localdomain is not on shared storage: Live migration can not be used without shared storage except a booted from volume VM which does not have a local disk. (HTTP 400) (Re-quest-ID: req-cc99cd70-8b36-448f-8817-7e1148970e2a)
~~~


2) But why does the following work even when shared-migration is the default?

~~~
$ openstack server migrate 34ca4f9f-8ad3-4295-89aa-ae470d5acd7e --live overcloud-compute-1.localdomain
~~~


(1) and (2) above are related to the bug: https://bugzilla.redhat.com/1424129


3) Why does the following work? I don’t have shared storage. 

~~~
$ nova live-migration 34ca4f9f-8ad3-4295-89aa-ae470d5acd7e overcloud-compute-0.localdoma
~~~

--> The nova client per default use the '"block_migration": "auto"' flag. You could see that if you run the migration with "nova --debug live-migration"

This information is missing in our support document.




Version-Release number of selected component (if applicable):

Red Hat OpenStack 10 Migration doc


Actual results:

Some outdated information in a doc.

Expected results:

Documentation should be updated with the current information.