In virtualized environments, in-house software must interface with the hypervisor layer to ensure the software runs properly as a virtual machine and behaves correctly if it's migrated to other platforms. Fortunately, Hyper-V provides convenient access to hypervisor functions through the WMI interface, allowing developers to integrate Hyper-V features into their own software.
WMI providers and benefits of the interface
The Active Directory provider, for example, maps Active Directory objects to WMI, while a Domain Name System provider lets programmers configure DNS resources and servers using WMI. Other WMI providers include the event log, IP routes and network load balancing. The Hyper-V WMI provider is yet another WMI interface that allows software developers and IT administrators to create scripts and software tools for Hyper-V systems and their virtual machines (VMs).
The WMI interface provides several benefits, including standardization. WMI is based on established systems management standards, such as the Common Information Model (CIM) and Web-Based Enterprise Management (WBEM), which enables third-party management software to easily use WMI interfaces to control Windows systems in the data center.
The WMI providers can be compared to application programming interfaces (APIs), in that they provide the interface to certain system features and functionality that any software developer can use without needing to create low-level functions from scratch. The simplicity of the WMI interface eliminates a significant amount of programming. For example, if a developer wants to create a utility that reports the date and time of a VM configuration, he or she can query the InstallDate property of the Msvm_NumaNode class of the Hyper-V WMI provider. (Code samples are readily available from Microsoft.) The developer won't need to create code to determine the date, only to access the interface already offered by the WMI provider.
WMI provider classes and APIs
The Hyper-V WMI provider for Windows Server 2012 offers a variety of WMI classes and APIs for software developers and script writers. The Hyper-V WMI provider defines 13 classes that encompass almost all hardware elements of the server and VMs. Hardware classes include BIOS, input devices, memory, processors, resource management, serial devices, storage and video. Virtualization classes include integration services, profile registration, remote desktops, virtual systems and virtual system management.
Developers can, for instance, query the AddressWidth variable within the Msvm_Processor class to determine the processor's address width (either 32 bits or 64 bits). The developer could then use this information to invoke important 64-bit processor tasks, or to restrict 32-bit processor tasks.
Hyper-V also delivers an array of six APIs that allow programmers to interact with crucial attributes of VM management: networking, application health and metrics monitoring, replication, migration and virtual Fibre Channel adapters. A developer can determine whether a virtual system's migration network connections use CredSSP or Kerberos authentication by querying the AuthenticationType variable within the Msvm_VirtualSystemMigrationServiceSettingData class -- part of the migration API.
Creating in-house software with WMI
Organizations develop Hyper-V WMI scripts to help administrators automate certain behaviors, and frequently create software utilities to fulfill functional needs not addressed by existing software tools in production. Common tasks include backing up and restoring VMs, exporting (protecting) a VM or its configuration and deriving the VM's DNS name.
When creating software for Hyper-V, developers are free to use any platform, but programs must run on systems that support WMI, which means the developed software must support Windows Server. For example, software created for Hyper-V (V2) must run on Windows Server 2012 or Windows 8. In practice, software is developed using C, C++ or C# along with Virtual Basic Scripting Edition, or VBScript, and PowerShell.
Newly developed software will most likely be used across a wide array of servers and other computers, meaning developers should avoid referencing or relying on the availability of specific hardware devices. These devices could ultimately restrict the software's use or require re-coding to accommodate refresh cycles.
This was first published in October 2013