Change [1] added new fields 'src|dst_supports_numa_live_migration'
to LibvirtLiveMigrateData object, but missed if condition for
dst_supports_numa_live_migration field in obj_make_compatible
method.

This change adds the if condition as well as fix typo in unit test
because of which this wasn't catched earlier.

Closes-Bug: #1975891
Change-Id: Ice5a2c7aca77f47ea6328a10d835854d9aff408e
(cherry picked from commit 3aa77a3999a7dcabbd4c0141d4c56b07a4624128)
(cherry picked from commit dfa05d62da441eeaf144e312cf33ba0e029452f0)
(cherry picked from commit 7c4059669c079787e5dbdc873a1cf767a95b2c54)

When the InstanceNUMATopology OVO has changed in
I901fbd7df00e45196395ff4c69e7b8aa3359edf6 to separately track
pcpus from vcpus a data migration was added. This data migration is
triggered when the InstanceNUMATopology object is loaded from the
instance_extra table. However that patch is missed the fact that the
InstanceNUMATopology object can be loaded from the request_spec table as
well. So InstanceNUMATopology object in RequestSpec are not migrated.
This could lead to errors in the scheduler when such RequestSpec object
is used for scheduling (e.g. during a migration of a pre Victoria
instance with cpu pinning)

This patch adds the missing data migration.

Change-Id: I812d720555bdf008c83cae3d81541a37bd99e594
Closes-Bug: #1952941
(cherry picked from commit e853bb57181721725a89656b3cb3058636630a6e)
(cherry picked from commit 7f6ec8cf546cf8f437ee94bb2308447427f54ada)

There is a race condition in nova-compute with the ironic virt driver as
nodes get rebalanced. It can lead to compute nodes being removed in the
DB and not repopulated. Ultimately this prevents these nodes from being
scheduled to.

The main race condition involved is in update_available_resources in
the compute manager. When the list of compute nodes is queried, there is
a compute node belonging to the host that it does not expect to be
managing, i.e. it is an orphan. Between that time and deleting the
orphan, the real owner of the compute node takes ownership of it ( in
the resource tracker). However, the node is still deleted as the first
host is unaware of the ownership change.

This change prevents this from occurring by filtering on the host when
deleting a compute node. If another compute host has taken ownership of
a node, it will have updated the host field and this will prevent
deletion from occurring. The first host sees this has happened via the
ComputeHostNotFound exception, and avoids deleting its resource
provider.

Co-Authored-By: melanie witt <melwittt@gmail.com>

Conflicts:
    nova/db/sqlalchemy/api.py

NOTE(melwitt): The conflict is because change
I9f414cf831316b624132d9e06192f1ecbbd3dd78 (db: Copy docs from
'nova.db.*' to 'nova.db.sqlalchemy.*') is not in Wallaby.

NOTE(melwitt): Differences from the cherry picked change from calling
nova.db.api => nova.db.sqlalchemy.api directly are due to the alembic
migration in Xena which looks to have made the nova.db.api interface
obsolete.

Closes-Bug: #1853009
Related-Bug: #1841481

Change-Id: I260c1fded79a85d4899e94df4d9036a1ee437f02
(cherry picked from commit a8492e88783b40f6dc61888fada232f0d00d6acf)

Nova has never supported specifying per numa node
cpu toplogies. Logically the  cpu toplogy of a guest
is independent of its numa toplogy and there is no
way to model different cpu toplogies per numa node
or implement that in hardware.

The presence of the code in nova that allowed the generation
of these invalid configuration has now been removed as it
broke the automatic selection of cpu topologies based
on hw:max_[cpus|sockets|threads] flavor and image properties.

This change removed the incorrect code and related unit
tests with assert nova could generate invalid topologies.

Closes-Bug: #1910466
Change-Id: Ia81a0fdbd950b51dbcc70c65ba492549a224ce2b
(cherry picked from commit 387823b36d091abbaa37efb930fc98b94a5bbb93)

Even if we want to bump the compute rpc api to a new major version, we still
need to support 5.x for the rolling upgrade case.

Adding a proxy that will handle those old RPC calls/casts so we could easily
cut it in a later change in the next X release timeframe (as we won't longer
support Victoria 5.x calls)

On the client side, we're making sure that we can still support v5.x methods
until the next X release (as operators could pin on 5.0 version for Victoria
compute nodes)

NOTE(sbauza): Now that the compute service only supports the 6.0
version, we could remove all the unnecessary verifications in both the
manager but also the functional and unittests. That being said, given
the patch would be large, I think it's better to just amend the needed
modifications for supporting 6.0 and delete the above in later changes.
For example, the NUMA live migration functests verify a lot of RPC API
compatibities in betwen 5.2, 5.3 and later. We need to stop verifying
this but let's do this in later changes, please.

Change-Id: Id2e467c43d5b7c6bafd5dbbbf8d5d06be6dc7e30

This change extend the vnic type to PCI request dev type mapping to
support the vDPA vnic type.

This change extends the PCI stats module to filter out VDPA 'dev_type'
pools if its not explicitly requested.

This change explicitly filters out the vDPA dev_type from the pci alias
schema since that is not supported.

Blueprint: libvirt-vdpa-support
Change-Id: I91dd7993395f693c7d26c1caa44fa365f5cbec12

Add a new PCI device type and update the parent objects to reflect this.
The code for handling the '[pci] alias' config option is updated to
prevent users specifying this in an alias.

Blueprint: libvirt-vdpa-support
Change-Id: I7c779ce7ee0648833758a75164e0bc0b54fe9a71

The USB-based tablet is often the only USB device in an x86 instance,
while the USB-based keyboard is often the only such device in an AArch64
instance (x86 have PS2 keyboards and mice). Replacing these with
virtio-based devices can eliminate the need to have a USB host adapter
in the instance. Enable just that possibility by adding a new value
image metadata property, 'hw_input_bus'. This allows us to specify not
only virtio-based pointer and keyboard input devices but also USB
equivalents.

Note that this also fixes one instance of a particular class of bugs,
whereby we have checks for *guest* architecture-specific behavior that
are being toggled based on the *host* architecture. In this instance,
we were attempting to add a keyboard device on AArch64 guests since they
don't have one by default, but we were determining the architecture by
looking at the CPU architecture reported in the host capabilities. By
replacing this check of the host capabilities with a call to the
'nova.virt.libvirt.utils.get_arch' helper, we correctly handle requests
to create non-host architecture guests via the 'hw_architecture' image
metadata property. There are many other instances of this bug and those
can be resolved separately.

Change-Id: If9f3ede3e8449f9a6c8d1da927974c0a73923d51
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>