Run OS Run...

The above title is a horrible attempt at a Forest Gump reference.

Either way - Novell announces support for VMWare's Virtual Machine Interface - which allows Suse Linux Enterprise Server (SLES) 10 Service Pack 2's kernel to have "increased performance and better interoperability".

Think of it this way - there will be preferred OS's to virtualize - Novell says you can virtualize Suse since its just x86 virtualization but if you do SLES 10SP2 - you can get VMI support.

In the paravirtualization space - this will mean increased density, better running VM's, better running ESX hosts, etc.

In other words - "the guest operating system is modified to work more closely with the underlying hardware and not just with the virtualized environment."

And its a brand differentiator as well - the OS and the VM platform both have to be tuned or tunable - and with VMI - VMWare is saying they are prepared to virtualize an OS like SUSE better than its competitors.

VKernel Ships Capacity Bottleneck Analyzer

We shipped the Capacity Bottleneck Analzyer (PDF) virtual appliance.

Go download CBA and start reviewing your performance, resources, and capacity with an appliance that's quick to download.

You just configure the IP address (DHCP or Static) and then point CBA at your Virtual Center or ESX host and start collecting and reporting.

Servers are no longer a "Resource Boundary"

One of the hardest concepts for System Administrators new to virtualization to understand is the shared resource management. VMware ESX makes it possible to share resources namely memory, cpu, storage and network not only inside a physical host, but also across multiple physical hosts. The resources are pulled together to create one massive resource pool captured in a concept called a cluster. Even resources inside clusters can be further subdivided into many Resource Pools. For admins who are only used to dealing with physical servers as resource boundaries this can be confusing, especially when it comes to planning and management of capacity. For example when monitoring or determining resource capacity, Admins must now take into consideration how all resource boundaries are affected. Looking just at physical servers is no longer an option!

9 capacity bottlenecks in ESX that kill performance

I have compiled a list of "things" that can cause you to run out of capacity resources in your ESX data center and run into performance problems or even downtime:

1. Adding new VMs though uncontrolled VM sprawl
2. Removing hosts from clusters
3. HA enabling your cluster without accounting for fail over
4. Changing Fail Over Capacity setting in a Cluster
5. Increasing reservations in VMs
6. Changing Resource Pool Configurations
7. Power up many VMs that were powered off or in maintenance
8. Natural growth rates in Storage, CPU, Memory and Network utilization
9. Changes in workloads can result in Disk I/O bottlenecks

Did I miss any? Let me know abakman@vkernel.com

Virtual server sprawl reality

If you have not heard the term "virtual machine sprawl", welcome to virtualization. While the number of physical hosts in your environment will start shrinking, the number of VMs will grow exponentially once your users figure out just how easy it is to create "another server".

The implications are many:

1. If you thought that you had "too many" servers to manage before, guess what? It will actually get worse. A thousand of anything is too much to manage, ten thousand of anything will send you off the deep end. The management challenge is in the numbers, and there is no relief in sight on this front. To fight it getting organized is the answer. You will have to get really good at keeping asset inventory of your VMs. You have to know how many VMs you have where are they, what's in them, what state they are in.

2. Capacity planing will quickly become an issue. Think about it. Adding VMs at a quick pace will begin to strain your ESX resources. You will be amazed at just how quickly your "plentiful" amount of memory, storage and CPU starts to disappear. Each VMs is consuming recourses and before you know your overburdened hosts begin to develop performance problems. To fight it, you have to get disciplined and control introductions of new VMs. At minimum you need a an approval process to quickly review new VM requests.

3. Audit of VM environment will become even more challenging. With so many VMs being added, knowing who is acting on them,, what changes are being made and where will require a real herculean effort.

Are we having fun yet? What do you think? Drop me a line.