When comparing kcore to Proxmox, Nutanix, OpenShift Virtualization, OpenStack, and OpenNebula one should consider the need of teams for a genuine alternative to VMware.
The situation in the VMware market has changed and many organizations are now considering other options. For a long time VMware had been the standard when it came to enterprise virtualization. The system was well developed, the tools were well known, and administrators were familiar with the way it worked. Because of the licensing arrangements, the commercial flexibility, and the strategic control involved, a new question arose: not just 'what will replace VMware?' but 'what kind of operating model do we want in the future?'
That distinction matters.
Leaving VMware is not the same as switching hypervisors. It involves making a decision regarding cost structure, the skills required, automation, integration with storage and networking, the level of migration risk, and how much vendor lock-in you are willing to accept on the next platform. The correct choice will depend on whether you need simple virtualization, a Kubernetes-first approach, a complete private-cloud control plane, or a VM-first platform which still provides APIs and Terraform.
The real criteria for a VMware replacement
Headline feature lists are a poor filter; instead, the new solution must include all the tasks you currently carry out—that is, creating and assigning VMs, attaching storage and networks, ensuring that the virtual machines remain available, backing them up, and supporting the hardware that your applications require, including the GPUs when they are needed.
That is just the first layer.
Teams also desire operations that are similar to those offered by the cloud: an API, declarative configuration, changes that can be reviewed, and a workflow which does not require each change to go through a proprietary console. Terraform and YAML are important in this context since they convert the environment into text which can be diffed and audited.
It is important to have Kubernetes support, but this has to be considered in the specific situation. In some cases organizations are already taking a Kubernetes-first approach, while in many others a large number of virtual machines are still in use and therefore they need a platform that will allow Kubernetes to be introduced later on without being forced to redesign every workload from the very beginning.
The migration tools are involved when choosing a platform; inventory taking, disk conversion, and cutover constitute separate tasks. In order to be credible, an exit plan must specify who is responsible for each task and what stays part of the project.
The platform landscape
A number of platforms are vying for attention, each with its own center of gravity.
- If you want to remain within VMware, the best option is VMware Cloud Foundation since it preserves your current operating model and ecosystem, as well as the commercial exposure which was the reason the exit talks began.
- Nutanix is a good choice when the main concern is having an appliance-style setup, since its integration offers an appealing advantage. However, the typical compromises that teams face when they leave VMware are high costs and platform dependence.
- Proxmox is attractive to smaller environments, labs, and teams who want simple KVM virtualization at a lower cost since simplicity is one of its advantages; however, it is not as suitable when one requires a first-class API, uses Terraform as the default workflow, and has a productized route from inventory to guest definitions on a different hypervisor.
- Red Hat OpenStack is suitable for large IaaS environments due to the dedicated platform engineering it provides. The level of operational responsibility is genuine, and most teams will not be able to justify the cost of the lifecycle unless they already have OpenStack skills in-house.
- Red Hat OpenShift Virtualization is an option that starts with Kubernetes. It is appropriate in cases where Kubernetes is already the primary operating model and VMs play a secondary role. However, it is not always the most natural choice when replacing a VM-first VMware setup.
- OpenNebula is aimed at enterprises which want VM operations together with a more extensive private-cloud and multi-tenant approach, this including elastic Kubernetes as part of that offering. When your need is for a complete open private cloud of that type, you should assess it on the basis of those criteria.
Where kcore fits
kcore is a hypervisor product that takes a virtual machine-first approach for those who want to avoid VMware's pricing without having to switch to another closed-appliance stack. Guests can be managed using kctl, YAML manifests, and the Terraform provider kcorehypervisor/kcore, which communicates with the kcore API via gRPC. This represents a standard IaC workflow, not something that relies on a shell wrapper.
The price is based on each physical CPU socket per year, not on each core. The Community Edition ISO and kctl are available through GitHub Releases under the Apache-2.0 license. The paid tiers finance the signed distribution, the enterprise update channel, and commercial support. For details on pricing, see pricing.
The system for issuing host updates is set up in such a way that if an update fails, the previous version of the system will be booted and Windows Server and Windows desktop guests will then continue to operate. For a virtual machine to be live migrated, shared Ceph storage is required; control-plane replication between data centers is not achieved through vSphere HA. Only one physical GPU can be allocated to a single VM; NVIDIA vGPU is not available. These limitations are listed on the features page so that you can make realistic plans.
Kubernetes can be made available in the form of clusters on nodes that are already part of the kcore cluster, thus allowing for a step-by-step approach in which VM-first operations are maintained before Kubernetes is introduced where it is beneficial. The fact is not that all features of a Kubernetes-first platform become available on day one.
When it comes to migration, kcore-migrate creates inventories for either vCenter or Proxmox and then generates Terraform code for kcore, along with a gap report. The convert tool converts an exported disk into qcow2 or raw format using either virt-v2v or qemu-img; it does not directly retrieve the disk's bytes from vCenter. Cutover is still considered a project. The steps that the operator needs to follow are given in the import guide. A more detailed separation of the inventory tools, the disk movers, and the Terraform generators is described in Three kinds of VMware migration tool.
Match the platform to the operating model
The more appropriate comparison is not one of having the most features. It should be about what kind of operating model we aim to adopt for the next five years.
- Proxmox is often chosen by small environments and technical teams.
- HCI in the form of an appliance usually ends up with Nutanix.
- Large engineering-focused IaaS often uses OpenStack.
- Organizations that adopt a Kubernetes-first approach tend to end up choosing OpenShift Virtualization.
- The needs relating to private clouds and multi-tenant IaaS are usually met using OpenNebula or similar systems.
- Estate projects that are based on VMs and wish to obtain commercial terms on a per-socket basis, and who have reviewable Terraform and YAML files, a free evaluation ISO, and a migration pathway that generates destination HCL, end up choosing kcore.
If you require NetApp, Veeam, or certification from another vendor as part of your hard gate, then you should refer to that vendor's support matrix for the platform you have chosen. Never assume that a blog post takes the place of carrying out this check.
Conclusion
Deciding to leave VMware is a strategic choice concerning infrastructure, not merely a matter of cost. If the right replacement isn't made, lock-in will be recreated, additional operational burden will be imposed that you can't staff, or an operating model will be forced upon you which doesn't suit the workloads you still need to run.
The most suitable option is the one that matches your architecture, skills, commercial objectives, and cloud timeline; kcore was designed for the approach that teams want which involves a practical exit based on virtual machines with API and Terraform used as normal tools.
Questions: team@tacconiconsulting.com.