System Center 2012 R2 Virtual Machine Manager Cookbook

Event logs: A good starting point is to look at the event logs. Look for OS- and VMM-related errors or failures. A problem with the Operating System or one of its core services could result or lead to a problem in VMM.
For example, if you are running SQL Server on the same server and it did not start, the VMM management service will not start either and VMM operations will fail as a direct result of this. You can easily find this by looking for errors in the system or application logs or errors that would indicate, in this example, that the service is not running (for this example, you can also check Services.msc).
VM manager log: When looking for VMM errors, it is recommended that you look at the VM Manager log as well. To do so, perform the following steps on the VMM server that runs Windows 2012:
1. In the Server Manager window, click on Tools.
2. Select Event Viewer, expand Applications and Services logs, and then select the VM Manager log.
VMM installation-related troubleshooting logs: VMM records information about the VMM agent installation. However, if the installation logging is not sufficient to determine the cause of failure, you can enable tracing by using the VMM MPS Reports tool and then restart the installation.
VMM server setup logging: Installation logs are written, by default, to the C:\ProgramData\VMMLogs hidden folder.
VMM agent installation logging: When installing an MSI package, such as installing the VMM agent manually, you can enable logging using the following syntax:
```
msiexec /I <MSIPackageName.msi> /L*V <path\logfilename>.log
```
For example, using the syntax, we can come up with something like the following command:
```
msiexec /I "C:\setup\vmmAgent.msi" /L*V vmmagent.log
```
The local agent installation information is logged in the C:\ProgramData\VMMLogs hidden folders.
Look for the log file, vmmAgent.msi_<m-d-yyy_hh-mm-dss>.log.
Tip
In logs, it is common to see errors shown as Carmine errors. Carmine was a VMM project name code during its development process.
Troubleshooting WinRM: To check whether WinRM has remote access, check the following:
- The Security Identifier (SID) in RootSDDL maps to the Virtual Machine Manager Servers local group on each Hyper-V host
- The local group contains the account that VMM management service runs as a service

How it works…

A good understanding of what a successful installation log contains from a POC or a pilot environment is important to identify possible issues, especially if it appears when deploying VMM on a production environment, as you can then compare both logs.

There's more…

Run the following command on the Hyper-V host:

winrm id

This should produce an output similar to the following one:

IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 6.1.7201 SP: 0.0 Stack: 2.0

If the result shows an error, run the following command for a quick configuration of WinRM:

winrm qc

If prompted, answer Yes. You will receive a response similar to the following one:

WinRM already is set up to receive requests on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made: Enable the WinRM firewall exception
Make these changes [y/n]?
WinRM has been updated for remote management.
WinRM firewall exception enabled.
WinRM can now be tested again by typing 'winrm id' as before

Now, check the listener with the following command:

winrm enum winrm/config/listener

Run the following command on the VMM management server:

winrm id –r:http://HyperVHost.yourdomain.local:5985  –u:YOURDOMAIN\AdminUser

The result will be similar to the following one:

IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 6.1.7201 SP: 0.0 Stack: 2.0

Otherwise, you will receive the following error:

Error number: -2144108526 0x80338012
The Client cannot connect to the destination specified in the request

This could indicate communication issues, so check your network, host firewall, and connectivity.

Most WinRM-related events appear in the system or application event logs. The Service Control Manager often contains the error, as the WinRM service has terminated or restarted for some reason.

During the VMM installation, you will get the following error:

To avoid this scenario, conduct the following checks:

Make sure that you have installed all of the prerequisites
Check the firewall rules and make sure the ports are configured correctly

Open the command prompt (Run as Administrator) and type the following commands:

winrm qc -q
winrm set winrm/config/service/auth @{CredSSP="True"}
winrm set winrm/config/winrs @{AllowRemoteShellAccess="True"}
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="2048"}

Verifying WMI providers

You can check whether the WinRM can communicate with OS WMI providers by running the following command:

winrm enum wmi/root/cimv2/Win32_ComputerSystem -r:http://servername:5985 [–u:YOURDOMAIN\AdminUser]

By running the following command, you can check whether the WinRM can communicate with Hyper-V WMI providers:

winrm enum wmi/root/virtualization/msvm_computersystem
-r:http://servername:5985 [–u:YOURDOMAIN\AdminUser]

