 Okay. So thank you. So we're going to go over the migration of virtual machines from, in this case, we're going to demo VMware. But the tooling that exists via Fortlet will take you from VMware, OpenStack, or over Red Hat virtualization into OpenShift virtualization. So here is what we're going to talk about, what is Fortlift, what it does, how you do it, the architecture, and then also we're going to demo it real time. What is Fortlift? A tool that accelerates the re-hosting and re-platforming of VMs. So taking a VM from vSphere, moving it over to your OpenShift virtualization cluster. The upstream product is called Fortlift, and Red Hat's packaging of that is called MTP, or Migration Toolkit for virtualization. And as I said, what it does is take those VMs from either of those platforms and move them over rather seamlessly. And they're still shut down involved there, but move it over into QBird or OpenShift virtualization. And we'll go over more details of how that works. So if you have an existing Kubernetes or OpenShift cluster, it's as simple as installing the operator, the MTP or Fortlift operator, and you create a mapping between your vSphere or VMware networks, map them to your OpenShift networks. Do the same with your storage, map your storage, you have multiple different storage platforms, you can just map them how you need them. And then you create what's called a plan, which defines that, uses which VMs you want from which vSphere, and then kicks off the migration to move them over. And we'll run those plans and we'll see how to do that shortly. Here's kind of a quick overview of the architecture. And you see we've got vSphere on the left, OpenShift bird on the right. What lies in between there is the Fortlift or MTP, in this case. We'll go a little bit further into what all those little boxes are in the middle there. So here's the first flow of this process, right? As the end user, you're going to create that virtual machine custom resource. The controller then gets the config and the source VM properties, brings it all in, validates everything, makes sure that you can bring that VM over, there are no issues with it, etc. It'll stop the VM at that point. Then the import controller will create the blank VM, right? And then the VM for it to then migrate that data into. And then for each of those VMs, it'll mount them up, copy everything over into the physical volume. And then after everything's transferred over, it'll shut down. We're not there yet. On the conversion pod to convert. So in VMware, you need a VMDBK software development kit to convert to the KDM process that we want on OpenShift bird. And then it was running on the source provider. It's going to shut it down, bring it up on the destination and fire it up again. If it's in a shutdown state on the source, it'll remain shut down on the other end of things. So requirements for work with the gotchas to look at. This is specific for VMware, but most of these apply either way. Addable version of vSphere, that's helpful. A user, so the API will hit the API of vSphere. So you need a user that can do the appropriate tasks of shutting down a VM, starting it up, etc. You'll need to, if you want to do what's called a warm migration, which would be... So there's two options, cold and warm, and we can go over both in the demo. The cold will shut down that VM, copy all the bits over, bring it up on the destination. Warm will take a snapshot of the running VM. Do you realize that snapshot? The copy overall, the majority of the bits. And then when you're ready, you just hit cut over, and then it just takes the change, the dead between the two. And copies are remaining over, so you can do a little faster cut over at that point. So like I said, you need that VDDK image. You'll need the Shalom fingerprint from the vCenter host, and I'll show you where all this gets set up. And then there's some limitations of, you know, if you're migrating more than 10 VMs, you need to increase the memory, hibernation, you want to shut that off, and you need to unmount any ISOs or CD-ROMs from there. So performance obviously comes into play. We recommend 10 gate nicks at a minimum. vSphere is faster than using ESXi as your endpoints. And then if you have lots of VMs and you can spare the hardware, then scaling out the number of compute nodes so you can get more compute nodes sending their data over, because each would be limited for compute nodes. And here is kind of a quick indicator of version and what either endpoint and how quickly those transfers happen. So these numbers here are for roughly 50 VMs transferred during that time frame. You can see how the number of hosts as you increase, duration comes down, throughput rate goes up. The supported versions, so with the latest version of MTV is 2.4, anyone open shift for 11 or later, and vSphere at 6.5 or later. One of the, when you list the inventory from VMware of your virtual machines, you're prompted with what you see on the screen there is a warning. So there are rules that are created through open policy agent. And it comes with the policy, you can add to them, they're customizable. But it'll check for certain things. Like here we see CBT, the chainsaw track is not enabled. So with this particular VM, I wouldn't be able to do a warm migration. And then UFI is also just kind of warning us there, right? For the secure boot part of things. And we'll see this in real time as well. So enough of boring slides, get to the good stuff. All right, so here is an open shift cluster. Should be familiar from Darren's demo earlier. I've already installed the operator in this environment. We know that because I've got this little migration tab on the left here. So if we look at that, the first little tab we look at is the creating providers. I've got this provider created under a different namespace. It's here, the empty name space. So the host in this case is our open shift cluster. We've got one provider currently configured, which is VMware. We've given it the vSphere endpoint. And it's been able to pull based on the API and the username, et cetera, that I passed it when it created this provider. We've got 15 VMs running there, two networks on a single compute host. So since that's all there and ready to go, the next step is to create a plan. This is what defines your migration. So we'll call this open infra. Here we choose our provider. In this case, we're going to go from VMware and we're targeting our host, which is our local. And then we're going to put it into the open infra demo namespace. And actually one thing worth noting here, the migration transfer network is the pod network. If you had multiple networks and if you have a large off environment, it's worthwhile to have that separate network transfer everything over an additional separate network. So you're not stepping on other productive traffic or controlling traffic. In this case, it's small, easy demo. We'll just leave it on the pod network. So here we have our data center from vSphere. So if you have multiple, you can choose where you want to go with it. Your 13 VMs are listed there. Next, here are the VMs. And specifically, we'll do this Paul H test right here. When I drop that down, there's the warnings that I showed earlier, right about CBT not enabled. This warm demo VM right here. Look at that. You will see that it doesn't have the CBT warning there because I've enabled CBT to do that warm demo. I was able to differentiate that and give you a proper warning. In this case, let's just do our single instance. Next, now this is where we're going to map our VMware network to our OpenShift network. So creating network mapping. We already have our OpenShift network that's on from the VMware side. And we're just going to put it onto our pod network in OpenShift. We can save this mapping if we're going to redo it over and over again. We can save it as a template, VMware and click next. Next, we map the storage. We don't have one stored. So we've only got one data store on VMware, data store two. And then these are the data stores available to me within OpenShift, within our OpenShift cluster. In this case, we'll do our setRBD. But if you had a net app or pure storage or some other backend, those would all be available there as well to map the storage to. For virtual machine diffs and any additional disks that were attached to that virtual machine can be pulled out of that storage. Okay. You're too often the cold or warm migration. In this case, we'll do cold because again, it's telling us that it will fail otherwise. Here you can add hooks. This would be an ansible playbook that could be run post or pre-installed. So if you had some extra customization after the migration, you can run them post migration, and it'll just kick off that playbook and do whatever you desire. And here's just kind of our little overview of what's happening, right? This is finished. So now we have a plan. Nothing has been kicked off yet. This is just the plan. You can have all your plans pre-staged and then at any given time, just go and kick it off. So here we'll kick this one off the start. Tell us it's going to shut down on the VMware side and kick it over. And we'll see here the status should kick on here in a sec. There it goes. Some initializing. And while that's going, let's do another plan for the warm migration. Again, we choose our providers, our target namespace, and our same data center. In this case, we want our warm demo. The warm gives you some more options of when you want to do that cut over. All right, that's all good there. More storage. Here we'll choose warm. Do everything and go. So if this one is still running and check the status on it, it's copying the disk right now. Go back and we start this warm migration. What we will see is it's going to do that preparing for incremental copy. So it's taking a snapshot of the virtual machine. It's going to then let the virtual machine continue running. So the workload runs. Everything's great. We'll get, once it does this initial snapshot and copy, we'll get prompted to if we want to do the cut over. And then we can schedule that cut over if we so choose. So here it is copying the data over. Go back to our plans. This one is still going. Be pretty close to finishing there. You know that it's going to still running performing incremental copy. While we wait. Any questions? Service. Comments. Can you move anything to open stuff? Yes, you can. Thank you, Chris. Three platforms that are available, which I think I mentioned earlier, but VMware OpenStack. So you can migrate all your OpenStack VMs into OpenShift, as well as over or Red Hat virtualization as well. All process remains the same. The only distinction between VMware and say OpenStack or over is VMware requires you to have a container image of their VDDK software development container. That has to be in a repository that can be pulled into OpenShift so that I can do that conversion of the disk image. How about moving between two OpenStack environments? From VMware to OpenStack. VMware to OpenStack? I wish. There is no easy path there, unfortunately. So we can see here, this one has succeeded. And if we go over to our virtualization side of the house here, change our namespace to OpenInfra. You'll now see we've got a running test VM that's been moved over. And we can go. We can see our little console here. Eventually. Yeah, so it's still booting up there. Now if we go back here to that one. All right, so this has done the incremental copy already. We've got this cut over now. So every hour by default, we'll take another snapshot and copy the delta between the two. So it's ready to go. It's customizable if you wanted to change that time frame up down every light. You can do that. So now when we click cutover, we've got our choice. We can schedule it for later. You want it to run in the middle of the night when everybody's sleeping. So no one complains. Do that cut over for any date and time you'd like. Okay. So let's just go ahead and cut it open now. So because all that data is going to cut over the transfer is going to be a little faster than it was on the cold migration. So a little less downtime for your end users during that migration. And it's going to go through that same sort of process answering the disks, et cetera. And then we will see it pop up into here alongside this instance. We can see the node that it's been dropped onto as well as this new IP address that it's got. It will maintain the same MAC address between your source VM and your destination VM. That address is dependent on your network. And how it's configured if it will reuse the same one or get a new one as it moves over. And that is pretty much it while we wait for this. So any questions? I've got two minutes and 15 seconds to spare. Hold on. There we go. I just want to stay up here to finish. We trust you. No. It's done now. It will be done.