Expandable Reservation on resource pools

Going through the Scott Lowe book atm, there's this check box on a resource pool's settings for Expandable Reservation. Scott says leaving this check box marked doesnt let the resource pool borrow more than the reservation set on it and it only borrows to satisfy the reservation, not borrow more than the reservation. They why even have the check box at all? The resource pool is going to get whatever is specified in the reservation anyway.

Jumped on vmware.com and read some paper on DRS, which says that leaving this check box marked enables a resource pool to borrow more than its reservation. This makes sense, but how much more can it borrow? If there isnt a limit, wouldnt it have the potential to starve the host/cluster?

So can someone please explain this for me and who's wrong, Scott or VMware (I doubt they'd be wrong!).

Find more posts tagged with

Comments

QHalo

If the VM exceeds its reservation, which if no reservations are set is equal to the cpu and memory allocation you gave the VM + it's memory overhead, it would traverse the sibling RP to the parent RP. In this case it would attempt to borrow from the cluster or host cpu and memory. It can't overconsume the host or cluster because if you created a VM that was equal to the amount of RAM and CPU of the host or cluster, you'd never be able to power it on because there's memory overhead and that would violate the parent RP allocation.

That's the way I understand it.

blargoe

QHalo wrote: »

If the VM exceeds its reservation, which if no reservations are set is equal to the cpu and memory allocation you gave the VM + it's memory overhead, it would traverse the sibling RP to the parent RP. In this case it would attempt to borrow from the cluster or host cpu and memory. It can't overconsume the host or cluster because if you created a VM that was equal to the amount of RAM and CPU of the host or cluster, you'd never be able to power it on because there's memory overhead and that would violate the parent RP allocation.

That's the way I understand it.

Yeah, this is right. Expandable just means that it can tap into whatever the parent container is for the VM or Resource Pool (could be a parent resource pool, or could be that the next tier is the top of the host/cluster). If the parent's limit has been reached (and the parent itself is not expandable), then no further expansion can occur on the child.

scott28tt

QHalo wrote: »

If the VM exceeds its reservation, which if no reservations are set is equal to the cpu and memory allocation you gave the VM + it's memory overhead, it would traverse the sibling RP to the parent RP. In this case it would attempt to borrow from the cluster or host cpu and memory. It can't overconsume the host or cluster because if you created a VM that was equal to the amount of RAM and CPU of the host or cluster, you'd never be able to power it on because there's memory overhead and that would violate the parent RP allocation.

That's the way I understand it.

Expandable reservation only comes into play in respect to reservations within the resource pool that has the expandable reservation, not the actual consumption of resources. So I disagree with the first 2 sentences. Reservations are guaranteed minimum levels of resource.