[nova] NUMA live migration - mostly how it's tested

Artom Lifshitz alifshit at redhat.com
Fri Mar 1 16:18:52 UTC 2019


On Fri, Mar 1, 2019 at 11:00 AM Matt Riedemann <mriedemos at gmail.com> wrote:
>
> On 3/1/2019 9:44 AM, Artom Lifshitz wrote:
> > Applying the same strategy to functional tests isn't straightforward
> > because the CONF object is very very global, and we can't have
> > different config values for different services in the same test. One
> > basic functional test we could have is just asserting that the live
> > migration is refused if both hosts are "full" with instances -
> > something that currently works just fine, except for resulting in
> > overlapping pin mappings.
>
> Can you run the different compute services with different fakelibvirt
> connections which report different pins? Seems Stephen and gibi have
> done some wizardry like that in the libvirt functional tests.

So something like [1], excepting setting side_effect=<list of
fake_connection> instead of the return value? I think that's doable.
Question is, does it allow us to do what we want - namely, create
situations where we can live migrate but expect the pin mappings to be
updated? We'd have to bypass fakelibvirt's NUMATopology helper and
create the LibvirtConfig classes directly, but we could set it up to
have something like this:

Host A:
  NUMA node 0: 4 CPUs
  NUMA node 1: 2 CPUs

Host B:
  NUMA node 0: 4 CPUs

Create an instance with 4 CPUs and 1 NUMA node and live migrate it.
Regardless of if it starts on A or B, we expect it's cell pins to be
updated.

Thanks for being my rubber duck Matt! /me goes off to try that.

[1] https://github.com/openstack/nova/blob/a90c8e1a359a236e06f3a78df74f55808bbef31b/nova/tests/functional/libvirt/test_numa_servers.py#L101
>
> --
>
> Thanks,
>
> Matt
>


-- 
--
Artom Lifshitz
Software Engineer, OpenStack Compute DFG



More information about the openstack-discuss mailing list