More catch up from the last 2 weeks, this time for Hyper-V:
Consider the following scenario:
- You have a computer that is running Windows Server 2008 or Windows Server 2008 R2 system that has a Hyper-V role installed.
- You start several Hyper-V virtual machines at the same time.
In this scenario, each Hyper-V virtual machine takes about 1 minute to start. Therefore, if you have more virtual machines, the last virtual machine takes longer to start. For example, when you start 30 virtual machines at the same time, it takes up to 30 minutes for the last virtual machine to start.
When you check the Microsoft-Windows-CAPI2/Operational log after the virtual machines have started, the following event is logged:
Log Name: Microsoft-Windows-CAPI2/Operational
Source: CAPI2
Event ID: 53
Level: Error
User: NETWORK SERVICE
Task Category: Retrieve Object from Network
When you view the event details, the EventAuxInfo ProcessName value is vmwp.exe.
When you start the Hyper-V virtual machines, the certificate store is enumerated to determine the preferred certificate that should be used to manage the virtual machine. If there are issues in verifying certificates in the store, they may cause the virtual machines to take longer than 30 minutes to start.
To work around these issues with certificates, you can configure a Hyper-V role to use the self-signed certificate that is generated by the Hyper-V Virtual Machine Management (VMMS) service instead of enumerating the whole certificate store when the virtual machines are started.
To configure a Hyper-V role to use the self-signed certificate from the VMMS service, follow these steps:
- To copy the PowerShell script, visit the following Microsoft Web site:
http://gallery.technet.microsoft.com/ScriptCenter/en-us/5b4a7114-218b-466c-a9c1-7eb2f725e707 (http://gallery.technet.microsoft.com/ScriptCenter/en-us/5b4a7114-218b-466c-a9c1-7eb2f725e707)
- Paste the script into Notepad, and then save the file as Certfix.ps1.
- Open an elevated Windows PowerShell command prompt.
- Run the Certfix.ps1 script.
For example, if you save the script to C:Scripts, type the following command at the PowerShell command prompt:
C:ScriptsCertfix.ps1
Note The self-signed certificate that is generated by the Hyper-V VMMS service is valid for one year. As soon as the certificate expires and the Hyper-V VMMS service generates a new certificate, you must run the Certfix.ps1 script to configure the Hyper-V role to use the new certificate.
To determine the expiration date for the Hyper-V VMMS service self-signed certificate, follow these steps:
- Click Start, click Run, type mmc, and then click OK.
- On the File menu, click Add/Remove Snap-in.
- Click Certificates, and then click Add.
- Click Service account, and then click Next.
- Click Local Computer, and then click Next.
- Click Hyper-V Virtual Machine Management, and then click Finish.
- Click OK to close the Add/Remove Snap-in window.
- Expand Certificates – Service, expand VmmsPersonal, and then click Certificates.
- Double-click the VMM Service certificate, and then check the expiration date in the VMM Service certificate window.
Consider the following scenario:
- You install the Hyper-V role on a computer that is running Windows Server 2008 R2 Service Pack 1 (SP1).
- You create a virtual machine on the Hyper-V server.
- You configure the virtual machine to use Dynamic Memory and set the Maximum RAM setting to a value that is larger than 4 GB.
- You start the virtual machine, and memory consumption approaches the maximum limit.
- You try to generate a complete memory dump file on the virtual machine.
In this scenario, it takes a very long time to generate a complete memory dump file on the virtual machine. For example, it takes approximately 5 hours to generate a complete memory dump file if you set the Maximum RAM setting to 8 GB.
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.