# Static IP Retention During VMware to OpenShift Migrations: Why On-Premise Wins and ROSA Rewrites the Rules

There’s a familiar story in hybrid cloud migrations: someone wants to lift a VM from VMware into OpenShift, drop it neatly into the cloud, and—of course—keep the same IP.

It sounds simple, right? But the answer, like most things in networking, depends entirely on **where you’re landing**.

If you’re moving into an on-premise OpenShift cluster, congratulations—you can keep that IP and move on with your day.

If you’re heading into **ROSA (Red Hat OpenShift Service on AWS)**… well, you’re going to have to let that IP go.

Let’s break down why this happens, what the architectural divide really means, and how to handle it without losing sleep (or your network engineer’s respect).

---

## The Short Answer

* **On-Premise OpenShift** → Yes, you can keep the IP.
* **ROSA (AWS-managed OpenShift)** → No, you can’t.
* **Why?** Because on-premise networks speak *Layer 2*, while AWS lives in a *software-defined Layer 3* world.

It’s less about your configuration skills and more about **physics meeting software abstraction**.

---

## On-Premise: Where IP Retention Just Works

On-premise environments (VMware, KVM, bare metal—you name it) are built on **Layer 2 adjacency**. Everyone on the same VLAN can chat directly using ARP—like an office full of engineers yelling to each other across cubicles.

So when you move a VM from vSphere to OpenShift Virtualization **on the same VLAN**, nothing magical happens; it’s just physics and a shared broadcast domain.

Here’s how it looks architecturally:

       ┌─────────────────────┐
       │  VMware vSphere     │
       │  (VLAN 100)         │
       └────────┬────────────┘
                │ Layer 2 Bridge
       ┌────────┴────────────┐
       │  OpenShift Node     │
       │  (Same VLAN 100)    │
       └────────┬────────────┘
                │
          ┌─────┴─────┐
          │   Migrated │
          │     VM     │
          └────────────┘

When both environments share the same **Layer 2 segment**, your VM keeps the same MAC, sends a few ARP requests, and everyone knows who’s who.

You can make this happen by creating a **Linux bridge** on your OpenShift worker nodes and exposing it through a **NetworkAttachmentDefinition (NAD)**. Then, when you migrate with **Red Hat’s Migration Toolkit for Virtualization (MTV)**, it maps the source network to that NAD and even keeps the MAC address intact.

Once the VM boots, it reintroduces itself to the network—and because the MAC didn’t change, the IP is still valid.

### The OS-Level Quirk: When Your NIC Forgets Who It Is

Here’s where it gets tricky: inside the VM, your OS may have amnesia.
VMware presents a `vmxnet3` adapter, but OpenShift/KVM uses `virtio-net`.

So your trusty `ens192` might suddenly become `enp1s0`, and your static IP configuration vanishes.

You can fix this preemptively:

**Method 1: Clone the network config**

nmcli connection clone ens192 enp1s0
nmcli con modify enp1s0 connection.interface-name enp1s0

**Method 2: Enforce predictable naming**

grubby --update-kernel=ALL --args="net.ifnames.prefix=net"

Both ensure that when the VM wakes up in its new virtual home, it remembers who it is—and where it lives.

---

## ROSA: When AWS Says “That IP Doesn’t Exist Here”

Now, let’s cross the cloud boundary.

Red Hat OpenShift Service on AWS (ROSA) doesn’t live in your data center—it lives *inside* your AWS **VPC**.

And that means everything, from routing to IP assignment, is defined by AWS’s **Layer 3 software-defined network**.

AWS VPCs don’t do ARP, broadcasts, or shared VLANs. There’s no “hey neighbor” conversation happening here. Instead, the control plane knows every IP and routes packets directly, like a silent librarian who knows every seat in the library.

That’s why your old on-prem IP (say, `192.168.1.50`) simply **doesn’t exist** in the AWS VPC’s CIDR range (say, `10.0.0.0/16`).

