Re: [Openstack-operators] [openstack-dev] [nova] How to move on from live_migration_uri?

[sfinucan]

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:///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
> 


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Anyone using libvirt driver port filtering with neutron?

[sfinucan]

On Thu, 2017-03-23 at 12:39 -0400, Mathieu Gagné wrote:
> On Thu, Mar 23, 2017 at 10:08 AM,   wrote:
> > The nova libvirt driver provides support for ebtables-based port
> > filtering (using libvirt's nwfilter) to prevent things like MAC, IP
> > and/or ARP spoofing. I've been looking into deprecating this as
> > part of
> > the move to deprecate all things nova-network'y, but it appears
> > that,
> > in some scenarios, it is possible to use this feature with neutron.
> 
> Isn't ARP spoofing support now part of Neutron, at least for
> Linuxbridge mechanism?
> https://review.openstack.org/#/c/196986/

Correct. In most cases, you'd have to explicitly disable the neutron
variant if you wanted the nova one. It was suggested to me that not
every neutron driver implements this feature and for these cases the
nova one would be beneficial. However, from my understanding of the
nova code, this feature only works with iptables- or OVS/IVS hybrid
interfaces, which _do_ support this feature in neutron [1][2], and it
would have to be an explicit action by the operator.

> We do use the feature you mentioned but there is too much hack or
> code
> change you need to do to benefit from it.
> Especially in our case as you can't use both Neutron network manager
> (with security groups, allowed address pairs, etc.) and Nova iptables
> driver to benefit from libvirt's nwfilter anti-ARP spoofing.
> 
> We are still running Kilo and will be migrating to Mitaka which has
> the ARP spoofing protection built-in in Neutron. So no, in our case,
> I
> don't see a reason to keep this feature around as you can get the
> same
> with Neutron port-security extension.

OK, good to hear.

Stephen

[1] https://review.openstack.org/#/c/196986/
[2] https://review.openstack.org/#/c/171003/

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators