VMware

Many VMware customers are concerned about ever-increasing licensing costs, and are actively considering VMware alternatives. However, mitigating VMware migration risks is an even more significant concern. There are four steps that IT planners can take to ensure a seamless and risk-free migration to a new infrastructure platform:

1. Upfront Assessment
2. Virtual Proof of Concept
3. On-Premises Evaluation
4. Gradual Cut Over

Upfront Assessment of a VMware Alternative

Before diving deep into any IT project, you want to ensure the result will be significantly better than the current state. When considering a VMware alternative, reducing and simplifying licensing costs is one of the obvious areas to examine. Beyond licensing costs, IT should also evaluate long-term cost savings potential like:

• Simplifying day-to-day operations like patching.
• Extending the life of existing hardware and using it more efficiently.
• Eliminating the need for a dedicated storage array.

Additionally, moving to an alternative platform should deliver more than cost savings. IT planners should consider the move to a new platform as an opportunity to improve capabilities like:

• Improving data protection capabilities by moving beyond snapshots.
• Improving ransomware resiliency and detection with a hardened infrastructure platform.

Finally, before moving to the next step, you should talk to some existing customers and see what they have to say about the potential alternative. Get their feedback on how easy the product is to use, how well it’s supported, and learn about their day-to-day experiences. Current customers can prove vendor claims.

Virtual Proof of Concept of a VMware Alternative

Once IT completes its initial assessment, most vendors try to rush to a proof of concept (POC). POCs are the cornerstone of mitigating VMware migration risks, but the problem is that a POC requires IT to find some hardware or make space for the vendor’s hardware. It also means that IT must find the time to go through the testing process and have a strategy for performing that test.

An alternative is a virtual proof of concept, where the vendor creates a virtual environment for you to test drive their solution. However, this virtual environment must give you full reign to perform whatever type of testing you want. You should be able to do more than “just drive the GUI.” You should be able to load up your virtual machines (VMs), test data protection capabilities, and start to think through on-premises test plans.

Your virtual instance should be 100% isolated from any other virtual POCs. Otherwise, you can’t deploy your applications and data without the risk of another organization gaining access to them. If the vendor can only deliver that isolation by dedicating specific hardware for the test, they will likely have to limit the time you can test. If the vendor can deliver that isolation, then they should be able to provide a very flexible testing timeframe.

On-Premises Evaluation of a VMware Alternative

If the potential VMware alternative still interests you after completing the virtual proof of concept, it is then time to move to an on-premises evaluation of the solution. Most vendors are happy to provide an on-premises evaluation. Still, the IT planner must pay attention to the vendor’s behavior as you move through this process.

There are red flags that will appear, even before you start testing. These red flags should give you some insight into how well the solution is going to perform for you in the coming years:

🚩 Does the vendor require a multi-hour meeting to ensure all the technical requirements are met?
🚩 Does the vendor insist on providing you with hardware even though they say they are "software-only"?
🚩 Does the vendor want to come on-site to install the evaluation?
🚩 Does the vendor push you to do a "try-and-buy" where you commit to buying the solution if critical requirements are met?
🚩 Does the vendor insist you use the local technical resource for any technical questions that might arise?

An on-premises evaluation should be a strings-free relationship. You should be able to use existing hardware. It should only require a quick call, not a three-hour workshop, to ensure the hardware you plan to use is optimal for your testing. If the vendor claims to be software-only, then as long as you can provide hardware that meets their minimum requirements, you should be given the green light for your evaluation.

Usually, having a vendor come on-site to install an evaluation, or worse, providing you with a “turnkey” hardware package for the evaluation is a sign that the vendor is trying to hide how complex their solution is to get running. If it is hard to install, it will be hard to operate.

You are testing something new, and you will run into technical questions. You should go through regular technical support channels to get those questions answered. This process lets you see what kind of support you will get years after installation.

Gradual Cut-Over to the New Platform

