 Hi, I'm Martin Etchos. I work on migration toolkit for virtualization. Before I will start the full talk, I want to introduce or give you an image of who this talk is for. Let's say that you are an sysadmin. You maintain some virtualization, vSphere, redhead virtualization, Overt, whatever enterprise level virtualization. And you want to move to the newest thing, OpenShift or Kubernetes. And first thing, you have all your infrastructure set it up in the virtual environments. So you need some way to migrate your VMs to the OpenShift. For that, you can use this tool. And you can use this CNV, container native virtualization, which is VMs inside containers. Because migration toolkit for virtualization is kind of mouthful, I will call it MTV throughout this talk. And if you want to check out the source code, the upstream name is Forklift. Previous engineers had really interesting naming systems. And what it does, either from VMware vSphere or redhead virtualization, migrates VMs to the OpenShift. Currently, we have a few engineers working also to include OpenStack, work in progress. Hopefully, it will be finished in a few months. You can install it with OpenShift operators. It comes all in one solution that you install it and sets up everything for you, configures all your CRDs, which are objects which you can configure and see what is displayed. Throughout the talk, we have named for the providers, which either provides the source or the destination where we want to migrate the VMs to or from. So when we install the operator, it sets up all the ports, services, all in one solution. When we want to use it, currently, we have our custom UI running in port. We have a few people working on integrating the custom plugin to the OpenShift. So when we want to start, we want to set where we want to migrate from. We can choose either from the three solutions, and it's only one direction. We cannot move VMs from CNV to OpenStack or VMware. So in this example, I'm adding ref. The quality isn't perfect. I'm adding a ref provider with the address admin user so we can log in and gather all the information from it. We get all the clusters. We list all the VMs, the necessary information about them, the storages. So we added a provider. Now we can create a migration plan itself. After we can choose from which source to which target, from ref provider to host. By default, when you install the MTV, the OpenShift cluster, which is installed on, it's added by default with name host. And you set the target namespace where you want your VMs to be migrated. We have also a validation. It validates when we gather the VMs, we check if they can be even migrated and in what way they will be affected. If the migration, for example, names are correct and we do all sorts of the checks. We need to, some way, to map the infrastructure itself. We need to map the storages, which storage goes to where and which networking goes to where. We need to say here, we have network mapping, so we want over management system to pod network. Those are both defaults. Or I have a storage domain in a data center named test, original name. And I have pre-created a storage class inside the OpenShift. So I choose it for here. We have multiple types of migration. It's either cold or warm. The cold migration itself, it shuts down the VM and copies the data. And that's the most primitive and, like, trustful. If you want to minimize downtime, you can use the warm migration, which creates a snapshot from the VM. It's still running, moves the snapshot data. And after some time, after it's migrated, it creates another snapshot and checks it's incrementally migrating the VM. And on the last time, last time when it does it, it shuts down the VM, moves the last data to the cluster, minimizing the downtime. In this example, I choose the cold migration. There are also possibilities to add ansible webhooks. We can add some tasks, which we want to do before the migration or after it, some cleanup, or changing the host names, whatever we want to do in the VMs. In the end of the creating of the plan, we have some review, what we are doing, that we have selected just one VM, but where from, so on. It created the migration plan. Now we can start it. And the migration itself creates an empty VM inside a CNV and starts moving the data from the provider to the CNV. For the vSphere, there are some problems that we need to use the word v2v to change the host. And in the end, we have running VM inside the OpenShift cluster, which was previously running on the Overt. Our current plans is to replace our custom UI with OpenShift plugin. And adding some 4.4 compabilities and adding the OpenSec, which I mentioned in the beginning. This is the example of the console, which our engineers are working on right now. And that's everything from me. Anybody got questions? Oh, OK, sorry. Can you hear me? Yeah. Yeah, so at the very beginning of today's DevConf, it was mentioned that the application should be aware that it is running on Kubernetes. So how does this toolkit solve that whatever we are hosting on our virtual machines is going to be aware it is running on Kubernetes? Yeah, when we install it with the operator, we check on what system it is installed. You can, of course, install it without the operator itself. You can install. Those are just pure ports running nothing special. The operator just makes everything easily. We have also written the operator for both of them. So it should be working. OK, so basically this toolkit is for moving Kubernetes from another solution to OpenShift, right? Yeah. Oh, OK, get it. Sorry, I misunderstood first. Anybody? Oh. OK, I have another question. What do you show the uncivil hooks? Is it possible to use some public repo and reference to some Git repository where you store uncivil playbooks and not just copy paste the uncivil playbooks or content here by hand? Very good question. Currently, no, but that's interesting suggestion, which I will suggest to our team to implement it. Currently, either you can paste it or pass the custom container image. It's not what I would do this, but I am not. I understand. Very skilled with container images, so. Yeah, go ahead. Will this work on just generic Kubernetes with Qvert installed or it's just the OpenShift variety plus CNV? It works also on the Kubernetes with Qvert installed. For example, our CI test, which I'm working on right now, it's not even Kubernetes itself. We are working on KIND, which is Kubernetes in Docker. Pure installed Qvert, and the migration works without problem. And one more question I do not understand. So this warm migration that you've covered, does it shut down the VM in the end or still? So yeah, it will shut it down and turn it on. Yeah, it shuts it down. The difference between cold and warm is in the cold migration, or in the warm migration, we are trying to minimize the downtime. Thank you. I wanted to ask if you tried to use OpenShift console or any UI in native Kubernetes? Yeah, well, we have working engineers on it right now to implement the plugin. You mean to make it working in native Kubernetes? Not in native Kubernetes, in the OpenShift itself. I think it is already implemented. I don't know. The UI goes completely out of my scope. No, I just wanted to say that I had issues trying to run OpenShift console just because it is the single UI, which you can use for Qubect right now. And it wasn't working for native Kubernetes. I would really like to have any UI which would work in native Kubernetes, not only with OpenShift. Thank you. This is just feedback. Anyone else? OK, thank you, everybody. OK, thank you very much.