Last week I moved our SCVMM from 2012 with service pack 1 to 2012 R2. Whilst the actual process was much simpler than I expected, we had a pretty big constraint imposed upon us by Lab Manager that largely dictated our approach.
Our SCVMM 2012 deployment was running on an aging Dell server. It had a pair of large hard drives that were software mirrored by the OS an we were using NIC teaming in Server 2012 to improve network throughput. It wasn’t performing that well, however. Transfers from the VMM library hosted on the server to our VM hosts were limited by the speed of the ageing SATA connectors and incoming transfers were further slowed by the software mirroring. We also had issues where Lab manager would timeout jobs whilst SCVMM was still diligently working on them.
Our grand plan involves migrating our VM hosts to Server 2012 R2. That will give us better network transfers of VMs and allow generation 2 VMs on our production servers (also managed by SCVMM). To get there we needed to upgrade SCVMM, and to do that we had to upgrade our Team Foundation Server. Richard did the latter a little while ago, which triggered the process of SCVMM upgrade.
Our big problem was that Lab is connected extremely strongly to SCVMM. We discovered just how strongly when we moved the SCVMM 2012. If we changed the name of the SCVMM server we would have to disconnect Lab from SCVMM. That would mean throwing away all our environments and imported machines, and I’m not going through the pain of rebuilding all that lot ever again.
I desperately wanted to move SCVMM onto better tin – more RAM, more cores and, importantly, faster disks and hardware mirroring. That led to a migration process that involved the following steps:
- Install Server 2012 R2 on our new server. Configure storage to give an OS drive and a data drive for the SCVMM library.
- Install the SCVMM pre-requisites on the new server.
- Using robocopy, transfer the contents of the SCVMM library to the new server. This needed breaking into blocks as we use data deduplication, and our library share contents are about three times the size of the drive! We could repeat the robocopy script and it would transfer any updated files.
- Uninstall SCVMM 2012 from the old server, making sure to keep the database as we do so.
- Change the name of the old server, and it’s IP address.
- Change the name of the new server to that of the old one, and change the IP address.
- Install SCVMM 2012 R2 onto the new server.
Almost all of that worked perfectly. When installing SCVMM onto the new server I wanted to use an existing share for the library, sat on drive d: and called MSCVMMLibrary. Setup refused, saying that the server I was installing to already had a share of that name, but on drive c:. Very true – for various reasons the share was indeed on the c: drive, albeit with storage on a separate partition attached with a mount point.
What to do – I couldn’t remove the existing share as I didn’t have SCVMM installed. I didn’t want to roll back either, as the steps were painful enough to deter me. So I looked in the SCVMM database for the share.
Sure enough, there is a table in there that lists the paths for the library shares for each server (tbl\IL\LibraryShare). There was a row with the name of my SCVMM server and a c:\mscvmmlibrary path for the share. I changed the ‘c’ to a ‘d’ and reran setup. It worked like a charm.
Now, I would not recommend doing what I did, but in the Lab Manager scenario, removing and re-adding that share causes all kinds of trouble as the resources in the library are connected to lab environments. I haven’t had any problems post-upgrade, so it looks like I got away with it. Sadly, this is just another in a long list of issues with the way Lab Manager interacts with SCVMM.