cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Converting Physical Database Servers to Virtual Machines

Level 11

I’m in the middle of tough project right now, a large client is trying to convert a large number of physical SQL Servers to virtual machines. They’ve done most of the right things—the underlying infrastructure is really strong, the storage is more than an adequate, and they aren’t overprovisioning the virtual environment.

Where the challenge is coming in is how to convert from physical to virtual. The classical approach, is to build new database VMs, restore backups from the physical to the VM, and ship log files until cutover time. However, in this case there are some application level challenges preventing that approach (mainly heavily customized application tier software). Even so, my preferred method here is to virtualize the system drives, and then restoring the databases using database restore operations.

This ensures the consistency of the databases, and rules out any corruption. Traditional P2V products have challenges around handling the rate of change in databases—many people think read only database workloads don’t generate many writes, but remember you are still writing to a cache, and frequently using temp space. What challenges have you seen in converting from virtual to physical?

34 Comments
Level 17

I have experienced absolutely NONE! But this is only because I have never converted from Virtual to Physical, nor vise-versa.

Level 11

This article is about two months too soon for me.  We have a project on the horizon to move our virtual DB to a physical server.  I am a little nervous but the DB team assures me that it will go fine. 

Level 17

And the reason I am bookmarking this one... if I could categorize it would be, 'Insight I will need later'

Level 11

Database moves, are relatively easy--just backup and set up some form of log shipping, and then cutover at cutover time. The complication here is that we can't rename the servers, which makes it a much dicier proposition.

Level 13

We haven't seen much here. I guess the biggest challenge is getting the resource allocation right.

Level 12

not much here on our DB's going virtual will have to book mark this though to see where it goes im sure we are going to do it soon just haven't seen it yet.

Level 11

Been a looonng time since I've had to mess with servers. Thank god for that!

Level 11

Your plan is sound.  I think you will find the experience of migration quite straight forward, and the benefits of virtualization are numerous.

Level 14

I assume you mean challenges from physical to virtual.  I have seen issues when trying to virtualize machines with really old applications (like some serial applications).

Level 11

I've run into that challenge before--an application I used to support in a former role was dependent on a serial key. The vendor eventually came out with a software based key. To answer some of the questions around resource allocation--a couple of things are key. In database servers, you nearly always want a memory reservation (this is a VMWare thing, Hyper-V doesn't allow memory allocation) to ensure that your VMs aren't having memory taken away from them. The other thing to consider is storage, given the shared nature of VMs (and the way IO is performed by the VM) more IOPs are required than you might need in a physical environment. VMs and SSDs are a very good combination.

Level 15

P2V challenges for a database are generally the same as any other server in my experience. Back end hardware requirements + actual transition (down time). I think that I have seen more problems providing the proper storage/CPU/memory specs than I have convincing a client that XX amount of outage would be required. But I could see the issue in some of the heavy SLA/99.999% type shops. I would be interested to see how they handle the challenge.

Level 10

I'm not seeing any flaws in this process. Have you ran a test in your environment i.e. Dry Run to see if this is a viable solution for your migration? I would recommend trying a few flavors of your migration process to see what best suites your ecosystem. I have found that sometimes just because it makes since doesn't mean that it will work out. 

Also if you run into hiccups document, document, document any issues or anomalies.

MVP
MVP

I have always been wary of these P2V claims and have yet to feel truly comfortable that they will catch everything

Level 10

I'll be sure to pass this along to my DB friends. Good article.

Level 12

We've had a lot of success with our previous P2V conversions... but we never tried with DB severs.

Level 13

If you are talking about MS SQL, there's a procedure to rename a server (unless it's an Express version).

Level 11

The P2V solutions tend to work really well, as long as a) you can deal with a decent amount of downtime (meaning the database services are stopped) or you can deal with a server rename. SQL Server and Oracle both deal with this. At one of my previous jobs we had a private cloud environment, where a VM of SQL Server was cloned and renamed, and it worked swimmingly.

Level 10

Put all Physical Servers on just a few Boxes, sounds good but Bottlenecks on I/O are a headache, especially with High Demand Applications like Orion or a CUCM.

Dedicated hardware with dedicated instances on Shared Boxes probably works better

Level 8

we have had mixed results with doing P2V operations without shutting down SQL. I agree with Joey, if you are going to do P2V, shutdown SQL

Level 8


We just finished a project on data center consolidation by closing a datacenter, We had 90% of physical server and at the end of project we now have just 3 Physical servers(may be <5%). As a sole DBA, need face lot of challenges and we had a mix on using VMware P2V process & CommVault Backup(Physical) & Restore(Virtual) process (where we can also right sized the resources disks/CPU/RAM).

Yes backup and restore databases with a downtime based on size is a cleaner option. Databases server right sizing is a important factor on converting Physical to Virtual specially on CPU/RAM..
I can share my experience on specifics if you have any.

gud luck

MVP
MVP

p2v of a mssql server is terrifying. this might be a good time to build a new VM from scratch, size it correctly, and migrate your database using the built-in migration tools in MSSQL Server Management Studio. Depending on the size of your database, this might be faster than restoring from tape. That's doubly true if you've got fast connectivity between the physical and virtual servers.

Level 11

Micheal--Agree completely, that is the approach I normally take (well close--I just use backup and restore, and transaction log shipping), in this case there extenuating circumstances preventing that approach.

