Comment 15 for bug 1708572

Reviewed: https://review.openstack.org/530744
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=e2d2c3e8b14a5461c95014be3accb1e40f3d1a0b
Submitter: Zuul
Branch: stable/ocata

commit e2d2c3e8b14a5461c95014be3accb1e40f3d1a0b
Author: Matthew Booth <email address hidden>
Date: Fri Dec 1 16:39:49 2017 +0000

    Fix disk size during live migration with disk over-commit

    Prior to microversion 2.25, the migration api supported a
    'disk_over_commit' parameter, which indicated that we should do disk
    size check on the destination host taking into account disk
    over-commit. Versions since 2.25 no longer have this parameter, but we
    continue to support the older microversion.

    This disk size check was broken when disk over commit was in use on
    the host. In LibvirtDriver._assert_dest_node_has_enough_disk() we
    correctly calculate the required space using allocated disk size
    rather than virtual disk size when doing an over-committed check.
    However, we were checking against 'disk_available_least' as reported
    by the destination host. This value is: the amount of disk space which
    the host would have if all instances fully allocated their storage. On
    an over-committed host it will therefore be negative, despite there
    actually being space on the destination host.

    The check we actually want to do for disk over commit is: does the
    target host have enough free space to take the allocated size of this
    instance's disks? We leave checking over-allocation ratios to the
    scheduler. Note that if we use disk_available_least here and the
    destination host is over-allocated, this will always fail because free
    space will be negative, even though we're explicitly ok with that.

    Using disk_available_least would make sense for the non-overcommit
    case, where the test would be: would the target host have enough free
    space for this instance if the instance fully allocated all its
    storage, and everything else on the target also fully allocated its
    storage? As noted, we no longer actually run that test, though.

    We fix the issue for legacy microversions by fixing the destination
    host's reported disk space according to the given disk_over_commit
    parameter.

    Change-Id: I8a705114d47384fcd00955d4a4f204072fed57c2
    Resolves-bug: #1708572
    (cherry picked from commit e097c001c8e11110efe8879da57264fcb7bdfdf2)