In development or QA environments, or moving from QA to staging, or from staging to production, live migration is a great idea. But it's not critical. The time requirements in those situations are loose enough that crashing an application while moving it around isn't necessarily fatal. But neither is the time penalty of shutting it down before moving it.

A better approach—to carefully map out your available capacity and put new VMs on hosts you know for sure have capacity and will continue to have it—isone that Microsoft also hasn't been particularly good at—at least until its Virtual Machine Manager 2008 became available as a relatively stable beta. (Microsoft announced yesterday that VMM 2008 would ship in September.)

That requires good resource-mapping and VM management capabilities; but, more important, it requires better and different capacity planning than is typical in either physical or virtualization-enabled data centers right now.

Rather than put an app on a physical server and keep loading that host up with VMs until it's ready to overload, Steffen advises putting limits on the load any physical server gets.

He also advises keeping at least 10 percent of your total compute capacity in reserve—even if that means keeping one or more servers spinning and hot but otherwise idle—so you can expand new VMs into it when you need to.

It takes less than 15 minutes to launch a new VM when Kroll needs new capacity; installing it on a server with spare capacity enhances the flexibility without increasing the risk.

That's the beauty and flexibility of virtual servers, not the questionable ability to move a VM from one server to another while it's running, Steffen says.

Why launch a VM on any server you think is going to be overloaded enough that you'd have to move it later without being able to secure its data and shut it down first, Seffen asks.

Fortunately, I had a good answer.

Duh.