So if you’ve kept up so far, you can see that virtualization is a major project, but extremely powerful and worthwhile.  You can realize some great benefits, and open up some additional functionalities that you would never have under the traditional “add another box” model.  The desktop versions give you a great starting point to learn about virtualization, and maybe test some new functions that are available in a safe, non-intrusive way, without the expense of building and maintaining a separate sandbox environment.

So now you’re at the next level.  You’ve decided that virtualization is a great fit, you’ve done the math proving the ROI, and you are ready to take your network to the next level.  What’s next?

The first question is, when is the best time to do a virtualization?  Here are some great guidelines:

• Find a time that your business is in a natural “lull” – not much is going on in the field or the office.  For construction companies, wintertime may be the best fit; for schools or education companies, summertime is better.  Christmastime is a great fit for many companies (or, for retail companies, the lull after the Christmas rush around the end of January).  The key point is to make sure that if things do go wrong (always plan on the worst case), you can reduce the financial impact on your business.

• Find a time that coincides with the natural rotation of your equipment. Typically this is around the three- to four-year mark.
• Make sure that your users can be without services for a while – during the migration process, it is preferable to keep users off the server.  From a business perspective, this usually means a weekend migration; if you choose this route, be prepared for overtime costs (time and a half or more for hourly employees or contractors, pizza and other “incentives” (bribes) for your team.  Some implementations will minimize downtime, but it’s always a good idea to plan for the worst.
• PLAN, PLAN, PLAN!!!! Planning is key in any major project.  Be sure to identify milestones to minimize the impact on the business, and give yourself some wiggle room – as with any major implementation, things can (and do) happen that will slow you down.  In a recent deployment, we found out when installing the new servers that the electrical system was old and underpowered, and not able to handle the load of the new equipment, requiring the services of a trained electrician.  The extra work delayed us, but because of proper planning, we were still on schedule, and met our client’s completion date.

The second question is, what should I virtualize?  The easy answer is, “Virtualize everything!” – that is not necessarily the correct one.  Here are some pointers on what servers you should (or should not) virtualize:

• File servers, print servers, and other non-critical servers – This is a no-brainer.  These servers are easy to virtualize, and don’t do much other than send out files or services to users.  Virtualization has a big win with this server type; a couple key strokes can add storage space to the server, and an errant file/system (or an infected file/system) can easily be restored.
• Domain controllers / Directory servers – Not as much of a “no-brainer” as you would think.  It’s always a good idea to virtualize a domain controller, as long as you have a domain controller on a standard server as well.  This practice makes sure that your users can still log into your computer, even if the VM server needs to be restarted for whatever reason.  The external server can be any old server (provided that the server still works and can run the OS), and generally only used as a domain controller and centralized management console, if applicable (VMWare’s vSphere console or Microsoft’s Virtual Machine Manager, for example).
• Application or database servers – It is highly recommended to virtualize application servers – the increased processing power alone makes the endeavor worthwhile.  However, check with your application’s vendor before virtualizing.  Some applications, especially those that rely on older technology, have issues with virtualization, and the vendor may not have approved the application for virtualization.
• Network services – Ask ten techs this question, and you will get eleven answers.   My opinion is to place critical network services (such as DHCP) on the external DC mentioned earlier; if the VM crashes, you will have easy access to the management tools of the host server without having to statically set your IP.  However, either configuration is fine.
• VoIP servers – Many business are exploring the wonderful world of Voice over IP, the next generation of telephony.  In a nutshell, VoIP uses the same network as your computer to make phone calls, using a VoIP server (instead of the traditional PBX system) to process calls.  I would heavily advise against virtualizing a VoIP server in a production environment:
  • Most VoIP servers use a telephony card to contact the outside world (read:  a modem card to plug the phone lines in).  It is technically possible to place this card in the host server, but if that card fails, you will need to bring down
  • If you have a pure VoIP provider (Vonage, for example), you don’t need a telephony card.  However, if your host server fails, you will not be able to call your customers and tell them you are having computer problems – ironically, because you’re having computer problems.
  • Having said that, I would recommend setting up a backup VM – if your phone server fails, you can easily move to the virtual server while the main server is being fixed.
  • Web servers – You can safely virtualize web servers, but you will need some additional configuration steps to ensure your Web server is safely in your network’s DMZ, rather than on the internal servers.

Stay tuned for the next entry, where I’ll go over the infrastructure that will be the best fit.