P2V a SQL Server?
This week, I again had the opportunity to be on the
Virtumania podcast with Rich Brambley, Marc Farley and a special SQL server guest, http://www.brentozar.com/ Brent Ozar. One of the points we discussed in episode 9 regarding SQL servers and virtualization was the challenge of performing a physical-to-virtual (P2V) conversion of a database server.
There are many ways to address the P2V task for a SQL database server, and Brent shared one trick that, while so incredibly simple, can really save a lot of time related to the conversion time requirements. His recommendation was to implement SQL-specific technologies such as replication, mirroring or log shipping of the source database server to the new virtual machine build. Brilliant!
For P2V of a SQL server, my practice has been to convert the system drive (C:\) of the source system and utilize one of two recovery strategies. The first is to create the data volume of the SQL server on the destination virtual machine initially empty, then restore a SQL backup onto the new, empty system. While you can convert the SQL database server's data volumes with the SQL Server service stopped, it is usually cleaner to have an absolutely consistent database on the virtual machine. This can be done by restoring from a SQL backup or an agent-based backup if you are using a tool that does this type of protection.
I came across one situation where the SQL data was on an iSCSI volume, and that made for a very straightforward P2V conversion, as the guest virtual machine retained the iSCSI initiator configuration in the virtual machine. I am not yet a fan of having in-guest iSCSI initiator configurations, but in the case of a P2V, I made an exception.
Starting with a clean build of the operating system on the virtual machine is always cleaner than a P2V. That's a big plus for using Brent's recommendation. On the other hand, administrators don't always have all of the resources about an application or database to go through the clean build. Be sure to check out my advanced P2V flowchart for planning your P2V conversion task to avoid any surprises.
When it comes to migrating databases from physical systems to virtual machines, what strategies have you utilized? Share your comments here.
Posted by Rick Vanover on 04/27/2010 at 12:47 PM