Once you’ve completed the evaluation, you should map out a migration strategy before you commit to purchase. Mitigating VMware migration risks requires that the cut-over to the new platform is gradual. In most cases, you won’t flip a switch and, in a single pass, move all your VMs to the new platform. You typically migrate in “lumps,” one workload at a time. This more gradual process means the migration capabilities, if there are any, should be continuous. The new platform’s migration capabilities need to keep VMs from the VMware environment in sync so that the most recent copy of data is on the new platform when IT is ready to convert the next workload.

A near-continuous sync of VMware VMs to the new platform also means that it can provide enterprise-wide value from day one while you are gradually migrating to it. Suppose the migration function is near-continuous and intelligent enough only to move changed data blocks. In that case, it can act as a disaster recovery solution (DR) for the entire VMware environment. The result is from day one; it can save you money while you migrate at your pace. Without it, you are under too much pressure to show value from the new purchase quickly, making you more likely to rush VM migrations.

If the new platform achieves the efficiency mentioned in the initial assessment, IT should be able to carve off two or three physical servers to act as the initial foundation. Those initial servers should be able to receive all the migrated VMs and the continuous updates to them. Then, as you move VMs into production on the new platform, resources will free up in the VMware environment, enabling you to add a few more servers to the new platform.

A De-Risked VMware Migration

Selecting a vendor that is patient enough to walk through the above process de-risks the migration away from VMware. Each of these steps is essentially a checkpoint in the process, and you don’t move to the next step until you are confident in the results of the prior step.

Using existing hardware and providing value while you migrate are critical. If, during the evaluation process, you discover something you don’t like about the solution, you are not saddled with a bunch of hardware that you must de-install and return. And the ability to add value while you gradually migrate, in our example acting as a DR solution, puts less pressure on you to migrate too quickly.

The VergeIO Team is happy to guide you through this process, which is why we have such high customer satisfaction. The first step is to perform the upfront assessment—schedule yours now with one of our technical experts.

The performance impact of retention means that VMware snapshots have a high cost, which further means that IT professionals must compensate by investing more than they should into storage and backup infrastructure. Below are the best practices of VMware’s snapshot functionality, according to VMware’s knowledge base article:

1. Don’t Use Snapshots As Backups
2. While the maximum number of supported snapshots per virtual machine is 32, the best practice is not to use more than 2 or 3.
3. Don’t retain a snapshot for more than 72 hours.
4. Ensure that snapshots are deleted when using third-party backup software
5. Never increase the virtual machine disk size while there are active snapshots.

The weaknesses of VMware’s Snapshots are just one of the hidden costs of using VMware in the data center. To learn all four, watch our on-demand webinar, “The 4 Hidden Costs of VMware“.

VMware Snapshots Are Not Backups

VMware states the reason VMware snapshots should not be considered backups of virtual machines (VMs) is “The snapshot file is only a change log of the original virtual disk. It creates a placeholder disk, virtual_machine-00000x-delta.vmdk, to store data changes since the snapshot was created. If the base disks are deleted, the snapshot files are insufficient to restore a virtual machine.”

The need to track changes in a separate file means that every time new data is written to a VM’s primary volume, it leads to significant overhead and dependency on the original volume. The overhead limits customers’ ability to use VMware’s snapshot technology for backup because only two or three snapshots can be active at any point in time. The dependency is the final nail in the coffin. If the primary fails, then all of your snapshots become useless.

The Impact of VMware Snapshots Not Being Backups

Most customers would still choose a separate backup software solution even if VMware could provide unlimited snapshots without performance impact. The fact that VMware snapshots are so hindered forces customers to invest more heavily in a backup solution. The weakness of VMware’s data protection capabilities has led to the creation of companies like Veeam and fueled its growth.

Backup solutions are the only products that can extract any usefulness from VMware Snapshots. They can execute one VMware snapshot, mount it to their backup application, and back it up. Then when the backup completes, the software can delete the snapshot it took so it doesn’t impact overall performance. That same knowledge base article advises IT to make sure their backup software selection can delete the snapshots it takes. (Item 4 above)

