The assessment of your environment should also include software applications in addition to hardware. You should do a complete inventory of applications running on your servers that you plan to virtualize so that you can ensure there will be no support or licensing issues when running them on virtual servers. You do not want to find out after you are done with your project that the application vendor will not provide support to you because the project is running on a virtual server. In addition, there might be special licensing considerations or configuration changes that need to be made to an application that has been virtualized:
Support issues. One of the first steps that you should complete when considering virtualization is to determine whether the applications you use are supported by the vendor in a virtualization environment. Almost all applications will run properly on virtual servers, but you will find that vendors typically have varying levels of support for virtual servers. The levels you will see will include the following:
Complete support for it. The vendor has certified their application to run on virtual servers and will support it without question. You will find most major applications will fall into this category, with a few notable exceptions, such as Microsoft.
Best effort support. The vendor will make an effort to support their application on a virtual server but may ask you to reproduce the problem on a physical server if they determine that the virtual environment is at fault. Microsoft falls into this category; if you have premier-level support with them, they will make more of an effort to help you.
No support. The vendor will provide no support for their application in a virtual environment. Typically, this is either because of known issues when running the application on a virtual server or that the vendor has not yet tested their product on virtual servers. If this is the case, you need to decide whether you want to risk virtualizing the application. If you do, plan for the times that you do need to contact support for help with problems (such as having a physical server available for reproducing the problem).
- Licensing issues. Some vendors have non-virtualization-friendly licensing models when you run their products on virtual servers; Oracle is a good example of this. Typically, they will still license based on the physical number of processors in the host server regardless of how many processors the VM has assigned to it. So for a VM running on a four-CPU host that has only a single virtual CPU, you may be required to license for four CPUs. Other vendors will change their models slightly for virtual servers. For example, IBM has a new processor value unit formula that makes licensing on virtual servers much more difficult to calculate compared to physical servers. Other vendors will license differently based on clusters of servers with pooled resources. If this is the case, you may need to create a smaller cluster just for the specific application to keep costs down. It's also common in virtual environments for a VM to not always be on the same host server because of features such as Distributed Resource Scheduler (DRS), HA, and VMotion. This can also cause headaches when licensing applications that are tied to specific hosts and hardware resources. It's best to contact all your software application vendors and find out their virtualization support policy in the early stages of your project. You might find that it may cost more to run their applications on virtual servers, but often the advantages that virtualization provides outweigh the increased costs.