We’re happy to announce the release of Kubermatic Virtualization (KubeV) 1.3. This release brings built-in VMware migration, backups and restore for running VMs, multi-tenancy, self-service networking, and a friendlier console.
For most organizations, choosing a VMware alternative is only the first step. The bigger challenge is moving existing VMs and making sure the new platform is ready to run them in production. With KubeV 1.3, migration and day-to-day VM management are now even easier to handle from a single platform.
With this release, teams can migrate VMs from vSphere directly through KubeV, protect running workloads with backups, and provide different teams or customers with their own isolated environments on a shared platform.
Built-In VMware Migration: Move vSphere VMs Without the Manual Work
Rising VMware licensing costs have pushed many teams to look for an exit. But moving workloads off VMware can still involve a lot of manual work, especially when migrating large numbers of VMs.
KubeV 1.3 now includes the migration engine directly in the platform. The migration engine ships with the platform, and KubeV installs and maintains it for you, so administrators only need to connect a vCenter once. Users then pick the VMs they want to move, match them to networks and storage, and start the migration from a guided wizard, without ever seeing vSphere credentials.
The wizard can work with large inventories, keeps a history of migration plans, and can place VMs directly on existing networks so they keep working the way they did before. Teams using NetApp ONTAP storage can also hand disk copying over to the storage array, helping speed up large migrations.
This makes it easier to migrate workloads in waves while managing the entire process directly from the virtualization platform.
Back Up Running VMs Out of the Box, No Shutdown Required
Before a team moves production workloads off VMware, the first question from operations and compliance is usually the same: how do we protect and restore these VMs?
With KubeV 1.3, the VM backup and restore feature is enabled out of the box on new installations. Once you’ve configured your own S3-compatible storage as the backup target, you can trigger backups of running VMs to it, so a VM keeps serving users while it’s backed up, with no shutdown needed. Backups also cover the disks created from the dashboard, so the VMs your teams create day to day are included without extra preparation on the VM side.
Each backup now has its own details page showing what was captured and what happened along the way. If a backup can’t complete, KubeV reports it right away with a clear reason instead of retrying quietly in the background. Operations teams get a simple answer to “are we protected?”, and compliance owners get the visibility they need to sign off on moving critical workloads.
Multi-Tenant Virtualization: One Platform for Every Team and Customer
One virtualization cluster for one team is simple. Serving many departments, or many customers as a service provider, needs clear separation, access control, and self-service. Without it, every new team means another cluster to run or another queue of tickets.
KubeV 1.3 integrates with the Kubermatic Developer Platform (KDP) to add organizations and projects to KubeV. Permissions apply at three levels: the whole platform, an organization, and a single project. Each team or customer works with their own VMs inside their own project, with access controlled at the level that fits.
Getting started is flexible. You can connect an existing KDP installation, or let the KubeV installer set KDP up for you. Either way, the platform team runs one shared platform while every tenant gets a self-service private cloud. For service providers, that is the foundation for a VM offering; for enterprises, it is a practical way to replace a shared VMware estate department by department.
Self-Service Networking
KubeV 1.3 brings more networking capabilities directly into the dashboard. Users can manage NAT gateways, public IPs, routing between virtual networks, and per-VM firewall rules without having to rely on the platform team for every change.
For larger environments, an edge router can connect virtual networks to the physical network. Existing networks can also be brought into KubeV.
Safer Upgrades and More Reliable Air-Gapped Installs
Cluster upgrades now follow a safer order, allowing VMs to move between hosts during maintenance without unnecessarily blocking the upgrade process.
This release also improves installations in air-gapped environments.
Easier VM Management, Now with GPU Support
Creating and editing VMs is easier, with operating system presets, sensible defaults, and dedicated edit pages for VMs and VM pools. Custom-sized VMs can now use GPUs, making it simpler to run AI and other GPU-heavy workloads next to your existing VMs.
The dashboard now shows events and errors directly alongside each resource, and the administration area has been reorganized to make VM management easier.
What to Check Before Upgrading to KubeV 1.3
A few things are worth checking before upgrading:
- KubeVirt settings in your cluster configuration file are now applied and checked. Review them before upgrading, because invalid settings that were accepted before will now be rejected.
- A few defaults have changed, including how VMs are moved between hosts during maintenance. The release notes list the details.
There are no deprecations in this release.
Try Kubermatic Virtualization 1.3
The full list of changes is in the release notes. For step-by-step instructions, see the upgrade guide, and for more details, visit the Kubermatic Virtualization documentation.
If leaving VMware is on your roadmap, KubeV 1.3 is a good time to test it. Connect one vCenter, move a few representative VMs, back them up, and see what your migration timeline really looks like. Our team is happy to help you plan it. Talk to us.