The Cost of VMware Snapshots Not Being Backups

VMware’s deficient snapshot capability is not unique. Although not as severe, many dedicated storage systems have similar limitations on how frequently you can execute a snapshot and how long you can retain those snapshots. All of the legacy snapshot technologies are plagued with this problem. Each successive snapshot depends on the snapshot before it, and all snapshots depend on the original volume. If that original volume is removed, all the snapshots are invalidated.

One of the most important priorities for IT is to protect the digital assets that the organization creates and uses to make decisions. Since that priority is paramount, IT must work around the weakness in snapshot technology and invest in a separate process, backup, and recovery, to mitigate the risk.

The investment in the backup and recovery process is not insignificant. There is the cost of the backup software and the need for and cost of a separate storage system. There is also the cost of time to transfer that data from production storage to the secondary storage device. The transfer time means significant gaps in which data is unprotected, something ransomware uses to its advantage. Finally, there is also the time involved in transferring data back into production if something goes wrong with primary storage. There is a place for separate backup and recovery, but it should not be the primary means to protect and recover production data.

IT professionals largely ignore the cost impact of these limitations because they assume that there is no alternative.

The Clone Alternative to VMware Snapshots

As discussed in our previous article, “Snapshots or Clones for Data Protection”, a Clone, i.e., a complete copy of a virtual machine or volume, except for one limitation, is a much better means to protect data:

1. Clones are independent
2. Clones don’t impact performance
3. Clones can be retained indefinitely

A limitation of clones is that they are exact copies of the original, which means there is a transfer time problem and a capacity consumption issue. This limitation goes away, though, if, at an infrastructure level, global inline deduplication is integrated into the core code. Global inline deduplication enables the creation of copies of any virtual machine, or even the entire environment. The clones can be made near instantly, and they, initially, don’t consume any capacity.

The problem is that most deduplication technology is an afterthought, especially within hypervisor software. VMware introduced deduplication into vSAN years after the initial release, and Nutanix waited even longer. Adding deduplication as a bolt-on years after the initial introduction means that the algorithm adds processing overhead to the environment, dramatically impacting performance and decreasing virtual machine density.

To some extent, IT can work around the overhead of deduplication by buying more powerful servers and adding more RAM to those servers, all of which add significant costs to the infrastructure. Alternatively, IT can purchase a dedicated storage array. Still, as we explain in our article, “The High Cost of Dedicated Storage,”, that approach also increases the cost of the infrastructure.

IOclone: Eliminating Costs While Increasing Resiliency

VergeIO integrates deduplication into VergeOS, and it isn’t a bolt-on. Global Inline Deduplication has been at the core of VergeOS since day one. As a result, it operates very efficiently and with no performance impact compared to legacy solutions. This means creating a clone using VergeOS’ IOclone capability; it happens instantly with virtually no initial impact on capacity. Also, these clones are not dependent on the original copy. They are standalone and don’t impact performance, nor do they have retention limitations.

VergeOS’ Global Inline Deduplication is also WAN aware, so IT can replicate production data and clones to remote DR sites or other data centers using minimal bandwidth and time. Moving data to a second VergeOS instance meets the “one copy off-site” requirement common in most data protection strategies.

Thanks to VergeOS’ foundational implementation of global inline deduplication, IOclone merges the best of both snapshots and clones to deliver unprecedented data protection and resilience. It is also why we refer to them as snapshots within our GUI. It is another example of the benefits of solving problems holistically at the infrastructure level instead of myopically at the data level. Watch our on-demand webinar, “Creating a Holistic Ransomware Response,” to see another example of solving problems at an infrastructure level.

While some VergeIO customers have eliminated backup as a separate process, you still may want to continue with your backup and recovery strategy, which VergeOS supports. Even if you do, the sophistication and expenses of that process are significantly reduced. While VMware snapshots have a high cost, IOclone does not. It is part of the reason customers who select VergeOS as their VMware alternative realize a reduction in the total cost of ownership by as much as 80% in addition to 30% or larger upfront licensing savings.