Virtual Machine migrations between differing hypervisor platforms rarely fail because compute or storage could not move. They fail because the application can no longer talk to what it needs to talk to. IP identity, segmentation intent, and return path behavior are usually embedded into everything around the workload, and those assumptions are hard to reproduce during a platform move. Isovalent Networking for Virtualization is built to take that network risk out of the critical path. It combines two capabilities, Isovalent Private Networks and the Isovalent Network Bridge, so you can move workloads incrementally, preserve IP identity, and keep connectivity consistent while you modernize your virtualization platform. If you only read one section Isovalent Networking for Virtualization is a controlled availability solution for teams migrating virtual machines from VMware platforms to OpenShift Virtualization, without turning the network into a redeployment project. Keep applications connected while you migrate: the Isovalent Network Bridge lets application components span VMware and OpenShift Virtualization during phased moves, so you can migrate tier by tier and reduce downtime risk. Preserve IP identity: avoid the chain reaction of firewall, DNS, and configuration changes that often follows IP renumbering. Prove each step with security and visibility: one policy model across VMs and containers, plus Timescape dashboards that make traffic, policy, and suspicious access patterns easy to validate during migration. Use a VPC style network model inside Kubernetes: Isovalent Private Networks , our main differentiator, provides isolated overlay networks for VMs and containers, including overlapping CIDRs and multi-tenant segmentation. Isovalent Networking for Virtualization is available through controlled availability. Contact us to discuss fit and access. Why VM migrations stall at the network layer When teams plan a migration, it is easy to underestimate how much “identity” is really the network: IP identity is sticky: Static addressing, allow lists, DNS entries, and operational runbooks often assume an IP address is stable, even if that stability was provided by conventions rather than guarantees. Readdressing forces coordinated change across app and infrastructure teams, and that is where risk stacks up. Segmentation intent gets lost: Security rules might be attached to port groups, distributed firewalls, or external appliances in the traditional environment. During cutover, teams can end up with temporary default allow behavior while they try to recreate the policy model somewhere else. Return traffic problems show up later: Even when traffic goes out successfully, asymmetric routing, unexpected NAT, and topology differences break stateful flows and produce the worst kind of outage: everything looks “up,” but the app is not usable. This is why VM migrations are not an event, they are a methodology. You need a phased approach that makes network assumptions visible, then gives you a path to change platforms without breaking connectivity. Introducing Isovalent Networking for Virtualization Isovalent Networking for Virtualization is designed for cloud native virtualization platforms that are extended to run Virtual Machines side by side with containers. It is made of two components: Isovalent Network Bridge provides seamless workload communication between VMware and OpenShift clusters running OpenShift Virtualization, enabling incremental migrations with preserved IPs and less migration risk. Isovalent Private Networks brings a VPC style networking model to Kubernetes for VMs and containers, including overlapping CIDRs and multi-tenant segmentation. Private Networks define isolated networks inside OpenShift, and Network Bridge keeps VMware and OpenShift Virtualization connected while workloads move. Together, they let you treat migration as a staged operating model change, not a single high risk cutover event, and designed to deliver three outcomes that matter in migration programmes: Incremental network migrations and preserved IPs: phased migrations where applications progressively span VMware and OpenShift clusters running OpenShift Virtualization, reducing risk and complexity while maintaining existing IPs. Flexibility without downtime pressure: move tiers when you are ready, keep application connectivity intact during the transition, and avoid forced changes to networking and application configuration. Enhanced security and observability: extend policy enforcement and flow visibility across VM and Kubernetes workloads. Isovalent Network Bridge: keep apps connected while you move In many environments, VMware and Kubernetes are separate islands for internal workload communication. Without a bridge, you are forced into “all tiers move at once,” because the moment a tier moves, it loses the network it expects and the application breaks. The Isovalent Network Bridge changes that migration constraint: Application components can incrementally or permanently span environments, allowing staged cutovers that keep the app connected while you move one tier at a time. Migrations can preserve IP identity, reducing the need for IP readdressing and the chain reaction of firewall, DNS, and configuration changes. The bridge is designed to be highly available, high performance, and self managed, with built in security and observability. Isovalent Private Networks: a Kubernetes VPC model for VMs and containers Private Networks provide the address space and isolation model that many teams need once VMs and containers share the same platform. Isovalent Private Networks are overlay networks used by virtual machines to attach vNICs, obtain network addresses, and communicate within isolated networks. They support overlapping CIDRs, multi-tenancy, and support Isovalent Network Bridge to provide connectivity to existing physical networks, enabling flexible network segmentation and migration topologies. What Private Networks add to Kubernetes Private Networks are designed to provide: Overlapping CIDRs and isolation: support for overlapping IP spaces across isolated private networks, which is essential for multi-tenant environments and complex migration scenarios. On demand network creation backed by Cilium: private networks can be created on demand and are backed by Cilium. IP address management integration: full integration with IP Address Management solutions. Connectivity to physical networks: Combined with Isovalent Network Bridge for bridging to physical networks, enabling migration topologies such as VLAN trunking or or EVPN Virtual Network Identifiers, which map workloads into Layer 3 segments across the fabric. Micro segmentation with Cilium Network Policies: Apply Cilium Network Policies to Private Networks so you can enforce fine grained, identity based controls between VMs, and between VMs and containers, within each isolated network. This is the foundation you need when you want Kubernetes to host VMs without forcing every workload into a single flat pod network model. How the two pieces fit together in a migration A simple way to think about the solution is: Define the target networks using Private Networks: so address space, isolation boundaries, and connectivity rules are clear and repeatable. Connect VMware platforms and OpenShift Virtualization with the Network Bridge: so application tiers can keep talking while you move them. Move workloads based on constraints: start with the ones that have fewer fixed IP and segmentation dependencies, then tackle the harder tiers once the pattern is proven. Validate each step with flow visibility and policy signals: so you can confirm the move is safe, and roll back quickly if a dependency was missed. This turns migration into a repeatable process, not a string of bespoke, late night cutovers. Watch the walkthrough In this walkthrough video, we migrate a virtual machine from a VMware vSphere environment to OpenShift Virtualization using Isovalent Network Bridge and Isovalent Private Networks to keep connectivity consistent through the move, then we close by showing what you gain after migration, Timescape flow visibility and Cilium Network Policies applied across both VM and container workloads. Security and visibility that stays consistent as workloads move Connectivity is only the start. During a migration you also need to preserve security intent and reduce blind spots. Isovalent Networking for Virtualization integrates built in Cilium security and observability features to enforce network policies and provide deep network flow visibility across VM and Kubernetes workloads. Migration success comes down to confidence at each step. You need to know what changed, whether it matches your intent, and whether any hidden dependency just surfaced. Timescape helps you turn a migration from a leap of faith into a series of measurable checkpoints. Start with visibility. The Timescape flow logging dashboard gives you a clear picture of who is talking to whom as workloads span VMware and OpenShift Virtualization. That makes it easier to spot unexpected east west dependencies early, validate that the bridged connectivity is behaving as expected, and confirm that the traffic you intended to keep local is actually staying local. Then validate intent, not just reachability. The Timescape network policy dashboard helps you confirm that segmentation is enforced the way you designed it, before and after each move. This ties directly to Cilium based policy enforcement, where policies can be expressed using workload identity rather than volatile IPs, and enforced in the kernel before traffic reaches the VM virtual interface. The result is a consistent security posture as workloads shift platforms. Finally, look for signals that explain the weird failures. Timescape also highlights suspicious access patterns, for example repeated database connection attempts from an unexpected source. During a migration, those signals can indicate a misrouted dependency, a missing policy rule, or an application component that is still pointing at the old destination. That shortens time to resolution and gives teams a safer path to proceed to the next migration wave. Migrate without turning networking into a rewrite project If your VM strategy is changing, the fastest path forward is rarely a single big cutover. The safer approach is a phased migration that preserves IP identity, keeps application connectivity intact, and gives you consistent policy and flow visibility while you move. Isovalent Networking for Virtualization is built for teams who want to reduce VMware dependency and adopt Kubernetes based virtualization, without letting the network become the main thing that slows the project down. By combining the Isovalent Network Bridge with Isovalent Private Networks, you can preserve IP identity, keep segmentation intent intact, and move workloads incrementally while maintaining connectivity and visibility throughout the transition. If you want help designing the right migration pattern for your environment, reach out to your Isovalent contact.