Migrating a digital device from one hypervisor to some other is a job fraught with demanding situations. We ceaselessly get so stuck up in putting in the platform, configuring the community and different infrastructure parts, and handiest afterwards believe the demanding situations throughout the digital machines themselves. In this newsletter, I speak about probably the most tactics you’ll be able to make the transition of community configuration on Red Hat Enterprise Linux digital machines from VMware to Red Hat OpenShift Virtualization smoother and more straightforward for the ones workloads that is probably not in a position to make the most of probably the most trendy ways in which OpenShift handles networking.

OpenShift Virtualization and conventional community configuration

Back when information facilities have been filled with bodily servers, each and every server would have a number of Ethernet cables that attached to a transfer, which then allowed get right of entry to to the remainder of the surroundings or the web. VMware digital machines took the similar method, however virtualized now not handiest the bodily server, but additionally the bodily Ethernet switches, permitting digital device directors to modify community configurations with a couple of mouse clicks. However, the fundamental structure remained the similar.

Red Hat OpenShift handles networking otherwise, by way of the usage of a devoted pod community for microservices, with software-defined load balancers (known as services and products) in entrance of the programs. These services and products are to be had throughout the cluster and may also be uncovered by way of a course with a DNS call to different programs and customers out of doors the OpenShift cluster. One of the advantages of this system is that the particular community configuration of any explicit microservice, akin to its IP cope with, turns into inappropriate. The OpenShift cluster and repair manages the ones relationships.

However, conventional digital machines don’t essentially are compatible into the OpenShift approach of doing issues, by no means when the concern is to raise and shift the workloads from VMware to OpenShift Virtualization. For the ones circumstances, OpenShift Virtualization does supply numerous tactics for digital device workloads to get right of entry to the exterior community. One of my earlier weblog posts outlines a few of the ones strategies and the right way to use them.

The first step to get your OpenShift Virtualization cluster configured is to permit digital machines to get right of entry to the exterior community, and feature a migration plan in position (such because the Migration Toolkit for Virtualization). Then you should believe what adjustments wish to be accomplished to the community configuration at the digital device itself to ease migration from VMware to OpenShift Virtualization.

The community adapter configuration puzzle

Red Hat Enterprise Linux and the underlying Linux kernel use numerous other laws to call a community interface card (NIC). For instance, a RHEL 9 server operating on VMware could have a community adapter the usage of the VMXNET motive force that udev calls ens192, as on this instance:

# ip hyperlink
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT workforce default qlen 1000
    hyperlink/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UP mode DEFAULT workforce default qlen 1000
    hyperlink/ether 00:50:56:af:23:16 brd ff:ff:ff:ff:ff:ff

But after the usage of a device such because the Migration Toolkit for Virtualization to transport to OpenShift Virtualization, the similar server may use the VirtIO motive force and boot with a community adapter call known as enp1s0, as on this instance:

# ip hyperlink
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT workforce default qlen 1000
    hyperlink/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UP mode DEFAULT workforce default qlen 1000
    hyperlink/ether 00:50:56:af:23:16 brd ff:ff:ff:ff:ff:ff

If you do not anything to arrange for the migration, then your migrated digital device has no get right of entry to to the community as a result of it is not able to seek out the community adapter it was once to start with the usage of. This manner the digital device administrator should log in to the console of each and every migrated digital device and manually exchange its community configuration. Even automation equipment like Red Hat Ansible Automation Platform would not  get to the bottom of the problem, since the digital machines don’t seem to be attached to the community.

But do not be concerned! There are answers to this puzzle.

Option #1: Updating NetworkSupervisor configuration to compare the community interfaces

I’ll get started with the most simple state of affairs, which is to make a clone of the community configuration after which replace it to compare the call of the community interfaces that can if truth be told be provide after the migration.

Advantages:

• Very easy to put into effect
• Easy to automate
• Works on Red Hat Enterprise Linux 7, 8, 9
• No downtime as opposed to migration

Disadvantages:

• You should know the objective interface names upfront of migration
• Only works with NetworkSupervisor
• Requires a small quantity of cleanup after migration

The instance under assumes the server being migrated is getting its IP cope with from DHCP. However, the stairs are an identical for a server with a static IP cope with.

Here’s the community configuration of my instance server previous to migration when the digital device remains to be operating on VMware (this output is abbreviated for comfort):

