Small business P2V migrations
When I hear “we only have 6 servers so our migration to VI should be quick and easy, right?” I hesitate. Not because it can’t be done, but because of how it should be done and the probable challenges. The expectation is usually that the physical servers should be virtualized as is. The reality is often that in order to achieve the best VI design the customer needs to separate applications and services.
A typical small office server infrastructure is usually similar to the following:
| Server 1 | Domain Controller, DNS, DHCP, WINS |
| Server 2 | Messaging, Backup Domain Controller, DNS, DHCP, WINS |
| Server 3 | Accounting, Finance, misc user and business applications |
| Server 4 | File Server, Database |
| Server 5 | Web, Intranet, FTP, DMZ applications or services, VPN or remote access |
| Server 6 | Antivirus, monitoring, misc administrator applications |
The exact placement of the different applications and services varies, but the result is the same. A small company P2V project really should be an infrastructure redesign project so that the features and benefits of VI can be fully leveraged. The following are my recommendations for the VI design of a small company like the example.
VI Hosts and storage
The goal should be to take advantage of as many enterprise VI features as possible. VMotion, DRS, and HA will all come in handy for any size company. To utilize all the features you need at least 2 hosts, a server for management, and shared storage. Shared storage does not have to be a SAN. Consider NFS storage.
If the current physical server hardware is relatively new then re-purpose it as the storage, for the management server, or even as a host if possible.
Consider the new small business blade centers as the ESX host and storage solution all in one chassis.
Domain Controller, DNS, DHCP, WINS
I usually do not try to P2V the domain controllers. Too much can go wrong and it’s just too easy to build one or two new a VMs as new DCs in the domain, allow time for replication, transfer the FSMO roles, and then dcpromo the physical server back to a member server. Then if there is still any other applications or services left on the box you can P2V what’s left.
Messaging
If it is just a messaging server than schedule some downtime and P2V. Else, dcpromo the DC and migrate any DNS, DHCP, or WINs to the new VM DCs. It also makes sense more times than not to build a new VM as a second messaging server and then migrate mailboxes. Decommission the messaging function on the physical box when complete.
User and Business Applications
These types of applications are the trickiest. An app by app analysis needs to occur, but the separation of most applications to their own new VMs is generally the best strategy. Sometimes you can’t because the migration is too difficult or maybe the person who wrote / configured the application is no longer around. Do what you can to separate the loads, but you can always shut everything down and P2V as is.
File Server and Database
These servers most likely will end up being direct P2Vs, but consider the opportunity to split multiple databases or cleanup and reorganize file shares. Robocopy, rsync, xcopy, etc file data to new VMs if possible.
Web Services, DMZ, and Remote Access
Typically a networking design needs to be carefully considered for these services. Can you isolate the DMZ on it’s own physical switch or at least VLAN? Spread out the remote access resources. Can you load balance web services between new VMs?
Administrator applications
Maybe migrate these apps to new VMs, or if your lucky you can eliminate some admin apps because similar functions are native to VI, but most likely these servers can be direct P2Vs also.
In summary, I tend to look for the opportunity to separate and migrate services from physical boxes to net new VMs before deciding to P2V. Not only for all the reasons mentioned above, but small company servers also tend to have operating systems that have mysterious issues. These issues may have occurred for various reasons, but regardless a fresh operating system and application installation does wonders for performance of both the VM and the VI.
Granted, more VMs means more licenses and infrastructure re-design means more implementation hours. This post is a best case scenario. Taking the time to find whatever ways to maximize the features of your VI design before you P2V will pay off in the long run.
Joe Foran over at SearchServerVirtualization.com blogs about a few servers that gave him trouble when he tried a couple different P2V tools. Although Joe’s post is not specifically about small company virtualization, he illustrates a lot of the concepts I have mentioned in this post. Check out Joe’s 2 part post:
P2V migration success, thanks to Robocopy and OEM + old machine + P2V migration = Murphy’s law.
Related Posts
Tags: backup, esx, hp, ibm, P2V, partner, planning, replication, SAN, vmware converter, windows
March 17th, 2008 at 6:46 am
[...] Small business P2V migrations [...]
April 9th, 2008 at 6:59 am
[...] Anyone who has already done it can tell you it involves much more than servers and hardware. Even for small companies, virtualizing servers potentially (and usually) involves networking, storag…. In fact, it is often as involved and complex as moving your physical servers from one data center [...]
August 12th, 2008 at 1:05 pm
I have a p2v nt 4.0 license server and need to change the Mac address of the VM nic. I have tried editing the vmx file as suggested on VM’s site but ikeep getting invalid mac range