Right sizing is very important as over allocation of vCPUs will definitely result in a performance penalty.    

Level 9

Im glad that we have a server team to handle the physical to virtual challenge.

Level 9

Have you looked into using a tool like Disk2VHD Tool ?

Level 11

I would be curious as to what challenges the applications would have on the databases themselves.  If needing acceptance testing ahead of time, I would certainly copy over backup files and restore from backups.  If time permits doing a hard cutover at some point, I would drop the databases and move them over and bring them online on the VM.  P2V of any sort would be the last resort.

Level 21

We have used all of the different methods you mention with varying degrees of success.  I agree that using the P2V tools is generally a last option.  Our method for any physical to virtual migration is normally to build a new VM and then migrate the data.  Many of these types of migrations that we have done also included moving to a newer OS and/or DB version.

I guess the question I would have would be around the application.  What specific problems does the heavily customized application introduce and how do they impact the database?  One way to do this would be a maintenance window where you put a moratorium on changes, do a full backup and restore of the database into the new system and then cut over.

Before any cut-overs are done I would restore a copy of the database and test it with a copy of the application to see how it works before you move the production workload.  By doing this you will also be able to get a good idea of how long the maintenance window will need to be.

Level 10

We just finished the P2V of 3 Database servers to VMWare.  I use the VMware standalone tool exclusively and have had much success with it.  The trick is using the synchronization feature within the tool.  Here is what we did to have 3 successful P2V SQL database conversions.

  • 2 days before conversion, run an initial P2V clone with the Final synchronization schedules for 3 days in advance.
  • Once the initial P2V clone is completed, you can right click on the Job and choose "Synchronize" to run synchronizations to the Virtual from the physical system.  These servers are 24x7 for us so our blackout windows was small (about 1 hour).  Keeping the system synchronized allowed us to have a small window.  We ran this about every 6 hours to keep a fresh copy on the Virtual.
  • Once our Blackout window appeared, we turned off SQL Services and then ran the final synchronization.  This way, there were no changes to the databases while the copy was being made.  This also freed up resources for the P2V to run.
  • Once the synchronization was completed, we Manually powered off the Physical server and configured the Virtual server (had to set up the Networking due to a new network adapter).

This was very successful for us.

Level 8

interesting... did the sync process slow down production at all?

Level 10

We saw no effect on production while the P2V processes where running.  However, the P2V process did take longer during the day when the servers are being more utilized than at night.

Level 9

We encountered significant problems when attempting to P2V database servers.  We use VMware and have a host of MS SQL and Oracle databases.  The major issues we encountered with P2V were the problems with booting Windows after the P2V (usually driver freak-out problems) and LUN mappings.  After about 5 failed attempts with some of our bigger databases, we switched to a different method.

Our usual process was to stand up a new Virtual Machine and backup/copy/restore the data.  While a bit slower because of the additional backup and restore time (copy time was pretty close to the P2V time, and the new VM was built while still using the physical hardware), we had the opportunity to upgrade the Operating System and/or the database software during this process.  We actually performed a cutover from the old server to the new server; that is, we swapped the names and IP addresses of the old and new servers. Thus, we did not have modify the applications that are using the database.

An additional catch-point we encountered was that the VMs needed to be configured with a second NIC.  Sure the VM infrastructure provides network redundancy, but having only one NIC on a VM still incurs the potential for bandwidth saturation.  We encountered this quickly as the backups began to run.  To solve this, we added a second NIC to each VM database server, put the NIC on its own non-routeable network for backup traffic and adjusted the routing tables in the OS so only the backup server could be accessed through that second NIC.  After that, we no longer had bandwidth saturation on the main interface when backups ran.

Level 13

I like Aaron's post above.

It used to be (5 years ago?) the recommended procedure for virtualizing DB servers was simply don't do it. The rationale was that no amount of hardware, RAM and disk could compete with a properly configured standalone database server with local RAID10, etc.

I did it once long ago with SolarWinds. It was a terrible mistake, because I am not a DBA, and I could not really characterize the performance needed. As Aaron noted, you need to look at worst case - probably for each bottleneck.

You didn't mention what platform you are hosting on. I think we're all assuming vmware. Hopefully, you've looked at things like:

http://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf

There's a book available:

http://longwhiteclouds.com/2014/07/08/virtualizing-sql-server-with-vmware-doing-it-right/

You have a bunch of fans watching this thread now, hoping to hear if the hero vanquishes the evil.

=Seymour=

Level 9

Resources and licensing has been our issue in the past.

Level 15

I have done a number of these conversions in former lives.  We were moving to VSphere and I used VMWare's coldclone application to make the conversion.  Of course, this meant the server had to have scheduled downtime but it caused us no issues making the clone and spinning it up in the VSphere environment.  All the post configuration needed was to set the IP address and reconfigure the bonded NICs.

Good discussion.

Level 13

The biggest problems I've seen are not so much in being able to P2V the environment - most of the time I can shut down the DB for the conversion so that's not an issue.  I've seen a ton of issues where the DB is contending for resources in the cluster and you get a lot of weird latency issues.  Almost all the VM environments I've seen really end up being undersized due to VM sprawl.  Old instances not shut down or cleaned up, over allocation, not well tuned, etc etc.