Just a quick FYI on a new SCVMM 2008 R2 Knowledge Base article we published today:
=====
Symptoms
You are using Hyper-V and a Failover Cluster and your Virtual Machines (VMs) share the same Clustered LUN to hold the VHD for the VMs. You are also using System Center Virtual Machine Manager 2008 R2 (SCVMM) to manage your environment. If you delete a VM that resides on a LUN which is shared with another VM, the other VM may fail.
Cause
When SCVMM deletes the selected VM, it also frees up the Clustered LUN and returns it to the "Available Storage" Group. The remaining VMs on this LUN lose their dependency. In a cluster Trace you will see the following entries during the delete of a VM: 00000952 30.59181404 [2960] 0B90.0F1C::06/22-15:39:56.848#04:WsmanAPIWrapper.cs(1415): WSMAN: URL: [http://hypervhost1.contoso.com:80] Verb: [INVOKE], method: [GetGroupType], resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/mscluster/MSCluster_ResourceGroup?Name=Available Storage] 00000953 30.59195137 [2960] 0B90.0F1C::06/22-15:39:56.848#04:WsmanAPIWrapper.cs(544): HostSessionCache: elements for [S-1-5-18-hypervhost1.contoso.com]: [100] 00000954 30.60273933 [2960] 0B90.0F1C::06/22-15:39:56.859#04:WsmanAPIWrapper.cs(1415): WSMAN: URL: [http://hypervhost1.contoso.com:80] Verb: [INVOKE], method: [MoveToNewGroup], resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/mscluster/MSCluster_Resource?Name=Classic Shared 50Gb]
Resolution
This is by design. System Center Virtual Machine Manager was not designed to allow management of this shared configuration. Sharing a LUN across multiple Virtual Machines is an unsupported configuration and may lead to undesirable effects.
More Information
This problem does not occur if you are using Clustered Shared Volumes (CSV). This issue only affects System Center Virtual Machine Manager 2008 R2.
For the latest version of this article see the following:
KB2423004 - Using System Center Virtual Machine Manager 2008 R2 to delete a VM on a shared LUN causes the other VMs to fail
J.C. Hornbeck | System Center Knowledge Engineer
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis
This release of the Virtual Machine Servicing Tool (VMST) 3.0 completely replaces the Offline Virtual Machine Servicing Tool version 2.1.
VMST 3.0 helps customers reduce IT costs by making it easier to update their offline virtual machines, templates, and virtual hard disks with the latest operating system and application patches—without introducing vulnerabilities into their IT infrastructure.
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.
For all the details and to download the Virtual Machine Servicing Tool (VMST) 3.0 click here.
Our very own Jonathan Jordan just posted some great info on creating templates for use with VM creation:
Templates save time! Templates make multiple custom deployments easy! Learn to use Templates!
So, essentially I have marked up two great TechNet articles on creating virtual machines from templates. This sounds a bit backwards, but these articles provide all the information needed to Create A Template. I have pointed out important points and added comments where a newbie may easily go astray. Consider this a ‘Best Practices’ for simply creating a usable template. As you learn to master this process you may find yourself branching out into greater and greater customizations.
For all the details see Jonathan's blog post here.
If you have two Hyper-V failover clusters managed by System Center Virtual Machine Manager 2008 R2, it is possible that you can't complete a LAN migration of a Virtual Machine (VM) from one of the clusters to the other. This issue will only appear if ALL of the following conditions are met.
When the migration fails you will see the following error:
Error (12711) VMM cannot complete the WMI operation on server <serverName> because of error: [MSCluster_ResourceGroup.Name="2068e895-4930-42be-a4c8-152ab15a28b8"] The cluster group could not be found. (The cluster group could not be found (0x1395)) Recommended Action Resolve the issue and then try the operation again.
Currently there are two possible workarounds for this issue:
1. If the VM is in a saved state and not in a running state, at the beginning of the migration across the two clusters then this issue will not appear and everything completes successfully. Due to this, one resolution is to put the VM in a saved state first and then initiate the migration.
2. Use the Failover Cluster Manager User Interface to locate the Virtual Machine in "Services and Applications". Right click on the top resource group for this VM and change the Resource Name from "Virtual Machine <vmname>" to "SCVMM <vmname>". Now refresh this VM from VMM using the "refresh-vm -force '<vmname>'" cmdlet. Migrating the VM from one cluster to another should now complete successfully.
If you are already in a situation where your VM migration failed (the virtual machine should be in a migration failed state) there is only one way to get your VM in a healthy state and that is by following the steps below:
1. Take a full database backup of the DB used by VMM (Just in case; this is a safety net in case something goes wrong)
2. Use the instructions in the following blog post to save any metadata applied to the VMs in your cluster. http://blogs.technet.com/b/m2/archive/2010/04/16/saving-and-re-applying-the-virtual-machine-metadata-in-vmm.aspx
3. Remove the source cluster from management. Here we assume that the Migration Failed VM is part of this source cluster (i.e. the cluster that contains the host that had the VM in the first place before the migration was initiated)
4. Re-add the source cluster into SCVMM management. The VM in question should now be in a healthy state and running. Verify your VM is working properly in the source cluster. This is a very important step.
5. Go to the destination cluster (the cluster that contains the host you want to move the VM to) and cleanup the service that maps to this VM. You might also have to go to the destination hyper-v host and delete that VM that was created as a placeholder. This is a very important step. You need to ensure you are deleting the VM from the destination cluster [the VM should be working properly in the source cluster - DO NOT touch that]
6. Re-apply any metadata to the VMs of your source cluster after it was re-added into management by SCVMM. The blog post referenced above explains how to do that.
7. Refresh the source and destination clusters.
8. Refresh the Virtual Machine that is going to be migrated.
9. Start the migration of the VM from the source cluster to the destination cluster.
For the latest version of the article see the link below:
KB2417319 - Migrating a System Center Virtual Machine Manager 2008 VM from one cluster to another fails with error 12711
System Center Virtual Machine Manager 2008 (SCVMM) uses BITS (Background Intelligent Transfer Service) to transfer content between the SCVMM Server, the Library Server(s) and the Virtualization Hosts. If there is a service on one of the involved servers that is using the HTTPS port 443, the transfer may be extremely slow or even fail with the following error:
Error (12700) <path to vhd on destination host> 'The file or directory is corrupted and unreadable' (0x80070570)
This occurs because BITS uses a default port of 443 (decimal) and this port is also used for HTTPS.
To resolve this issue, configure SCVMM to use another port for BITS transfers between its Library Server(s) and the Virtualization Hosts.
Note: You need to ensure that the newly selected port is not blocked by a Firewall between the involved hosts.
1. On your VMM Server open the Registry 2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings 3. Locate BITSTcpPort which should have a value of decimal 443. Change this to some port unused in your environment. (e.g. 8500) 4. Restart Virtual Machine Manager Service so that the change takes effect.
For all the details and the latest version of this new Knowledge Base article please see the following:
KB2405062 - Transfers between the System Center Virtual Machine Manager server, the Library Server and the Virtualization Hosts may fail with Error 12700
Just a quick note that we recently published a new Knowledge Base article documenting the recommended hotfixes for System Center Virtual Machine Manager 208 R2. I won't list all the hotfixes here but you can access the new KB at the link below:
KB2397711 - Recommended hotfixes for System Center Virtual Machine Manager 2008 R2
Attempting to login to the System Center Virtual Machine Manager 2008 (SCVMM) self-service portal may fail with the following error message in the browser:
Could not load file or assembly ‘TraceWrapper, Version=1 .0.523.0, Culture=neutral, PubhcKeyToken=31bf3856ad364e35’ or one of its dependencies. An attempt was made to load a program with an incorrect format. Login again Contact administrator
This can occur if the application pool for SCVMM self-service portal is configured with Allow 32-bit Applications set to “True” in the Advanced Settings.
By default on a 64-bit machine, the Application pool in IIS 7 has the Allow 32-bit Applications setting set to false, however in certain environments the application pool may have Allow 32-bit Applications configured as True. In these cases we will receive error message as stated above. To resolve this issue change the Allow 32-bit Applications setting to False from True. To do that perform the following steps:
For the latest version of this article please see the Knowledge Base article below:
KB2397656 - Attempting to login to the System Center Virtual Machine Manager 2008 self-service portal fails with "Could not load file or assembly"
Jonathan Jordan, one of our very own System Center Virtual Machine Manager engineers, posted another great tip over on his blog about how to fix Error 2912 issues. If you're running into this issue then he can help you get back on the right track:
A common problem during data transfers, especially toward the end of P2V jobs, is Error 2912, with some variation of 0x8007xxxx. This is generally certificate related. I’ve put together a complete set of steps that will correct certificate issues between the SCVMM Server and Hosts. Why do certificates matter? BITS uses them… and BITS is what transfers data…
Check out the rest of his article straight from the source here.
We've already talked about this issue earlier but we now have an official Knowledge Base article on it so I wanted to send out a heads up. Here are the details:
Migration of a virtual machine from one Microsoft Windows 2008 R2 Failover Cluster to another fails. Both Failover Clusters are managed by System Center Virtual Machine Manager 2008 R2 (SCVMM).
Error (12711) VMM cannot complete the WMI operation on server Contoso.LOCAL because of error: [MSCluster_ResourceGroup.Name="2068e895-4930-42be-a4c8-152ab15a28b8"] The cluster group could not be found. (The cluster group could not be found (0x1395)) Recommended Action Resolve the issue and then try the operation again.
Error (12711) VMM cannot complete the WMI operation on server Contoso.LOCAL because of error: [MSCluster_ResourceGroup.Name="2068e895-4930-42be-a4c8-152ab15a28b8"] The cluster group could not be found.
(The cluster group could not be found (0x1395))
Recommended Action Resolve the issue and then try the operation again.
SCVMM 2008 R2 attempts to execute an operation on the source host (of the source cluster) using the resources names and GUIDS of the destination cluster. Migration will always fail right after the BITS migration when the virtual machine is placed in a saved state.
This issue can only be reproduced under these conditions:
There are two different workarounds for this issue.
1. Perform the migration when the virtual machine is in a saved state or powered down.
2. Use the Failover Cluster Manager User Interface to locate the virtual machine in "Services and Applications". Right click the top resource group for this virtual machine and change the Resource Name from "Virtual Machine <vmname>" to "SCVMM <vmname>". Then refresh the virtual machine in SCVMM PowerShell using the "refresh-vm -force '<vmname>'" cmdlet. The virtual machine can now be migrated while in a running state.
You can find the latest version of the article here:
KB2397370 - A System Center Virtual Machine Manager 2008 R2 virtual machine migrated between Failover Clusters fails with Error 12711
Here's a great post our very own Michael Michael posted today that talks about an issue you may run into when using System Center Virtual Machine Manager 2008 trying to migrate a virtual machine from one cluster to another:
If you have two Hyper-V failover clusters managed by VMM 2008 R2, it is possible that you can't migrate over the network (LAN migration) a VM from one of the clusters to the other cluster. This issue will only appear if ALL of the following conditions are met.
· VM is created using Hyper-V (i.e. the VM was not created through the VMM Administrator Console)
· VM is made into an HA VM using the FOC GUI (resource name will be called something like “Virtual Machine <vmname>”)
· VM is in a running state
· VM is migrated to a different cluster. VMM will chose QSM (Quick Storage Migration) network migration (LAN migration) in this case
· The migration job will always fail with the error below.
<<
Error (12711)
VMM cannot complete the WMI operation on server blre3r02-24a.DOM202594.LOCAL because of error: [MSCluster_ResourceGroup.Name="2068e895-4930-42be-a4c8-152ab15a28b8"] The cluster group could not be found.
Recommended Action
Resolve the issue and then try the operation again.
For all the details including his suggested workaround see the following link:
http://blogs.technet.com/b/m2/archive/2010/09/01/issues-with-migrating-a-virtual-machine-from-one-cluster-to-another.aspx