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.