Additionally, once you create a resource pool for networking and storage, the resource
pools will become visible in the Hyper-V Manager GUI (but not for processor and
memory), as shown in Figure 6.13.
Figure 6.13 Viewing resource pools in Hyper-V Manager
Once the resource pool is created, it can be enabled for metering by using the normal
cmdlets, except instead of a virtual machine name (VMName), specify the name of the
resource pool (ResourcePoolName), as in this example:
Enable-VMResourceMetering -ResourcePoolName GroupA
If you create a resource pool, run the Get-VMResourcePool cmdlet again. You will see a
lot of new entries. Remember, if you use resource pools, by default, you would not be
able to move a virtual machine configured in a resource pool if the target host does
not have the same resource pool defined. I think resource pools are an interesting
concept, but they need to be easily managed across multiple hosts to be a useful
feature.
While resource pools are primarily aimed at metering, they can also be used for
resource allocation. Notice in the Add-VMNetworkAdapter command earlier, I don’t
specify a switch but rather just a resource pool that has switches added to it. This
allows me to easily provision virtual machines on different hosts (provided the
resource pool is defined on multiple hosts) and not worry about the switch name. I
don’t expect many people to use resource pools in this manner. Using SCVMM to
manage resource allocation is a much better and more enterprise-ready approach.
Monitoring
I want to close with the concept of monitoring your environment. When you
virtualize, as I’ve said previously, you are putting all your eggs into a much smaller
number of baskets. It’s critical that those baskets are healthy and being proactively
monitored, so you are not only alerted when something breaks, but also notified when
something is not performing as expected, when best practices aren’t used on
something, and when there are signs of impending failure.