[rdo-list] Overprovisioning of local disk storage possible?

Thu Mar 9 13:51:50 UTC 2017

> Hello people,
> After setting up an Ocata cloud and spinning up a few instances in it all of them using local storage I noticed I wasn't able to create more than a handfull of instances all thought the cloud had much more capacity.
> After some debugging I noticed the compute node reporting more disk space as used than actual disk space available, which caused an Exception in the nova api service:
> Compute:
> 2017-03-08 14:43:47.209 3386 INFO nova.compute.resource_tracker [req-1486e04b-7548-4b17-b095-b5b08768ba67 - - - - -] Final resource view: name=redacted_hostname phys_ram=12287MB used_ram=6656MB phys_disk=48GB
> used_disk=60GB total_vcpus=4 used_vcpus=3 pci_stats=[]
>
> The underlying issue (more disk space reported than available) seems to not be new, people already asked about it back in '14[1] which is why I didn't create a bugzilla but asking here.
> I assume this is caused by nova counting the virtual disk size of all instances on that host as 'used_disk'. This in turn means it is not possible to overprovision local storage. Is there a configuration setting or a workaround for this?

“space used” is based on the size of  the disk specified in the instance flavors not what is used on-disk.
e.g. when you spawn 10 instances with a flavor with 50GB of local storage the hypervisor will assume 500GB of space is needed.
If you use “thin-provisioing” of the and only 10GB is actually on disk it will still calculate with 500GB because those instances might grow to 500GB in total.
This is based on the assumption that you do not want to see “can’t write, disk full” messages on all your instances ;)

If you think you can get away with overprovisioning by assuming that not all instances will use the full disk space or e.g. use zfs compression you can set the overprovision facter.
Overprovision of disk is managed by “disk_allocation_ratio”.
You can set this either in nova.conf or in an aggregate.
Basically, works the same as memory/cpu overcommit.

Cheers,
Robert van Leeuwen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20170309/ef1d5302/attachment.html>