Also, to check whether WinRM can communicate with the VMM agent WMI provider, run the following command:

winrm invoke GetVersion wmi/root/scvmm/AgentManagement
-r:servername [–u:YOURDOMAIN\AdminUser] @{}

Tip

If you are using VMM services, do not remove and re-add the host. Instead, evacuate the host before removing it or, on the host, uninstall and then reinstall the agent manually, and then reassociate it in VMM.

Troubleshooting tools

The following are the troubleshooting tools available for use:

Windows Management Instrumentation Tester (wbemtest.exe): The wbemtest.exe tool gives you the ability to query WMI namespaces on local or remote servers.
Connecting to a namespace locally indicates that it is properly registered and is accessible via the WMI service. By connecting to a remote server additionally, it also indicates that the WMI connectivity between the two machines is working.
For more information about wbemtest, refer to the link at http://technet.microsoft.com/en-us/library/cc785775.aspx.
WMI Service Control Utility: This tool configures and controls the WMI service, allowing namespace permissions to be modified.
To open this tool, type in the following command in the command prompt:
```
winmgmt.msc
```
Then, perform the following steps:
1. Right-click on WMI Control (Local).
2. Select Properties.
3. Click on the Security tab, and then select Root.
4. Click on the Security button to check the permissions.

Background Intelligent Transfer Service troubleshooting

Background Intelligent Transfer Service (BITS) transfers files between machines, providing information about the operation's progress. The transfer can be asynchronous.

In VMM, BITS is used for encrypted data transfer between managed computers. Encryption is done by using a self-signed certificate that is generated when the Hyper-V host is added to VMM.

You can use BITSadmin to verify that BITS is working properly outside of VMM. BITSadmin can be downloaded at http://msdn.microsoft.com/en-us/library/aa362813(VS.85).aspx.

You can also find some examples of BITSadmin at http://msdn.microsoft.com/en-us/library/aa362812(VS.85).aspx.

Data collection tools

The following tools are used to collect data surrounding VMM issues:

VMM tracing tools: VMM tracing tools provide the ability to manage, collect, and view various traces and diagnostic information in a VMM environment.
When you face an issue and need to report it to Microsoft, you can gather the trace by performing the following steps:
1. In the VMM server, open the command prompt with administrative rights and type in the following command:
```
logman create trace
VMMDebug -v mmddhhmm -o %SystemDrive%\VMMlogs\DebugTrace_%computername%.ETL -cnf 01:00:00 -p Microsoft-VirtualMachineManager-Debug
```
2. Start the trace collection by executing the following command:
```
logman start VMMDebug
```
3. Next, try to reproduce the issue, and at the end, stop the trace collection by executing the following command:
```
logman stop VMMDebug
```
4. Send the ETL file located in %SystemDrive%\VMMlogs\DebugTrace_%computerna;me%.ETL to Microsoft.
5. Delete the debug information by executing the following command:
```
logman delete VMMDebug
```
The VMM TraceViewer utility: After gathering the trace, you can use TraceViewer on the traces. This tool converts the ETL binary trace logs into CAR files that can be viewed in both the TraceViewer and other trace parsing tools and provides basic trace parsing.
To convert the ETL file, perform the following steps:
1. In the TraceViewer, drag the trace file into the open pane.
2. Provide the location to where you want to save the CAR file. Once the file has been saved, TraceViewer will open the converted ETL file for analysis.
3. You can download the tool from http://blogs.technet.com/b/jonjor/archive/2011/01/07/vmmtrace-simplified-scvmm-tracing.aspx.

System Center 2012 R2 Virtual Machine Manager Cookbook - Second Edition

By : Edvaldo Alessandro Cardoso Sobrinho, EDVALDO ALESSANDRO CARDOSO

System Center 2012 R2 Virtual Machine Manager Cookbook - Second Edition

By: Edvaldo Alessandro Cardoso Sobrinho, EDVALDO ALESSANDRO CARDOSO

Overview of this book

Related Content you might be interested in

Current Title:

System Center 2012 R2 Virtual Machine Manager Cookbook - Second Edition

Troubleshooting VMM and supporting technologies

Getting ready

How to do it…

Tip

How it works…

There's more…

Verifying WMI providers

Tip

Troubleshooting tools

Background Intelligent Transfer Service troubleshooting

Data collection tools

See also