IT Core Blog

Never stop questioning. Curiosity has its own reason for existing…

Posts Tagged ‘Hyper-V

Failover Clustering & Hyper-V: Planning your Highly-Available

leave a comment »

From Microsoft tech.ed online here’s an excellent video to help you with the Failover Clustering in Hyper-V.

This technical session will discuss Hyper-V and Failover Clustering live migration, deployment considerations, licensing, upgrades, host clustering, guest clustering, disaster recovery, multi-site clustering, System Center Virtual Machine Manager, hardware and validation. What are the pros and cons of each virtualization solution? What’s right for my customers and their scenarios? What about combining physical and virtual machines in the same cluster? This session will include a live demo of a Hyper-V Cluster deployment and live migration.



Written by IT Core

November 23, 2010 at 9:34 PM

Posted in How to..., Videos, Virtualization

Tagged with ,

How Time Synchronization works in Hyper-V

leave a comment »

Ben Armstrong explains in dep How Time Synchronization works in Hyper-V.

Problem #1 – Running virtual machines lose track of time.

While all computers contain a hardware clock (called the RTC – or real-time clock) most operating systems do not rely on this clock.  Instead they read the time from this clock once (when they boot) and then they use their own internal routines to calculate how much time has passed.

The problem is that these internal routines make assumptions about how the underlying hardware behaves (how frequently interrupts are delivered, etc…) and these assumptions do not account for the fact that things are different inside a virtual machine.  The fact that multiple virtual machines need to be scheduled to run on the same physical hardware invariably results in minor differences in these underlying systems.  The net result of this is that time appears to drift inside of virtual machines.

UPDATE 11/22: One thing that you should be aware of here: the rate at which the time in a virtual machine drifts is affected by the total system load of the Hyper-V server.  More virtual machines doing more stuff means time drifts faster.

In order to deal with time drift in a virtual machine – you need to have some process that regularly gets the real time from a trusted source and updates the time in a virtual machine.

