Let's go back to a time when there wasn't a concept of server virtualization. We had data centers running a large number of machines; most of them were bought to run an application or a set of services. All those servers had enough CPU, memory, and storage capacity to host the application or the services that were running on it. The amount of compute and storage resources depended on what the application or the service would need during its peak load. However, the catch here is that not all servers execute peak load all the time. Research shows that more than 90% of hardware resources remain under-utilized. That is a huge number in terms of resource wastage. Running more than one application or service for the business always meant that there was a demand for additional hardware resources. Such a demand contributed to other factors such as power consumption, investment in cooling solutions, hardware maintenance, and the real estate space required to host all the hardware.

Now, a possible solution an administrator could have fantasized about would be to find a way to somehow magically connect all these servers together and present it as a large pool of resources to the applications or services. If that were possible, then you would probably be renting out 90% of your resources, that you have already invested in, to someone else to run their applications and you are paid for that service. Or, if you were in the planning phase of a new infrastructure, you could reduce the amount of server hardware needed for hosting the services. Unfortunately, such a conglomeration was far from reality due to two main reasons, the first one being the physical boundaries that separate these hardware resources and the second one being that not all services could run alongside each other without running into a conflict, affecting both the services. This is where the concept of server virtualization did its magic, on its introduction, like never perceived before.

In this chapter, we will learn the following: