doc: add another up-call caveat for cells v2 for xenapi aggregates

There is an up-call from the xenapi driver when performing a live
migration and --block-migrate is not specified such that the driver
checks to see if the source and destination hosts are in the same
aggregate. This fails in a super-conductor setup because the
aggregates are now in the API database and the cell conductor
won't be able to access that database by design.

Change-Id: I6c880c72d87eb0116cb57371e5d600dced2915f7
Related-Bug: #1709594
changes/06/493006/1
Matt Riedemann 5 years ago
parent 4cd6a3a1b4
commit 904c4a1d9a
  1. 14
      doc/source/user/cellsv2_layout.rst

@ -316,9 +316,10 @@ implement some features without such connectivity. Thus, anything that
requires a so-called "upcall" will not function. This impacts the
following:
- Instance reschedules during boot
- Instance affinity reporting from the compute nodes to scheduler
- The late anti-affinity check
#. Instance reschedules during boot
#. Instance affinity reporting from the compute nodes to scheduler
#. The late anti-affinity check
#. Querying host aggregates from the cell
The first is simple: if you boot an instance, it gets scheduled to a
compute node, fails, it would normally be re-scheduled to another
@ -336,3 +337,10 @@ affect you. To make sure you don't make futile attempts at the
affinity check, you should set
``[workarounds]/disable_group_policy_check_upcall=True`` and
``[filter_scheduler]/track_instance_changes=False`` in ``nova.conf``.
The fourth is currently only a problem when performing live migrations
using the XenAPI driver and not specifying ``--block-migrate``. The
driver will attempt to figure out if block migration should be performed
based on source and destination hosts being in the same aggregate. Since
aggregates data has migrated to the API database, the cell conductor will
not be able to access the aggregate information and will fail.

Loading…
Cancel
Save