Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Getting support for virtual migrations in a vendor-provided system

Learn how to convince vendors to allow virtual migrations in the vendor systems that your organization uses -- and keep the support agreement.

As virtualization is used by an increasing number of organizations, vendor- provided systems may become an area of concern if the vendor did not include provisions for virtualization in the initial support agreement. In this tip, I'll go through some strategies, exceptions, and cases for convincing vendors to make provisions for virtual migrations or implementations.

What vendor systems are we talking about?

We all have vendor systems, but we may not know much about them. These systems can include specialized environments that run custom software that has a proprietary database, special connectivity, or otherwise do something that has historically been best suited on its own server. One frequent way these systems are introduced to the environment is by decisions that involve underlying technology, but aren't made while considering the underlying technology. Take a modern distribution center for any of your major retailers. These are very technologically advanced facilities with many systems, yet the distribution centers are generally designed and funded by process engineers or industrial engineers.

Vendor systems can also be systems that provide call recording, multimedia services, or serve an external connectivity role. Regardless of why or how vendor systems arrived in your data center's architecture, it's time to identify if a virtualized environment is the right place for these systems.

Establish a proof of concept and contingency

Many different parties may have reservations about placing a critical system in a virtualized environment. The best way to address these concerns is to test a virtual machine performing the specialized system role and compare it to a physical machine while measuring performance metrics. It is common practice for vendors to do lab builds and develop in virtual environments.

Having the vendor's build process use virtualization can save steps in the overall process. Migration technologies can be used in tests against virtual and physical equivalents of the vendor system. Another option is to engage professional services to determine if the system is a candidate for virtualization. A leading example is VMware's Capacity Planner service. In determining if a system is a virtualization candidate, this service will create a timeline driven analysis of a physical system. Having VMware approve that the vendor systems would be good virtualization candidates will give both your company and the vendor assurance that the decision to migrate with virtualization is worthwhile.

You should also be familiar with contingency plans. Should you have a critical vendor system that is virtualized, and at a later it is determined that there is a need to migrate it to a physical system for performance reasons, have the tools and procedures ready. For Microsoft Windows systems, one approach is to be able to perform a virtual-to-physical migration. Using a migration technology like this would incur some changes to the environment after the conversion, but these are usually minimal. Tools such as PlateSpin PowerConvert and Symantec BackupExec System Recovery perform both virtual-to-physical and physical-to-virtual migrations.

Your approach as the customer

The first step is to determine how much of an investment you have in the system -- not a financial investment, but more of a situational investment. Questions you can ask to determine the investment in the vendor system include:

  • Do you perform support for the system?
  • Does the system reside in your data center?
  • Does the system reside on your network?
  • Does the hardware give you grief?

When you answer yes to these questions, you are defining your stake in the vendor system. You have the right to determine the placement of the vendor system within your environment.

Having a vendor system integrated within your virtualization environment also provides you with greater visibility to any issues that would arise with the installation. For example, if the processor utilization or memory usage is higher than normal, you would notice it first in a virtual environment. This could provide you advance warning of a functional issue that could impact your business from the intended purpose of the system.

Be sure to ask your vendor about their experiences running similar systems within a virtual environment. You are not likely to be not the first to inquire, and you should be aware of any issues that other customers may have experienced. More importantly, you can get your expectations in line with what the vendor is reporting from other installations. If you happen to be the trailblazer, take the proof of concept approach with a physical system as a fail back option.

Do not overlook supportability. Ensure that the virtual instance of your vendor system is a supported configuration. While you may technically be able to port your vendor system to a virtualized environment, if you void a support agreement or otherwise compromise vendor support, you have taken a big step backwards. Should your vendor not support virtualized environments, ask why.

Use disaster recovery planning to your advantage

A decision that enhances a disaster recovery plan is a positive step. Virtual systems can enhance a vendor system by being integrated into your standard disaster recovery parameters. This is good because you can support the disaster recovery internally, which will provide these other important benefits:

  1. Familiarity with the process. If the vendor system is migrated (or initially installed) to your virtual environment, you will have zero learning curve in how to apply your disaster recovery requirements.
  2. Lowered support costs. If you were to ask the vendor to make the solution adhere to the same availability requirements, the cost of the system would increase. The vendor system's interpretation of the availability requirements may include additional hardware, software, and remote support services to adhere to the availability parameters that are provided by your virtual environment.
  3. Quality system. With virtualized environments, it is much easier to make another instance of the vendor system designated as a quality system (or development environment) with virtualization tools. This separate instance of the vendor system can be used to test upgrades, core functionality changes, or business rule changes.

Upgrading existing systems

Eventually, it will come time to upgrade your system due to obsolete hardware or a dated operating system. Most vendors will provide services sometimes called a modernization, platform refresh, platform migration or upgrade. This may include large or small upgrades to the core functionality, and usually incurs operating system, database, or other third party title version upgrades. This is a prime opportunity to migrate to a virtual environment. The scope of the upgrade process varies widely for varied systems, but the key is to have IT staff involved with the entire process so that placement in the virtualized environment is the plan from the start.

Exceptions and when you have to object

Every system is not an ideal virtualization candidate. Vendor systems that provide specialized connectivity via non-standard input/output modules, serial connectivity, or interfaces to non-computer equipment over a proprietary interface may be a dead stop in putting that specific system in a virtual environment. While certain connectivity can be converted to Ethernet-driven options, this should be proceeded upon cautiously. In situations where existing connectivity is direct attached, converting it to Ethernet will increase the response time of the devices involved. One popular example is Ethernet-attached serial ports. These are very convenient as they can reduce cabling and allow you to relocate computer resources, but the increased response time and reliability of the device needs to be assessed.

Another example is in the automation arena for connectivity to control devices, such as a programmable logic controller (PLC). PLC connectivity for new installations is almost exclusively Ethernet, but there are many modules installed that may inhibit virtualization. You can change your connectivity from the various interfaces to Ethernet, but there will be (possible substantial) costs involved. Adding communications modules, code changes, and changes on the vendor application to change the connectivity to use different media require effort, and there are associated costs. But that is simply one factor in your decision to advance your solution to a modern, supportable platform.

A lot of factors determine if and how you implement a virtualized vendor system. But, begin with the end in mind of putting yourself in a better support situation and meeting your disaster recovery requirements. Then determine where you want to go and what defines the parameters of your systems.

About the author: Rick Vanover is an MCSA-certified system administrator for Belron US in Columbus, Ohio. Previous roles included software engineering roles with Siemens and Dematic in Grand Rapids, Michigan, working with complex supply chain execution systems. Rick has been working information technology for over 10 years and virtualization technologies for over seven years and has been publishing articles online for over six years.

Dig Deeper on Virtualization vendor comparisons

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.