# ip cope with
1: ...
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP workforce default qlen 1000
   hyperlink/ether 00:50:56:af:23:16 brd ff:ff:ff:ff:ff:ff
   altname enp11s0
   inet 10.8.50.215/23 brd 10.8.51.255 scope world dynamic noprefixroute ens192
      valid_lft 42965sec preferred_lft 42965sec
   inet6 2620:52:0:832:250:56ff:feaf:2316/64 scope world dynamic noprefixroute 
      valid_lft 2591985sec preferred_lft 604785sec
   inet6 fe80::250:56ff:feaf:2316/64 scope hyperlink noprefixroute 
      valid_lft without end preferred_lft without end

The community interface known as ens192 has an IP cope with of 10.8.5.215. After migration, the community interface will use VirtIO drivers and will likely be renamed to enp1s0 (on Red Hat Enterprise Linux 7, the brand new interface call will likely be eth0).

To get ready this digital device for migration, you’ll be able to clone the community configuration to the brand new call after which replace the interface. First, clone the NetworkSupervisor configuration for ens192 to a brand new connection known as enp1s0:

# nmcli connection clone ens192 enp1s0

At this level, you will have handiest created a brand new configuration known as enp1s0, however it’s nonetheless the usage of the prevailing ens192 interface. Modify the brand new connection to make use of the enp1s0 interface as a substitute:

# nmcli con alter enp1s0 connection.interface-name enp1s0

Now you are prepared for the migration! After the digital device is migrated to OpenShift Virtualization and it is configured to connect with the exterior community, the brand new community adapter configuration is identical, except for for the call. The IP cope with and MAC cope with are the similar as they have been earlier than the migration, so any programs would proceed to serve as simply as earlier than.

# ip a
1: ...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UP workforce default qlen 1000
   hyperlink/ether 00:50:56:af:23:16 brd ff:ff:ff:ff:ff:ff
   inet 10.8.50.215/23 brd 10.8.51.255 scope world dynamic noprefixroute enp1s0
      valid_lft 43182sec preferred_lft 43182sec
   inet6 2620:52:0:832:250:56ff:feaf:2316/64 scope world dynamic noprefixroute 
      valid_lft 2591982sec preferred_lft 604782sec
   inet6 fe80::250:56ff:feaf:2316/64 scope hyperlink noprefixroute 
      valid_lft without end preferred_lft without end

The previous community adapter configuration remains to be provide, however it may be got rid of at any time.

# nmcli connection display
NAME    UUID                                  TYPE      DEVICE
enp1s0  360d1330-11cf-3a91-ae05-590058fc3e82  ethernet  enp1s0
lo      5e40f44b-5388-4dad-bfdb-502e97a74c26  loopback  lo    
ens192  1d8cc2e0-c4f8-3dc8-a372-97bc75cec1ed  ethernet  --
# nmcli con delete ens192
Connection “ens192” (1d8cc2e0-c4f8-3dc8-a372-97bc75cec1ed) effectively deleted.

Using this selection with groups or bonds

If your digital device is the usage of a workforce or bond interface, then it isn’t vital to clone any of the interfaces. Instead, simply upload the brand new interface names to the workforce or bond. When the digital device is migrated to OpenShift Virtualization, the brand new interface names are lively and the previous interface names may also be got rid of.

In the instance under, I’ve a workforce known as team0 with the interfaces ens192 and ens224 as individuals. Use the nmcli device so as to add interfaces enp1s0 and enp2s0 to the workforce. The enp1s0 and enp2s0 do not but exist within the digital device earlier than migration, however you’ll be able to upload them anyway. This does now not have an effect on the serve as of the workforce or bond.

For a workforce:

# nmcli con upload kind ethernet con-name enp1s0 ifname enp1s0 slave-type workforce grasp team0
# nmcli con upload kind ethernet con-name enp2s0 ifname enp2s0 slave-type workforce grasp team0

For a bond, the syntax is:

#  nmcli con upload kind ethernet con-name enp1s0 ifname enp1s0 grasp bond0
#  nmcli con upload kind ethernet con-name enp2s0 ifname enp2s0 grasp bond0

Once the digital device is migrated, the previous ens192 and ens224 interfaces may also be deleted:

# nmcli con del ens192
# nmcli con del ens224

Because the workforce or bond itself was once by no means modified on this instance, the MAC cope with stays the similar, so the IP cope with  from DHCP additionally stays the similar.

Option #2: Updating community interfaces to compare the NetworkSupervisor configuration

The earlier instance was once simple, nevertheless it assumes that you simply knew upfront what the community adapter names will likely be earlier than beginning the migration. That’s a protected assumption in lots of circumstances, however should you use a unique community adapter motive force or have any other configurations in position (akin to a lot of other community adapter sorts), then it could be tricky to are expecting what the brand new community adapter names are going to be.