Hyper-V provides the time synchronization integration services to do this for you.  The way it does this is by getting time readings from the management operating system and sending them over to the guest operating system.  Once inside the guest operating system – these time readings are then delivered to the Windows time keeping infrastructure in the form of an Windows time provider (you can read more about this here:   These time samples are correctly adjusted for any time zone difference between the management operating system and the guest operating system.

Problem #2 – Saved virtual machines / snapshots have the wrong time when they are restored.

When we restore a virtual machines from a saved state or from a snapshot we put back together the memory and run state of the guest operating system to exactly match what it was when the saved state / snapshot was taken.  This includes the time calculated by the guest operating system.  So if the snapshot was taken one month ago – the time and date will report that it is still one month ago.

Interestingly enough, at this point in time we will be reporting the correct (with some caveats) time in the systems RTC.  But unfortunately the guest operating system has no idea that anything significant has happened – so it does not know to go and check the RTC and instead continues with its own internally calculated time.

To deal with this the Hyper-V time synchronization integration service detects whenever it has come back from a saved state or snapshot, and corrects the time.  It does this by issuing a time change request through the normal user mode interfaces provided by Windows.  The effect of this is that it looks just like the user sat down and changed the time manually.  This method also correctly adjusts for time zone differences between the management operating system and the guest operating system.

Read more here 🙂

Written by IT Core

November 23, 2010 at 9:25 PM

Posted in Documentation, Tools, Virtualization

Tagged with

SCVMM P2V fails with Error 2910 (0x80070005) Access Denied

leave a comment »


When using Microsoft System Center Virtual Machine Manager 2008 to perform a Physical-to-Virtual conversion (P2V), the following error message appears during the Scan System phase.
Error (2910)
VMM does not have appropriate permissions to access the resource on the %server.
Access is denied (0x80070005)
Recommended Action
Ensure that Virtual Machine Manager has the appropriate rights to perform this action.
Additional Information: The Source computer is the machine intended to be virtualized in the P2V conversion.


This failure is typically caused by either of the following conditions:

•  The credentials provided during the P2V wizard is not a member of the local ‘Administrators’ group on the Source computer.
•  The Source computer does not allow remote WMI calls to the CIMV2 namespace for the credentials entered during the P2V wizard.

To resolve the problem, follow these steps:

  1. Make sure that the account used during the P2V wizard is a member of the local ‘Administrators’ group on the Source computer. Note Pay particular attention to this if the SCVMM server and Source computer are in different domains.
  2. During the Scan System phase of the P2V conversion, SCVMM makes WMI calls to the CIMV2 namespace on the Source computer to pull basic system information. If these WMI calls fail, then the P2V conversion will also fail. To verify WMI connectivity to the CIMV2 namespace on the Source computer, perform the following actions from the SCVMM server:
  3. Click Start , point to Run and type ” WBEMtest” (without the quotes) in the Open box and click OK . This will open the WBEMtest window.
  4. Click Connect in the upper right hand corner.
  5. Now, connect to the CIMV2 namespace on the Source computer.

Example: \\Source\ROOT\CIMV2

                Note Be sure to use the name of your Source computer.

  1. Then click Connect to complete the connection. This should connect without any errors displayed.
  2. Just to confirm access to a sample object, select Open Class and type Win32_PhysicalMemory
  3. You should see objects populate in the Object Editor window. The actual content returned is not as important as the fact that a remote connection to the CIMV2 namespace was established.
  4. Open wmimgmt.msc and verify connectivity to the Local computer and also check the ‘Remote Enable’ permissions.
    1. Click Start , point to Run and type wmimgmt.msc and click OK . This will open the WMI Control (Local).
    2. Right click on the WMI Control (Local) node and select Properties .
    3. Select the Security tab, highlight Root and then open security by clicking the Security button in the lower right.
    4. Select “Remote Enable” permission for Everyone or the specific user account that you want to grant this permission to.
    5. This action does not require a reboot.
    6. Open dcomcnfg and verify that DCOM is running and also check the ‘Remote Activation’ permission.
      1. Click Start , point to Run and type dcomcnfg and click OK . This will open the Component Services snap-in.|
      2. Expand Component Service , then Computers , then My Computer . If My Computer has a red down arrow mark, it means that the service is not running. It will need to be started.
      3. Right click on My Computer and select Properties and select the COM Security tab.
      4. Click Edit Limits under the Launch and Activation Permissions section.
      5. For the Everyone user give the “Remote Activation” permission or add the specific user account that you want to grant this permission to.

Note The following error message may occur if the appropriate WMI permission is not granted to the user:
Access Denied” with Error Code: 0x80041003

  1. This problem can also occur if the OLE registry key is missing or has the incorrect value on the Source computer.
    1. Start Registry Editor.
    2. Locate the following path:
    3. This key should have a REG_SZ value EnableDCOM and a value of Y

Written by IT Core

November 23, 2010 at 9:17 PM

KB2465160: Add Host or other action fails with (2916) 0x80338126 in System Center Virtual Machine Manager 2008

leave a comment »

From Microsoft , KB2465160.

Adding a Host to System Center Virtual Machine Manager 2008 (SCVMM 2008) fails with a variation of Error (2916):

Error (2916)
VMM is unable to complete the request. The connection to the agent was lost.
(The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and firewall exception for Windows Remote Management service is enabled. (0x80338126))

Recommended Action:
Ensure that the WS-Management service and the agent are installed and running and that a firewall is not blocking HTTP traffic. If the error persists; reboot and then try the operation again.

Specific content is being filtered by a non-Windows firewall. The firewall could be software installed on either the SCVMM 2008 Server or the Host that is being added. More likely, there is a hardware appliance firewall on the network between the two communicating servers.

Test multiple communication protocols between the two systems; the SCVMM 2008 Server and Host in this example. Some firewalls can have content filtering enabled despite showing that it is not. Remove all non-Windows software firewalls and bypass all hardware appliance firewalls entirely long enough to perform testing to verify whether or not they are contributing to the problem.

The following tests are examples of protocols that should always succeed. Test both directions always:

Ping by DNS name in both directions (NETBIOS and FQDN). The IP address returned must match.
Access to ‘\\\admin$’ from the ‘Run’ command in both directions. This must succeed.
From Server B: \\\admin$
From Server A: \\\admin$
WinRM basic connectivity in both directions. This must succeed. If it does not, execute ‘winrm qc’ on both servers, accepting all prompts, then test again.
Remote NETBIOS test: winrm id -r:remoteserver
Remote FQDN test: winrm id
WinRM successful reply example:

C:\>winrm id -r:ServerA
    ProtocolVersion =
    ProductVendor = Microsoft Corporation
    ProductVersion = OS: 6.1.7600 SP: 0.0 Stack: 2.0

More Information
Recently a firewall appliance sold by a major vendor showed content filtering disabled and not licensed to be turned on, yet was still filtering specific content. This was discovered through examination of network traces. Do not assume content, protocols or traffic are not being blocked. Perform tests to verify.

Written by IT Core

November 23, 2010 at 9:12 PM

Virtual Machine Servicing Tool (VMST) 3.0

leave a comment »

This release of the Virtual Machine Servicing Tool (VMST) 3.0 completely replaces the Offline Virtual Machine Servicing Tool version 2.1.

Version 3.0 of the tool works with System Center Virtual Machine Manager 2008 R2, System Center Configuration Manager 2007 SP2, and Windows Server Update Services 3.0 SP2. The tool also supports updating the Windows® 7 and Windows Server® 2008 R2 operating systems.

To Download the Virtual Machine Servicing Tool 3.0 click here.

Some highlights include:
•    Offline virtual machines in a SCVMM library.
•    Stopped and saved state virtual machines on a host.
•    Virtual machine templates.
•    Offline virtual hard disks in a SCVMM library by injecting update packages.

Written by IT Core

September 28, 2010 at 12:00 AM

KB2413735: Mouse and screen resolution issues when managing a virtual machine using the Hyper-V

leave a comment »

From KB2413735

Windows Server 2008 or Windows Server 2008 R2, you may experience one of the following symptoms when you connect to a Hyper-V virtual machine using the Hyper-V Manager console or the System Center Virtual Machine Manager Administrator Console:
· The mouse cursor is frozen or has disappeared
· The screen resolution has reverted to the default size
If you connect to the virtual machine using a Remote Desktop Connection (RDP), the symptoms listed above are not exhibited.

This issue can occur after a new Hyper-V VMMS certificate is generated.
Note: The following event will be logged in the Hyper-VMMS event log when a new VMMS certificate is generated:

Log Name: Microsoft-Windows-Hyper-V-VMMS-Admin
Source: Microsoft-Windows-Hyper-V-VMMS
Event ID: 12520
Level: Warning
Auto-generating a self-signed certificate for server authentication.

To resolve this issue, perform one of the following steps on the Hyper-V server:
·Place the virtual machines in a saved state and then resume the virtual machines.
·Restart the virtual machines.

The self-signed certificate that is generated by the Hyper-V Virtual Machine Management service is valid for one year.

To create a self-signed certificate that doesn’t expire for several years, perform the following steps:
Copy the PowerShell script from the following Microsoft Web site: (
2. Paste the script into notepad, and then save the file as Cert.ps1. 
3. Copy Makecert.exe to the same directory as the Cert.ps1 file.
For more information on how to obtain Makecert.exe, please visit the following Microsoft web site: (
4. Open an elevated Windows PowerShell command prompt. 
5. Run the Cert.ps1 script.


Written by IT Core

September 23, 2010 at 12:14 PM

Hyper-V R2 Cluster CSV stops working when NTLM is disabled in cluster with Hyper-V Enabled

leave a comment »

Hyper-V R2 Cluster CSV stops working when NTLM is disabled in cluster with Hyper-V Enabled

ID: 5121
Source: Microsoft-Windows-FailoverClustering
Version: 6.1
Message: Cluster Shared Volume ‘%1′ (’%2′) is no longer directly accessible from this cluster node

This error may be caused because the NTLM was disabled in your Hyper-Host. Enabling a policy to disable NTLM may break CSV and cause the alert described before.

If the NTLM was disabled using GPO in your Active Directory Domain, identify the GPO with this setting and create an exception to this policy for all clustered Hyper-V computer objects. Alternatively you can create and link another GPO (GPO with “enable NTLM” setting) that applies just to the clustered hosts. 


Written by IT Core

September 21, 2010 at 10:07 PM