THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

The Rambling DBA: Jonathan Kehayias

The random ramblings and rantings of frazzled SQL Server DBA

Don’t just P2V that server for Testing!

If you use virtualization in your company, at some point in time you might be tempted to perform a Physical-To-Virtual conversion, also known as P2V.  The ability to create a complete working copy of a physical server as a virtual machine is really useful for migrating to a virtualized datacenter, but it can also wreak havoc in your environment if you use it to generate a copy of a server for testing and the only change you make is the name of the server. 

The Problem:

Consider that you have a multi-purpose server running SQL Server, IIS, and an Application, lets call this ServerA.  To test a new Service Pack or release of the application you decide to P2V ServerA to VM-ServerA-Test, and you change the FQDN.  In the past ServerA was a stand alone solution, so the expectation is usually that VM-ServerA-Test is now its own stand alone solution for testing the upgrade, but its not.  The applications on VM-ServerA-Test are configured to use the SQL Server named ServerA, so any changes made on the P2V copy of the server actually happen against the production database.


Beyond the obvious “Don’t Do that”, there are a couple of solutions that can be done to prevent this from actually being a problem.  The first and most obvious one if you know that you are going to have a problem is to change the application configuration so that it talks to the new server name, making it once again a stand alone solution.  At the same time, you should probably also tell SQL Server that its name changed using sp_dropserver and sp_addserver since it still thinks its the old server (  Another solution is to bring the server up on a segregated vLAN that doesn’t have routes to the production environment.

Published Tuesday, April 20, 2010 11:58 PM by Jonathan Kehayias



roman said:

You can also create a SQL Server alias on the VM-ServerA-Test and redirect any calls going to ServerA to itself. Sometimes I create aliases pointing to non-existing servers, just to see what fails, good way to catch what we missed.

April 20, 2010 11:10 PM

doubleoh0 said:

I have a mirror of production in vmware. I've copied sql, mail, dns, etc servers and keep them on a separate vlan. If you've got the disk space it gives you a more realistic test env w/o dealing with changes name, ip addresses, or proecting the innocent

April 20, 2010 11:25 PM

Jonathan Kehayias said:

You could also do a hosts file hack on the P2V system to shortcut DNS lookups, but those solutions start hiding things that are harder to troubleshoot if you haven't been taught to look for them.

April 20, 2010 11:28 PM

A Lockwood said:

There may also be a bug where all your VM DBs get flagged as sparse files. I've seen it and the link below dives into the details of how it (typically) happens and how to fix it.

Full disclosure: There's a chance we were testing NetBackup on these dev boxes prior to the P2V and that may have caused the issue. Can't be 100% sure though.

I'd also add that if you change the name of the server you'll need to modify or create a new SPN as well to keep Kerberos happy.

April 21, 2010 12:13 AM
Anonymous comments are disabled

This Blog


Privacy Statement