In this example, you’ll be able to make some adjustments to how udev names community adapters previous to migrating the digital device. This does require some paintings, however it is repeatable paintings that may be treated by way of a just right automation device like Red Hat Ansible Automation Platform

Advantages:

• Network interface names will likely be identified upfront
• Can be automatic
• Works for Red Hat Enterprise Linux 8 and 9

Disadvantages:

• Doesn’t paintings for Red Hat Enterprise Linux 7 servers
• Requires an outage upfront of the migration
• Some interface prefixes is probably not used

The instance under calls for editing the kernel boot parameters to set the prefix for the community adapter call, or interface call, to one thing of your selection. As is printed on this Red Hat Knowledgebase article, keep away from the usage of community adapter names that may battle with names that udev already makes use of, akin to eth, ens, em, or eno. For this case, I exploit the prefix internet, which might make our first community adapter net0, and the second one net1, and so forth.

To set a community interface prefix, upload the next line to the kernel boot parameters:

internet.ifnames.prefix=internet

The best strategy to set this parameter is with the grubby device:

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

Before you reboot, observe the similar steps as in Option #1, however this time you already know precisely what the community adapter names will likely be. Furthermore, you’ll be able to do all of this paintings in a deliberate server outage at any time earlier than the migration starts as a result of those steps be certain that the community adapter names keep the similar, whether or not the digital device is operating on VMware or on OpenShift Virtualization.

# nmcli connection clone ens192 net0

At this level, you have got handiest created a brand new configuration known as net0, however it is nonetheless the usage of the prevailing ens192 interface. Modify the brand new connection to make use of the net0 interface:

# nmcli con alter net0 connection.interface-name net0

After the digital device is rebooted, the community adapters use the brand new naming conference. Remember, on this state of affairs the digital device remains to be operating on VMware!

# ip cope with
1: ...
2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP workforce default qlen 1000
   hyperlink/ether 00:50:56:af:03:61 brd ff:ff:ff:ff:ff:ff
   altname enp11s0
   altname ens192
   inet 10.8.50.131/23 brd 10.8.51.255 scope world noprefixroute net0
      valid_lft without end preferred_lft without end
   inet6 2620:52:0:832:250:56ff:feaf:361/64 scope world dynamic noprefixroute 
      valid_lft 2591984sec preferred_lft 604784sec
   inet6 fe80::250:56ff:feaf:361/64 scope hyperlink noprefixroute 
      valid_lft without end preferred_lft without end

After migrating the digital device to OpenShift Virtualization, the community adapter call does not exchange, so the static IP cope with or DHCP configuration is strictly the similar because it was once earlier than the migration.

# ip cope with
1: ...
2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP workforce default qlen 1000
   hyperlink/ether 00:50:56:af:03:61 brd ff:ff:ff:ff:ff:ff
   inet 10.8.50.131/23 brd 10.8.51.255 scope world noprefixroute net0
      valid_lft without end preferred_lft without end
   inet6 2620:52:0:832:250:56ff:feaf:361/64 scope world dynamic noprefixroute 
      valid_lft 2591964sec preferred_lft 604764sec
   inet6 fe80::250:56ff:feaf:361/64 scope hyperlink noprefixroute 
      valid_lft without end preferred_lft without end

The previous community adapter configuration remains to be provide, however it may be got rid of at any time.

# nmcli connection display
NAME    UUID                                  TYPE      DEVICE
net0    e69b124b-50a8-4458-8859-5e68c3f19460  ethernet  net0
lo      2a0388d4-36fa-4df5-bc65-01ec8e0b6f2e  loopback  lo    
ens192  38486930-d56a-4088-bbb5-d8a6a1d236c0  ethernet  --
# nmcli con delete ens192
Connection “ens192” (38486930-d56a-4088-bbb5-d8a6a1d236c0) effectively deleted.

Seamless migration

Migrating from one hypervisor resolution that has been in use for years to a brand new one is a frightening process. Preparing for the migration is a key side of making sure the luck of any undertaking, particularly in relation to shifting workloads to leading edge applied sciences. In this newsletter, I demonstrated one side of the complicated means of appearing digital device migrations from VMware to OpenShift Virtualization.

To in finding out extra about Red Hat OpenShift Virtualization, please take a look at our product web page, in addition to a prior weblog submit of mine at the matter, or in finding extra details about our equipment to lend a hand within the migration.  Together, we will make the transition to OpenShift digital machines or packing containers a luck in your group.