The scheduler should be able to schedule VMs that have memory backed by memory - such VMs do not consume regular memory pages we normally consider, but rather hugepages from previously allocated pool.

Specification of hugepages feature:
- hugepage cannot be split: VM with 800 MB ram and hugepage size of 1048576 will consume exactly one hugepage
- only the memory backing of the guest is stored on hugepages; QEMU overhead resides in regular memory
- host reports available hugepages for VM scheduling in it's stats
```
    ...
    "hugepages": {
        "1048576": {
            "resv_hugepages": 0,
            "free_hugepages": 16,
            "nr_overcommit_hugepages": 0,
            "surplus_hugepages": 0,
            "vm.free_hugepages": 16, # <--- the amount of hugepages that we may use for VMs (with hugepage size of 1048576)
            "nr_hugepages": 16,
            "nr_hugepages_mempolicy": 16
        },
        "2048": {
            "resv_hugepages": 0,
            "free_hugepages": 0,
            "nr_overcommit_hugepages": 0,
            "surplus_hugepages": 0,
            "vm.free_hugepages": 0, # <--- the amount of hugepages that we may use for VMs (with hugepage size of 2048)
            "nr_hugepages": 0,
            "nr_hugepages_mempolicy": 0
        }
    },
    "dateTime": "2017-06-14T13:02:53 GMT",
    ...
```
- - scheduler *must* use the highlighted field as certain number of system free hugepages may be reserved for something else (e.g. DPDK)
- host reports available hugepages sizes in capabilities
```
    ...
    "hostedEngineDeployed": false,
    "hugepages": [
        1048576,
        2048
    ],
    "kvmEnabled": "true",
    ...
```
- allocating hugepages reduces available system memory by number of hugepages times hugepages size (even if the hugepages are unused)
- - in other words, each hugepage size can be treated as separate memory pool
- - example: if the host has 64 GiB RAM and 14 1048576 hugepages, it's free memory follows 0 <= free memory <= (64 - 14) GiB
- - the hugepages will be allocated at the boot time
- as far as scheduler is concerned, the hugepages cannot be dynamically (de)allocated
- migration for VMs with hugepages is disabled
- memory hot(unplug) is disabled
- no overcommit
- quota support (maximum number of hugepages consumed by user)
- no special permissions required
- not numa aware at the moment