Here in product support our job is not only to fix problems when they happen but to help prevent those problems from happening in the first place. There are a lot of ways we approach that aspect of our job but one of the top ways we do this is simply by analyzing the issues that get reported to us and seeing which ones percolate up to the top. My hope is to start blogging on a few more of these kinds of issues so that if you run into them in the future you'll have a resource on how to fix them, and also so that maybe you'll head off some of these before hitting them yourself.
With that said, here's an issue we tend to see every once in a while with SCVMM 2008 and it concerns the Refresh Host Cluster job taking a long time to complete. Now I'll have to say that we've mentioned this one before back in November of last year but we're still seeing a few calls come in so I thought it was worth a rerun here.
Issue: The Refresh Host Cluster job takes longer than 10 minutes to complete. How much longer? Well, that depends. To some it could appear to hang or lock up even though technically it's not hung, while for others it may just appear to run very slowly or take a long time in general.
Cause: This is almost always caused by the cluster having a high number of LUNs.
Resolution: If you encounter an issue like this, fortunately the resolution is simple and painless. All you need to do is install the System Center Virtual Machine Manager 2008 R2 hotfix rollup per KB976244.
And even if you're not experiencing this issue, the SCVMM 2008 R2 hotfix rollup I mentioned above fixes a few other issues as well so it probably wouldn't be a bad idea to go ahead and get that installed anyway.
Hope this helps,
J.C. Hornbeck | System Center Knowledge Engineer
You may have noticed that when you go to set custom host reserve properties in a host group these setting do not automatically propagate down to the individual hosts with those groups:
When you set the properties for “Host Reserves” at the Host Group level in System Center Virtual Machine Manager 2008 or SCVMM 2008 R2, you are, in essence, setting template values for host reserves for newly added hosts only. A common misconception is that when you set these reserves on host groups with active hosts that these reserve values will propagate down automatically or that these hosts will inherit those settings. That is not the case.
You can get these settings to pass down by leveraging the Host Group in the form of a template. All newly added hosts that are placed directly in a host group with custom reserve settings will inherit these settings; however, this is the only way this occurs.
If the host are already added, then the only way to get these settings to take effect on existing hosts is to remove the host and then re-add it directly to the host group (with reassociation.) Simply moving a new host to a host group after adding it as a host will not suffice.
Steve Thomas | Senior Support Escalation Engineer
Consider the following scenario:
In this scenario, you may receive the following error message:
Error (2947) Virtual Machine Manager cannot complete the VirtualCenter action on the server hostname.domain.com because of the following error: Error during the configuration of the host: configSpec.guestId. (Unknown error (0x194)) Recommended Action Resolve the issue and then try the operation again.
As of now, there is no resolution or work around for this scenario. The placement of a virtual machine to an instance of VMware ESX Server 3.0 host on an x64-based version of Windows Server 2008 R2 is not supported.
For all the details and latest updates please reference the following Knowledge Base article:
KB979592 - Error message when you try to deploy a newly created virtual machine to an instance of VMware ESX Server 3.0 Host that is running on an x64-based version of Windows Server 2008
This is an issue that we originally talked about a while back but we're still seeing some cases come in so I thought it would be worth another mention just in case.
When using System Center Virtual Machine Manager 2008 to perform any action involving file transfers across machines such as new VM or new P2V the operation may fail with the following error message:
Error (2912) An internal error has occurred trying to contact an agent on the %serverName%. (Element not found (0x80070490))
Recommendation Action Ensure that the agent is installed and running. Ensure the WS-Management service is installed and running, then restart the agent.
0x80070490 = Element not found = Certificate not found
Note: The exact error message displayed in the console is generic in nature, such as 2912 or 3154. However it will always contain the "Element no found" in the description.
This issue is caused by a problem with the Host certificate (incorrect name, IP instead of FQDN or NetBIOS) or the certificate is missing from the VMM server.
Identifying and verifying this issue requires capturing a trace using the Dbgview utility. The following article discusses this process in more detail, including where to download the Dbgview utility:
KB970066 How to collect traces in System Center Virtual Machine Manager
The following is a snippet from the stack trace while this error occurred - note where the operation is checking for the certificate on the VMM server. Another key is the BitDeployer.Copy function.
00006921 302.15213013 [1972] at Microsoft.VirtualManager.Engine.Deployment.FileDeploymentServerJobFactory.GetPeerCertificate(WsmanAPIWrapper clientWrapper) 00006922 302.15213013 [1972] at Microsoft.VirtualManager.Engine.Deployment.ImageDeploymentServerJobFactory.CreateJob(WsmanAPIWrapper serverWrapper, WsmanAPIWrapper clientWrapper, DeploymentFile file, Boolean useHTTPS) 00006923 302.15213013 [1972] at Microsoft.VirtualManager.Engine.Deployment.BitDeployer.Copy() 00006924 302.15213013 [1972] at Microsoft.VirtualManager.Engine.Deployment.DeploySubtask.RunSubtask() 00006948 302.15328979 [1972] *** Carmine error was: HostAgentFail (2912); HR: 0x80070490
The solution is to remove the managed host from the VMM server and also delete any residual certificates from the host on the VMM server, and then re-add the host:
More Information:
SCVMM uses BITS to transfer payload between SCVMM managed computers. These data transfers are encrypted by using a self-signed certificate generated at the time a host machine is added to VMM. If these certificates are missing or corrupted from the VMM server or managed computers, the payload deployment job can fail. Deleting the certificates and re-adding the host will cause the certificates to regenerate.
This same information is documented in our Knowledge base at http://support.microsoft.com/kb/971264.
Have you ever tried managing a Windows Server 2008 R2 Hyper-V host using System Center Virtual Machine Manager 2008 (the RTM version, not the R2 version) but kept running into issues that prevented it from working properly? If so then today's tip is for you:
The original version of VMM 2008 doesn’t support managing Windows Server 2008 R2 Hyper-V hosts. To manage Windows Server 2008 R2 Hyper-V hosts, you'll need to upgrade to System Center Virtual Machine Manager 2008 R2.
To make it even more official, the following TechNet site has been updated to state that managing Hyper-V R2 hosts requires VMM 2008 R2: http://technet.microsoft.com/en-us/library/cc764213.aspx.
Here's another one that's not necessarily SCVMM specific but should come in handy if you ever have to debug any of your Hyper-V VMs:
Hyper-V(tm) VM State to Memory Dump Converter (vm2dmp) is a command-line tool that converts the saved state of a Hyper-V virtual machine to a full memory dump file compatible with Debugging Tools for Windows. You can use this tool to convert the memory contents of a virtual machine at a point of time to a full memory dump file. The vm2dmp tool makes it easier to debug hard problems when they occur on virtual machines. Using this tool, developers can save time by avoiding the need to create a dump file over a slow debugger connection or from the operating system running inside the virtual machine.
For all the details and to download the tool see http://code.msdn.microsoft.com/vm2dmp
You may find yourself in the position of needing to move the SCVMM database from one server to another for various reasons. For instance, this situation can occur when moving from local to remote SQL or from a stand-alone SQL server to a SQL cluster. The following instructions are provided as a guideline on how to accomplish this move from a SCVMM perspective.
Important! It is strongly encouraged that before undertaking this process that a complete backup of the SCVMM database is captured.
There are two methods to accomplish the task of backing up and moving the SQL database. You can use either SQL Server Management Studio or the built in scvmmrecover.exe tool built into SCVMM.
Method #1 -- Using SQL Server Management Studio
How to move SCVMM database to another server (local to remote SQL)
1. Take a backup of the existing VMM DB
2. Uninstall VMM with the Retain Data option
3. On the remote SQL server, import VMM db
4. Install VMM pointing at the new SQL server and using the imported VMM db
5. If any managed host has the status of Access Denied, right click and select Reassociate
Method #2 -- Using the scvmmrecover.exe tool
The scvmmrecover.exe tool is discussed in great detail at the following TechNet article: http://technet.microsoft.com/en-us/library/cc956045.aspx
More Information
How to: Attach a Database (SQL Server Management Studio)
How to: Attach a Database File to SQL Server Express
SCVMM R2 operations Guide
Mike Briggs | Senior Support Escalation Engineer