instances being migrated are not accounting for disk_available_least

[Nikola Đipanov]

Looking briefly at the code of other drivers that try to report this (xenapi and ironic) - it is also likely broken for at least xenapi.

The crux of the issue is that resource tracker works by looking at the instances Nova knows about, and also the ongoing migration, so anything that is reported by any of the virt drivers as part of the dictionary returned from get_available_resource should only be based on the available resources and should never try to factor in any resource usage. Only the resource tracker holding the global resource lock (COMPUTE_RESOURCE_SEMAPHORE) knows the current usage of resources since it can take into account migrations that are in flight etc.

Unfortunately, both libvirt and xenapi (I think) try to look at the instance currently know by the hypervisor, which is not all instances we should be taking into account, and deduce the final disk_available_least number.

To fix this we would have to rework how disk_available least is calculated - we'd have to make sure the drivers only report the total available space, and then make sure we update the usage _for each instance and migration_ to come up with the final number.

[Bob Ball (bob-ball)]

I believe this should work already for XenAPI? we get the physical utilisation from the SR, not counting up from instances. VDIs will be created for disks that are being live migrated at the start of the live migration.

https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/xenapi/driver.py#n448
https://git.openstack.org/cgit/openstack/nova/tree/nova/virt/xenapi/host.py#n243

Was the issue identifed by inspection or is there a failure case that has been seen?

[Bob Ball (bob-ball)]

Awesome - so re-reading I can see it was identified by inspection... Sorry for being blind. I don't think XenAPI is affected by this.

[Mohammed Ashraf (mohammed-asharaf)]

Hi,

I am new to Openstack .

I just started taking a look at this defect. I understand from the comment above that it's was raised upon code inspection
and there's a clarification that it's not applicable to xenapi.

So is this now valid only for libvirt driver and is this defect reproducible for libvirt driver? Any one able to reproduce it?

Please let me know.

Thanks
Ashraf

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/293272

[OpenStack Infra (hudson-openstack)]

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/293272
Reason: Per discussion at the summit (https://etherpad.openstack.org/p/ocata-nova-summit-meetup), we are abandoning Newton specs that haven't merged. You may restore this patch and move it to Ocata if you'd like.

[Jay Pipes (jaypipes)]

Unassigning. This is a real bug, yes. The issue Chris Friesen raised on the related patch (since abandoned) around accounting for the QCOW2 backing file should be tracked as a separate bug.

This bug is relatively straight-forward, as is the fix: ensure we track migrating instances for disk_available_least calculations.

The actual patch may be complicated, however, due to various side-effects and virt-driver-specific implementation details.