[Openstack-operators] [openstack-dev] [nova] How to move on from live_migration_uri?
sfinucan at redhat.com
sfinucan at redhat.com
Wed Jun 7 16:49:28 UTC 2017
On Wed, 2017-06-07 at 10:20 -0500, Matt Riedemann wrote:
> The [libvirt]/live_migration_uri config option was deprecated in Ocata
> [1] in favor of two other config options:
>
> live_migration_scheme: defaults to tcp (could be ssh), only used for
> kvm/qemu virt types
>
> live_migration_inbound_addr: defaults to None, only used if doing a
> non-tunneled live migration
>
> Those are used here:
>
> https://github.com/openstack/nova/blob/7815108d4892525b0047c787cbd2fe2f26c204c2/nova/virt/libvirt/
> driver.py#L652
>
> If you leave a %s in the URI, the libvirt driver will replace that with
> the destination target host.
>
> Devstack is configuring the live_migration_uri option and setting it to
> "qemu+ssh://stack@%s/system" in our CI jobs. That %s gets replaced with
> the target destination host IP as noted above.
>
> Since live_migration_uri is deprecated, I tried to update devstack to
> use the new options that replace it [2], but then I ran into some
> problems [3].
>
> What I'm trying to do is continue to use ssh as the scheme since that's
> what devstack sets up. So I set live_migration_scheme=ssh.
>
> Within the libvirt driver, it starts with a URL like this for qemu:
>
> qemu+%s://%s/system
>
> And does a string replace on that URL with (scheme, destination), which
> would give us:
>
> qemu+ssh://<dest>/system
>
> The problem lies in the dest part. Devstack is trying to specify the
> username for the ssh URI, so it wants "stack@%s" for the dest part. I
> tried setting live_migration_inbound_addr="stack@%s" but that doesn't
> work because the driver doesn't replace the dest on top of that again,
> so we just end up with this:
>
> qemu+ssh://stack@%s/system
>
> Is there some other way to be doing this? We could try to use tunneling
> but the config option help text for live_migration_tunnelled makes that
> sound scary, e.g. "Enable this option will definitely
> impact performance massively." Holy crap Scoobs, let's scram!
>
> Should we check if the scheme is ssh and try a final string replacement
> with the destination host after we've already applied
> (live_migration_scheme, live_migration_inbound_addr)?
>
> Other ideas? Given the bazillion config options related to libvirt live
> migration, this is just a landmine of terrible so I'm interested in what
> people are doing config-wise if they are using ssh.
I _think_ this bug [1] is the same thing, and I've some patches already up to resolve it [2].
Reviews appreciated :)
Stephen
[1] https://bugs.launchpad.net/nova/+bug/1671288
[2] https://review.openstack.org/#/c/456571/
> [1] https://review.openstack.org/#/c/410817/
> [2] https://review.openstack.org/#/c/471011/
> [3]
> http://logs.openstack.org/19/471019/1/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xeni
> al/546935b/logs/screen-n-cpu.txt.gz?level=TRACE#_Jun_05_15_56_42_184587
>
More information about the OpenStack-operators
mailing list