Migrating Virtual Machines to Kubernetes based platforms can be a challenge! Isovalent Networking for Virtualization removes the pain of migration, and this technical walkthrough shows you how to successfully migrate virtual machines from VMware vSphere to Red Hat OpenShift. Introduction If you've ever tried to move virtual machines off a VMware platform, you already know the hard part is not the compute or the storage it's actually the network. Applications are typically tied to their IP addresses, which is their identity on the network that ties to security rules and the routing behavior that has grown over years inside of the data center. change any of that too quickly and the application will still boot up on your new platform but you'll find that it can't reach the service that needs access to and you end up troubleshooting that under pressure at last minute and then having to perform a roll back. Most migrations hit the same blockers you want to move in phases, but the moment that you've moved one tier of application, it loses the network that it expects. Ideally, you want to avoid having to reIP every static network. Configure virtualization networking address that's set on every single virtual machine because that triggers updates across firewall rules, DNS entries, application configurations and then also you may lose access to that segmentation temp that's been set up as well that migration may also open you up to new attack paths or break compliance controls inside of your data center as well. well and then the last piece that you need to think about is that deep visibility at each step to prove that when you've migrated the workload, what's happened at that networking layer? Is the traffic flowing that you expect and also what happens if you do need to roll back if a hidden dependency does show up networking virtualization has been built to solve these problems when migrating between traditional hypervisor platforms into new modern cloud-native platforms that can run containers and virtual machines side by side it combines two capabilities the first of which is isent private networks which brings a VPC style model to OpenShift and other Kubernetes and cubvert platforms that you can define isolated networks for virtual machines and containers together this includes the ability to have overlapping IP address ranges and multi-tenant segmentation while keeping policy consistent throughout using nicelium network policies that's really key because as we all know when we've operated Kubernetes containers before we distribute the same IP address space across multiple nodes in the cluster and we don't have the ability to stage or differ different subnets at times especially if they overlap. The second component is iceel network bridge and this is what connects a VMware environment for example to an OpenShift environment during a transition. So an application components can still span both environments whilst you migrate without forcing network related application changes and that's what we're going to deep dive into today. today this is the architecture of my lab environment that we're going to run through the demo today on the left hand side at the bottom here we have our typical VMware traditional deployment. Deploy virtualization networking smaller size than what we typically see in a customer's data center of course but essentially is going to represent what everyone knows and loves about using VMware hypervisors today we have a common layer 2 von that connects kind of most of our services within this environment but the virtual machines that run in this vere deployment here run an IP address range of 1 198.8 18.128.018 that's going to be really important because on the right hand side I have my OpenShift deployment. So this is based on a enterprise Kubernetes deployment with a number of nodes we've also enabled it with the OpenShift virtualization capability which is a cube vert behind the hood that enables us to run virtual machines side by side with those OpenShift containers. However, because this is a Kubernetes environment, networking works differently to what we understand from a traditional environment. So when we migrate those virtual machines, we've also then got to adapt them for that Kubernetesbased networking. Kubernetesbased networking we're not going to dive into the full technicalities of how Cuba and Open OpenShift therefore implements that Shift therefore implements that virtualization networking today but ultimately the most important thing to remember as part of this demo is that in this OpenShift deployment here on my right hand side, the networking subnet range that is going to be used for all pods and virtual machines that run on there is going to be 10.128.0.0414. And that poses quite a problem because I'm not going to be able to move all of my applications in one go from my vSphere environment like a typical customer with scaled out application tiers when I move my virtual machines they can't move their IP address with them because that subnet range does not exist in my OpenShift deployment and that's where the isent network bridge comes in it's going to give us a way to transit that data back via the vSphere environment so that we can still transit that data using its same IP address identity and the same segmentation temp that it's used to but also benefit from all of the capabilities that you would get using not only Kubernetes to run your virtual machines but by using Cilium as that underlying data path. So you're going to get the additional out ofthe-box security compliance and observability features that everyone knows and loves when we bring Cilium to containerized workloads. containerized workloads. Okay. So now I'm going to dive into my lab environment and I'll start to show you the migrations in process how it looks in the VMware environment and then what it looks like once we've migrated into that OpenShift environment. So what is the iselt network bridge that we're going to be using in this environment that I've explained to help us migrate the workloads? Well, it's deployed in a small virtual machine form factor into the existing VMware environment it will have an internal interface that connects the existing Kubernetes cluster using an overlay. There'll be no change that are needed to the existing topology of my OpenShift environment that's already running ice networking for Kubernetes the enterprise hardened grade edition of Psilium external network interfaces are going to connect to the source VMware networks and we can connect multiple those into that network bridge virtual appliance if needed. today's environment, we're only going to connect one and then it's going to give us that full VPC like network support, that migration capability, and the ability to transit data back through that appliance into the VMware environment as if the original virtual machine has never moved. Okay, so we're going to go through my demo environment as we can see in my VMware, I've already deployed the isvalent network bridge it's just a virtual machine we talked about before it's a Linux based machine which is going to connect to our existing Cilium environment we've connected this with two network adapters that's going to connect one into my internal Kubernetes environment. So I connect to my OpenShift environment and my second app's shift environment and my second app's going to connect to where my virtual machines are and we can add more network adapters as needed into different port groups. I'm now going to power off my first virtual machine and just configure some of the prerequisite settings so that we can enable that migration these prerequisites come from using OpenShift MTV which is the built-in technology inside of OpenShift virtualization to migrate VMs so first and foremost, I'm going to enable change block tracking on this virtual machine so that when we migrate it, we take across all the data and any blocks of data that have changed during that migration as well. Now we're going to power on that virtual machine and then I'm going to log into that virtual machine so that I can install the open tools that are needed to run in OpenShift environment very similar to VMware tools for those of you familiar with Linux you'll have seen these tax commands being run before just using the AP package manager to update and then. Validate virtualization networking install that package in the background. Now my virtual machine's up and running the last thing I want to show before we carry on with the demo is just that I've running a basic web page on that machine as well and then we're going to use that to test connectivity going forward we're now in my Red Hat OpenShift environment. environment and if I go to the operators we're just going to have a look at what's actually available when we think about virtualization for OpenShift. So operators are a way to manage packaged installations of feature sets into open OpenShift and we can see I've already shift and we can see I've already installed is failent networking for Kubernetes and the migration toolkit for virtualization. I'm now going to go into the configuration side of the migration for virtualization toolkit. I'm going to create a new provider. That provider of course is going to be VMware that's my source destination. So I'm going to give in the usual credentials that we expect. How to contact it using its FQDM. We've also got a couple additional settings such as how we do the IO synchronization to be more efficient when copying that data across and then the username and password to connect into my vCenter so that one we can run discovery on it to virtual machines are there but also then we'll use the same user account to be able to copy that storage across We can now see that I've discovered my VMware environment because it's a demo it's not a massive environment, but we know that it's up and running and that we've tested the connection to it and it shows us now ready and we can also see that we've got an existing provider there, which is the host cluster itself which is the OpenShift environment. I'm now going to create my first migration plan. So we're going to do a cold migration which means we turn the virtual machines off to migrate them so that no changes are ropes from during that migration itself. Source provider of course my VMware environ my target project is going to be the OpenShift cluster that we're currently running on and we're going to put that into a new OpenShift project called finance which just maps to the same place that it's coming from in the VMware environment. I'm going to migrate to finance virtual machines. we need to set up a network map so that's how to configure the source network from VMware and target the default network the default network is going to be that containerized network that we already have running slowly in the background and in a moment we're going to see kind of where we fit in with the ICEL network bridge that does all the smart stuff of transparently making that network fully available for the virtual machine once it's moved the key thing here is we're going to preserve the static IP addresses of the virtual machine when they move. So we can see now we've got a warning the migration plan might not work as expected because we've select preserved static IP address of the virtual machines and we're using the pod networking of the underlying gold shift cluster which may not have the same subnet range available to it as the original virtual machine but that's okay because again we're going to use the ice because again we're going to use the Isovalent network bridge and the private veilent network bridge and the private network feature to handle all that for us we're going to look at that in a little bit more detail in a moment and we're going to see that the configuration of that's quite simple but first and foremost, I'm going to kick off my cold migration in the background. So, we can see that's now running as we can expect and we're going through a migration status and of course, for purpose of this video, I've sped that up if I open up the migration history, we can now see the state of that migration task running for the two virtual machines. machines we can see that we're allocating discs we'll be doing a disc conversion into the cubvert format and I'll be transferring the data from the VMware environment across into that new virtual disc that's been created into the open OpenShift platform. So what does this look like under the hood? So I'm going to go to my custom resource definitions and I'm going to look for a term called private networks this is the ice vealent private networks feature that we talked about earlier and I'm going to look for an instance of that's deployed and we've called that VM network just to map to the VMware environment we're migrating from when I open up that YAML we're going to see that it's actually really easy to configure those additional networking settings inside of the platform. So first and foremost I've specified my network bridge that's that virtual appliance that we've set up on our VMware environment it's called Open OpenShift hyphen bridge we've then set up Shift hyphen bridge we've then set up the routing information of how we get to that when we pass traffic over that network bridge and then finally the subnet that would be available on that side that makes that subnet now available inside of my OpenShift environment when I boot up that virtual machine when it's moved if we have a quick look at the Cilium configuration. Sicilium is being used as the single exclusive CNI inside of this environment. environment we can see that the pod networking range is actually the 10.128.0.0414 range which does not meet the same IP address range as that my virtual machines. So just showing you that there so you can understand the little bit of the differences in my configuration we've now found that my two Finance virtual machines have been migrated across which is fantastic. Going to go to my VMware environment we can see that those two virtual machines have now been powered off as part of that migration process. I'm going to move into the virtualization view inside of my OpenShift console and now I can see I've got two virtual machines registered and those two virtual machines are already running as part of that migration process the view here looks a little bit similar to what we're used to in terms of the web interface vere but not quite the same but most people be able to run around that. Now if I reload that page we can see that it's still available. Now I'm going to create a second plan. So we're actually going to do a warm migration this is where the virtual machine is not powered off so we will move a delta copy of the disk across we will then move across any changes that were made during the migration itself before it's finalized this is helping migrate downtime but some additional resources that are needed for that. So do check the OpenShift documentation. Again, we're going to create the same source network and a network map, sorry, for the source destination network and the same for storage as well. Very similar to the first migration plan that we created but we're still going to have that same challenge again whereby we're migrating the static IP address range from earlier and not making those changes. Again, we had the same warning there, but I'm just going to go back to my home screen and just wait for that plan to come available before I migrate the VMs so, let's kick that off now, it's available. You'll also see that we've got schedule cut over button and that just allows us then to choose when we make cut over them VMs into the live environment if we go into a vsspere environment, we can see that those two VMs are left running not been shut down. However, a snapshot has been created those virtually that's going to capture any changes during the migration process and then be synced over when we schedule that cut over. So, I'm going to ping my sales virtual machine just so we can see that happening in the background. So, we can look at that uptime and essentially, we're just proving that it stays continuously available inside of my environment we're now ready for that cut over. So, I'm basically just going to say schedule that cut over immediately and now we know the cut over start to happen because the virtual machine is going to be powered off that's why we're getting the request timeouts. I can see the virtual machines are now powered off in venter. Okay. Okay, so our destination is showing as unreachable because it doesn't know where the V virtual machine is at the moment from our data center networking that's okay and now virtual machine's just started to come back online. So we got a couple of pings there we're going to see them time out just that operating system boots in the background and then we'll see the virtual machine fully become available as we expected previously. And there we go that virtual machine is now up and running as we expected with minimize downtime. Now our virtual machines are up and running in our upper. Let's look at some of the capabilities that we can take advantage of inside of is Isovalent networking for Kubernetes extending that. virtualization networking observability to our virtual machines. So I'm going to jump into that namespace my finance where I've moved my virtual machines to and now we can see flows from Hubble already being captured straight away. So let's have a quick look at that in a little bit more detail. So we can see we've got going to the world to the outside we've got finance web one which is that virtual machine that I moved earlier and in a second we're just going to see going to zoom in on the Windows machine that I've connected from earlier for using port 80 and 443 to that virtual machine to make sure that the web page was up and running as we expected. We can also see that we are highlighting there that it's coming from the OpenShift bridge meaning that virtual shift bridge meaning that virtual machine that we deployed in our VMware instance that I showed you earlier on in the demo. So we can actually capture that traffic going across the iceent network bridge to understand where that traffic originated from. Now that we're up and running and we've got network flows coming into timescape let's look at some more advanced use cases. So I'm going to start by applying some SIM network policies these are the same SIM network policies that we use for containers they will also apply to the virtual machines that are now running in our rob shift environment whether we've created them from scratch or migrated them from VMware this very simple network policy I've applied here allows access on port 80 and port 22 for SSH to my finance web one virtual machine. machine. Going to go back to my TSC UI now I've applied that at the cluster level. I can see that it's also synchronized with the network policy change tracking feature inside of Timescape UI so it's showing me what traffic is allowed to where it's applied to and in a moment once we made some changes to that we're also going to see that sync back as well. So let's go back into our environment and test that these policies are working as we expect. So, I'm now connecting using SSH to my Finance Web One VM and then I'm going to exit out of this VM because we proved that access works. I'm just going to curl to that interface as well just to trigger the port 80 rule and we can see that's worked we've got a status code of 200 being returned there. if I now go back into my timecape UI I can now see the new flows have loaded on port 22 and port 80. I can see all those flow details in more if I click on it. I've also got the option see the raw flow in a JSON format and also the actions button there where I could create a policy on the fly if needed. needed. Now, let's go back to my cluster and we're going to change that policy that was applied and I'm going to edit the port for port 23. That means my SSH access will no longer work as expected if I go into my policies view in timescape UI I can now also see a differential of showing what was removed and what was added, what was part of those changes and that helps us with troubleshooting when network policies may be getting in the way of our access. Can now see when I try to sh to my virtual machine that's not worked and if I was going to change that just to a dropped flows there as well we can now see that those flows are being dropped because of that policy in place. Okay. So that wraps the demos covering Icevalent networking virtualization where not only have we looked at migrating virtual machines from a VMware platform into a OpenShift virtualization platform but we've also made use of the isveillent private networks feature so that we can have over overlapping IP address space inside of our Kubernetesbased cluster that also exists still in the VMware cluster we can then transit data across the Isovalent network bridge so that the virtual machine still exit onto the network in the same way it did before the migration this means that it's segmentation intent. any private IP address spacing that is being used statically assigned for example is still in use and does not need to be changed as part of that migration minimizing the risk of a failed migration because of having to make inflight changes to the underlying configuration of either the application itself or the operating system of that virtual machine. Thank you very much for watching through this video you can find out more details on our website is icevalent.com and you can also click to contact to our team of experts through the website if you've got any questions or queries and we can also help you plan out your migration using our capabilities as well. Have a good day.