System Center 2012 Virtual Machine Manager offers new capabilities for a new computing age
I say this in many articles, talks, and books: We really are in a third age, as far as thinking about our IT infrastructures is concerned. Originally, administrators focused on each physical server on which an OS was installed. You walked around the data center and pointed to each server: "That's my domain controller; that's my Microsoft SQL Server machine," and so on. Management was performed on a per-box basis because each box ran a single OS with a single application. With virtualization, OSs were consolidated onto fewer physical boxes hosting multiple virtual machines (VMs), and we entered the virtualization age. We focused on each OS instance: "That system is running a bunch of VMs; that one's running a bunch of VMs, too." Unsurprisingly, tours of data centers weren't as popular as they had been. The management effort was similar, provisioning became a bit easier, but there were extra hypervisor pieces to manage. Each OS was still managed individually. As an administrator, you connected via RDP to a server -- if you were very advanced, you connected remotely, via System Center Service Manager -- but still managed and focused on one OS at a time.
The Third Age
With the private cloud, we enter the third age of management. The focus shifts to the service that's being provided. The management infrastructure should manage and provision the OS as a collective, behind the scenes, allowing the focus to be on the service rather than on the underlying OS. To enable this shift to application-centric thinking, two things are needed:
- A way to easily deploy server-application instances with only a few target-specific configuration items, and the ability to move those application instances between OS instances without reinstalling or losing configuration
- A modeling capability to enable the design of services that might have multiple tiers of components (e.g., a database back end, a middleware layer, a web front end) and multiple, definable role instances for each tier so that the service can scale up or down, depending on load
Not surprisingly, Microsoft Virtual Machine Manager addresses both these needs.
Readers who are familiar with desktop technologies probably know that Microsoft acquired a company called Softricity several years ago, renaming Softricity's Softgrid application-virtualization solution as Microsoft Application Virtualization. App-V allows an application to run locally on an OS, without being installed on the OS, through the use of a virtual environment. This environment has virtual layers, such as file system and registry, in which application artifacts (e.g., files, settings) reside. This application virtualization allows applications to be delivered very quickly. No application installation takes place. Because applications each run in their own virtual environment, a major application problem is solved -- namely, application-to-application compatibility challenges, such as when application A can't exist on the same OS instance as application B. Because the applications are virtualized and run in their own sandboxed environments, they don't see one another.
The goals for server virtualization are different than those of desktop virtualization. Server application isolation is rarely required or even desirable. Likewise, real-time streaming of server applications is an uncommon requirement. What's wanted is the ability to simplify the deployment of server applications, which can have primarily manual, 100-page installation processes. Also desirable is the ability to enable server-application mobility between OS instances, so that OSs can be serviced without lengthy application downtime, by moving an application instance from one OS instance to another.
Now, the App-V technology has been enhanced to support server requirements, via Microsoft Server Application Virtualization (Server App-V), a specific version of App-V that's part of Virtual Machine Manager 2012. The major differences from the desktop App-V features are as follows:
- Support for system services
- COM,COM+, and DCOM components, captured and visible through tools such as Dcomcnfg
- Virtualization of Windows Management Instrumentation (WMI) providers and classes that applications install
- Local user and group creation
- Virtualization of Microsoft Internet Information Services (IIS) 6.0 and earlier websites
- SQL Server Reporting Services (SSRS) virtualization support
- Virtualization of application configuration and data, enabling the entire application installation and state to be easily backed up and restored
This technology means that a server application is installed once in the Server App-V sequencer environment, which creates the Server App-V packaged version of the application. There, the entire installation process is performed, and any machine-specific configurations (e.g., service credentials, hostnames, port numbers) are extracted. This packaged Server App-V application can then be quickly deployed in a consistent way, simply by passing these instance-specific settings to all the required environments (e.g., development, testing, production). This approach solves many problems that are common when deploying complex applications between environments. In addition, the deployed Server App-V application instance and all its data can easily be backed up and deployed to another OS instance, maintaining all application states. Not only is the server application virtualized, but any related configurations and data are connected to the packaged application and can easily be backed up and restored through Server App-V Windows PowerShell cmdlets, providing easy portability between OS instances.
During the creation of a Server App-V sequenced server application, the sequencer process automatically identifies many instance-specific parameters, such as the hostname and credentials. However, you can also modify the packaged application after sequencing. The person who performs the sequencing can specify additional properties from the registry, services, and XML configuration files to be considered instance-specific; these properties will then prompt for a value during the deployment of the virtualized server application. In future versions of Server App-V, I expect to see even more flexibility for extracting instance-specific values from regular text files instead of from XML files only.