Even if you tried to assign it, AWS would just shrug—it’s not routable, not valid, and definitely not part of the VPC’s defined network space.

---

## The Cloud-Native Mindset Shift: Re-IP and Move On

So what do we do?

We **embrace re-IP** as a standard part of cloud migration. Instead of forcing an old address into a new universe, we give the VM a new, permanent IP from the AWS subnet.

And here’s the thing—it’s not about the IP anymore.
It’s about the **service**.

In ROSA, the right way to expose your migrated VM isn’t through a static IP—it’s through an **AWS Load Balancer** provisioned via the **OpenShift LoadBalancer Service**.

That load balancer gets a **stable DNS name** (e.g., `my-app-123.us-east-1.elb.amazonaws.com`), which becomes your new endpoint.

Here’s the simplified flow:

   [Client]
      │
      ▼
┌──────────────┐
│ AWS Load     │
│ Balancer     │
│ (DNS Stable) │
└──────┬───────┘
       │
   ┌───▼──────────────┐
   │ ROSA Worker Node │
   │ (VPC 10.0.0.0/16)│
   └───┬──────────────┘
       │
   ┌───▼────────┐
   │  Migrated  │
   │     VM     │
   └────────────┘

This model decouples *infrastructure identity* from *service identity*. You can replace or redeploy the VM later without touching DNS or your clients.

---

## “But, What If I Really Need That Old IP?”

Ah, the classic question.

In some rare legacy cases, you might be dealing with an application that’s allergic to change—its IP is hardcoded across a dozen systems.

You can technically extend your on-prem Layer 2 network into AWS using **VXLAN tunnels** or an **F5 BIG-IP bridge**, but this is like duct-taping two data centers together and hoping they don’t drift apart.

Yes, it’s possible.
No, it’s not elegant.
And yes, it will cost you in performance, complexity, and operational sanity.

These setups introduce latency, packet encapsulation overhead, and “trombone routing”—where traffic bounces back to your on-prem router before returning to AWS.

That’s why extending Layer 2 is considered a **network anti-pattern**.
It’s fine for short-term coexistence, not for long-term design.

---

## Migration Blueprint: The Realistic Playbook

Here’s how I approach a static-IP-sensitive migration from VMware to OpenShift on ROSA:

### **Phase 1: Discovery**

* Identify every system or service dependent on the VM’s IP.
* Reserve a new IP from the AWS subnet.
* Plan DNS cutovers early.

### **Phase 2: Preparation**

* Deploy **MTV** on your ROSA cluster.
* Create a **NetworkAttachmentDefinition (NAD)** with a `macvlan` or `ipvlan` CNI.
* Use **cloud-init** to preconfigure the new IP inside the VM.

[Code Block: Example cloud-init `networkData` configuration for static IP setup]

### **Phase 3: Migration**

* Run MTV warm migration (copies while VM is live).
* Attach the NAD to the new VM.
* Inject the `cloud-init` file.

### **Phase 4: Validation**

* Confirm the static IP assignment.
* Expose the VM through a `Service` of type `LoadBalancer`.
* Update DNS records to the new endpoint.

---

## The Bigger Lesson

The difference between on-premise and cloud isn’t just technology—it’s philosophy.

In the data center, **the IP is the identity**.
In the cloud, **the service is the identity**.

When you start designing with that in mind, migrations stop being about what you lose and start being about what you gain: elasticity, automation, and a cleaner network model that won’t crumble under the weight of “legacy IP pride.”

---

**Final Thought:**
If you’re still fighting to keep an old IP in a new cloud, you’re missing the point.
Sometimes the smartest network move isn’t to preserve what was—but to architect for what’s next.

---

*(All architectural observations and networking details have been verified against common OpenShift and AWS VPC configurations. Layer 2 tunneling solutions are feasible but discouraged; always test these designs in controlled environments before production.)*