New bloggers: Scale the Mind, Lone Sysadmin, and Richard McDougall
I wanted to introduce a few more bloggers to our little corner of the blogosphere:
Scale the Mind. Tommy Bishop created the excellent thevirtualsearch.com (now happily resident in the sidebar to the right of this website). Recent posts are:
- What's New with VI3.5 Document Posted (Covers ESX 3.5 and VirtualCenter 2.5 Features)
- How Many ESX Servers are in Your Environment? [Reader Poll] [currently about half and half: small (< 10) and bigger (including two folks who are running over 100 ESX Servers).]
- The Next Step in the Evolution of VirtualCenter?
I envision a scenario in which the only config needed for ESX, is to be pointed to the desired VirtualCenter server (and perhaps some IP config as well). ESX would then contact the VirtualCenter server and obtain the appropriate configuration based on a pre-configured template. ESX would perform the same query upon boot and possibly at scheduled intervals.
The Lone Sysadmin. Bob Plankers runs this joint. Recent posts include:
- links for 2007-11-13 "Oracle Unveils Oracle® VM This is ridiculous. I think I’m going to create a Xen-based BobVM, and only support software on that."
- Intel Releases the Xeon 5200 & 5400 Processors "The 5400 series looks very attractive for smaller virtualization environments."
- Why I Think Your Server Will Be Fine In VMware [I agree!]
- esxcfg-nics & esxcfg-vswitch
One of my ESX Servers’ management NICs died today, right as I was to start upgrading to ESX 3.0.2. ...Luckily I had an extra, unused NIC, esxcfg-nics, and esxcfg-vswitch. With these commands you can display and alter the settings for the NICs and virtual switches from the console.
blog.richardmcdougall.com. We welcome Richard McDougall to VMware's performance team:
- Dunking Krishna in the VMware pond
- New diggs: VMware!
But why is virtualization so interesting to a performance person? ...
If we think for a moment about the holy grail for performance management, we’re trying to get to a point where we can do automated performance monitoring, diagnosis and adaptation. That is, we’d like the environment to be able to take in a set of policies that we express about our applications and act accordingly on those policies.
In the past, I’ve seen customers struggle with creating the boundary that defines where we apply these policies — it’s quite hard to define these at the application component level - for example, which process or set of processes do I apply a CPU priority to? The virtual machine however provides a great insular boundary at which resource management policies can be applied. This encapsulation of an application allows us to express a basic set of resource requirements, and then let the infrastructure decide how much CPU to apply.
With this basic encapsulation in place, we can not just apply resource management at the box level (the typical consolidation play), but now we can express and manage at the grid level — with newer techniques like Dynamic Resource Scheduling we can automatically place workloads onto a grid of machines. Once there, we can dynamically load balance them by using vMotion to move them.
This is a convenient and easy way to express encapsulation and policy today. I don’t see this as being the end-point however, rather a convenient first step. In the future, we’ll want to break out applications into individual transactions or service levels. This would allow us to monitor in terms in specific currency of the target application, and then optionally automatically control resources based on these terms.
Comments