In a previous post we discussed one of the latest capabilities in VMTurbo Release 5.0, enabling our users to understand various constraints in their environment. Let’s continue to explore how this capability helps with managing virtualization constraints and how they may be impacting your pursuit of the desired state – an operational state in which application performance is assured while the environment is utilized as efficiently as possible, i.e. a “healthy” state for your applications.
Remember some constraints are logical while others may have been placed on the environment by a mistake or in an attempt to “control” it.
To explain this new capability in a bit more detail let’s look at two scenario 1) A highly utilized host is running high on memory but a network constraint is preventing a vMotion and 2) Understanding why a VM placement constraint is driving a high host utilization index.
Let’s look at the first scenario first. In this case we have one host with memory highly utilized but other hosts on the same cluster have lower memory utilization. As any VMTurbo user will tell you the market will sort this out and you’d expect to see a vMotion action or in automation mode it will just happen.
Below you can see that hp-edx52 has memory utilization at over 90% while the other hosts are all below 80%.
You can also see below that 3 out of the 4 VMs on this host are suffering from high Latency utilization.
But there is a problem, the network is not shared properly in that cluster and the VM cannot move to another host that has a lower memory utilization and is offering the vMem the VM so badly demands (along with other critical resources) for a lower price. Below is the list of constraints for one of the VMs on hp-esx52, as you can see it has been constrained to one network provider from which it can buy network resources.
If this constraint did not exist (the network was properly shared among the hosts) and automation was enabled VMTurbo would have migrated the VM without the user’s involvement assuring that whatever application workload was running in the VM continues to get the resources it needs to assure performance.
By seeing the constraint and addressing it by properly sharing the network the user can now continue to drive the environment to its Desired State.
In another scenario let’s imagine you’ve set up a group policy restricting the number of VMs that can run on a particular host. This is often done to comply with a licensing policy. See hp-esx11’s Workload Placement Policy Constraint below.
And as you can see on the host all the way on the left below the Utilization Index is high. If you’re new to VMTurbo you may not be familiar with our Utilization Index (UI). The UI is a measure of the risk to Quality of Service (QoS) that a consumer of resources will experience. The higher the UI on a provider, the more risk to QoS for any consumer of that provider’s resources.
Although as you can see below the key commodities, CPU, Memory, IO, Network … are not highly utilized.
You can also see the first recommendation below to move one of the VMs off of the host to address a violation of workload placement.
We treat constraints just like other commodities in the market. The host only has two constraints to sell that let VMs run on it but there are three there right now so the price has gone way up.
Now the decision is yours, do you make the move to address this violation or do you remove the constraint and the VM will stay.
VMTurbo is the only demand-driven control platform that takes into account application workload demand and any constraint you place on your environment to assure your applications perform while efficiency is maximized. It understands all of the relationships and policies in your data center and will make the best decisions for you to drive your environment to its Desired State.