On 8/2/2019 3:53 AM, Budai Laszlo wrote:
1. configure Nova to use local LVM storage (images_types = lvm) - provided the best performance, but we could not migrate our instances (seems to be a bug).
Yes it's a known bug: https://bugs.launchpad.net/nova/+bug/1831657 As noted within that bug report, WindRiver had a patch at one point to make that work but it's long out of date, someone would have to polish it off and get it working again. The good news is we have a nova-lvm CI job which is currently skipping resize tests but in the patch that implements migrate for lvm we could unskip those tests and make sure everything is working in that nova-lvm CI job. We just need contributors that care about it to do the work (there seem to be several people that want this, but a dearth of people actually making it happen).
2. use cinder with lvm backend and instance locality, we could migrate the instances, but the performance is less than half of the previous case
I could dredge up the ML thread on this but while this is an option, (or even using the now-either-deprecated-or-deleted cinder local block volume type driver), it could quickly become a management nightmare since enforcing compute/volume locality with availability zones becomes a mess at scale. If you only have a half dozen computes or something then maybe that's not a problem in a private cloud shop, but it's definitely a problem at larger scale, and also complicated if you set the [cinder]cross_az_attach=False value in nova.conf because of known bugs [1] with that. [1] https://bugs.launchpad.net/nova/+bug/1694844 - yes I'm a bad person for not having cleaned up that patch yet but I haven't felt much urgency either. -- Thanks, Matt