Pitfalls to avoid with SCVMM 2008 P2V (error 2916)

Recently I’ve had to set up two Hyper-V hosts. As we are currently running a hodgepodge of VMWare products (mainly VMWare Server in various incarnations, including the disgusting version 2), we are looking for alternatives that are easier to manage. VMWare might be leading from a technical standpoint, but if you are used to proper service and operations management it’s easy to come away disappointed. Hence my foray into Microsoft’s virtualization territory. Read on for a few pointers into the various pitfalls I managed to fall into (and clamber out again).

First of all, every single problem I had had to do with the fact that all communication is SSL encrypted. Not once have I encountered a problem with a specific application or system to convert, nor with the conversion components themselves. So here goes, in order of discovery and severity:

  1. The misconfigured proxy settings
    When you are communicating via HTTPS, your web proxy settings might be taken into account. If you have a proxy configured, make sure it avoids the proxy for local addresses.

  2. The default P2VBITSTcpPort
    If any of the systems involved (be that the system to be virtualized, the SCVMM server or the receiving Hyper-V host) is running a web server, consider stopping it for conversion, or changing the BITS port used during P2V. The corresponding registry setting is (on the SCVMM server):

    HLKM\sotware\microsoft\microsoft system center virtual machine manager server\settings\P2VBITSTcpPort
    Use something like 30443 (anything not well-known) and restart your VMM service.

  3. The self service portal and the DNS alias
    This one took me half a day, but it’s fairly obvious: I configured a DNS alias for the self service portal, intending to install it on a separate host after I’m more familar with SCVMM. I also made a SSL certificate to match the DNS alias and installed it on the SCVMM server. That of course broke SSL communication with the Hyper-V servers during conversion (which still uses port 443 and does not expect a SSL certificate not matching the SCVMM host name). As a workaround I disable the IIS binding to 443 during conversion, and eventually moving the self service portal to another machine will solve the problem

Other than that, it has been smooth sailing so far. SCVMM is a great piece of software, and while a little unpolished when it comes to integrating ESX it’s  a lot better than what VMWare offers when integrated with the rest of System Center (an I'm fortunate enough to have most of them).