 Hi, my name is Rhys Oxnum, I'm the Director of the Customer and Field Engagement team here at Red Hat. In this short video I'm going to be demonstrating the migration of virtual machines from Red Hat Virtualization to OpenShift Virtualization via the Migration Toolkit for Virtualization or MTV for short, a project based on the upstream conveyor forklift project. I'm going to be covering both cold migration and warm migration, enabling customers to have flexibility within migrations whilst also ensuring minimal downtime when switching over. For the purpose of keeping this video as short as possible, many sections have been sped up. In the demonstration environment we have Red Hat Virtualization, where we can see a single RAL8 virtual machine running, and also OpenShift Virtualization, where we can see a single RAL9 virtual machine running. We're going to be migrating this RAL8 virtual machine from Rev over to OpenShift. We've got a basic workload running on this virtual machine that simply displays a hello message from an end-to-next server with the current server address being shown. We'll use this to validate that our VM moves over and it retains both its workload, host name and also its IP address post-migration. The Migration Toolkit for Virtualization runs as a workload on a given OpenShift cluster and is deployed via an operator. Here you can see that we've already got this operator installed and that it's ready to go. If we navigate to the Roots and select the OpenShift MTV project, we'll see that there's a route created for us that takes us to the MTV user interface. In this environment I've only deployed the operator with a very simple configuration. I'm yet to configure any of the providers and therefore have to walk through all of the providers and the various mappings that enable the solution to determine how to map storage and networking interfaces between the platforms. Out of the box the operator will have to find the host provider, which is the cluster in which MTV is already running on top of. In this demonstration this will also be our target cluster, but it can also act as an intermediary between clusters if required. MTV shows that there are a number of storage classes to find, as well as a number of networks that have been discovered on the host cluster, and we'll be able to generate mappings to these, noting that our OpenShift environment has been configured with a data center network that bridges virtual machines onto the corporate network outside of the SDN. Next we'll add a new provider. Currently MTV supports three different options, VMware, Red Hat Virtualization and OpenShift Virtualization itself, as this tool can be used to move virtual machines between OpenShift clusters too. As this demonstration is targeted at Rev, we'll select Red Hat Virtualization now. Now we have to provide some additional configuration information, so MTV can connect to the Rev API and be able to scrape the necessary information, as well as pull data out. We'll give it a provider name, add in the host name of our Rev Manager, a username and password that will give us access, and finally the CA certificate, so we can verify that we're talking to the right endpoint. After a minute or so this will be validated and it will start to populate the necessary information about the environment, number of hosts, virtual machine count and so on. Now we're ready to add some mappings, and as we said before this will define some of the out-of-the-box mappings that map storage and networking constructs from the source environment to the target environment. For example, if you had a VM that utilized NFS based storage on Rev, but you wanted it to automatically map to using Ceph on OpenShift, we can define that mapping here by leveraging an available storage class. And the same for networking, if we utilized a VLAN tag network on Rev, you can map it to the equivalent configuration provided by a network attachment definition in OpenShift. We'll first define the network mapping and we'll give it the name of RevM Network. We'll then choose our RevM PemLab source provider and select the host target provider. This will then dynamically populate the network lists for both, allowing us to choose the appropriate configuration. We have a very simple configuration in the demonstration environment where our Rev-based VMs utilize the overt management network. And we've got an equivalent data center network that's been defined in OpenShift that will put workloads onto the same layer 2 network. So I'll make this mapping now. Now we've done the network mapping, I'll move over to storage, and it's much the same thing. We'll give it a name, we'll select the source provider and the target provider, and we'll attach our simple hosted storage from Rev as the source, and have that map to the Ceph RBD storage class on the OpenShift side. Now we've got both storage and network mappings complete. At this stage we're ready to start our first migration. For this we need to create a migration plan that will pull all of the providers and mappings together into a definition of what we want to migrate. We'll select migration plans and then create, where it will ask us a number of questions. First we have to give it a name, noting that with MTV it's possible to migrate multiple VMs at a time, but for now we're just going to migrate a single VM, so I'll call my plan rel8-vm migration. I'll select the source as the rev environment and the target as host, which is OpenShift, and then select a target namespace for my VM. This is important as VMs are namespace scoped in OpenShift virtualization, so I need to make sure it ends up in the correct project, which for me will be default where my current rel9 VM resides. Then I'm given the option of selecting a different network for the data migration, which I can leave as the pod network for now. On the next page I can select my virtual machines that I want to migrate, and MTV will have already scraped a list of VMs from the rev cluster, and I'll select the PEM lab data center in my rev environment, and you can see that it is noted two potential virtual machines to migrate. On the next page it shows that there are two virtual machines that could be migrated, the hosted engine, which is the rev manager itself, which we'll ignore, and the rel8-vm1 virtual machine that we do want to migrate. MTV runs a migration assessment, which highlights potential issues that may arise when migrating virtual machines onto OpenShift, where it shows us a warning for our rel8-vm. If we expand that it shows that there are some simple issues that won't block the migration but are perhaps something to be aware of. Let's now make sure this virtual machine is selected and we can proceed further. We can now select our network and storage mappings that we previously configured, which it will give a visual indication of the configuration to ensure it's as we expect it to be, which in our case everything looks good. It will then ask us for a migration type, where we choose between a cold migration or a warm migration. A cold migration is where the source virtual machine is powered down before the vm data is migrated and then is started on the target platform, whereas a warm migration keeps the source vm running whilst data is copied in the background, enabling a quick cutover to minimize downtime between shutting down on the source and booting on the target. We'll start off with a cold migration, then later we'll rerun the migration with the warm options afterwards. Next we'll ask whether we want to run any ansible hooks, which could be useful if, for example, a cmdb needed to be updated to perhaps reference the location of the virtual machine, or some kind of ticket needs to be created. All of this can be configured here, but we'll skip this for now. Finally it'll take us to a review page where we can make sure everything is in order. I'll select finish as it all looks good. We're then taken to the plans page where we can see that our plan is in the ready state, but it isn't automatically started. We can now trigger it by clicking the start button on the right hand side where it confirms that the source vm will be shut down. On the OpenShift side we'll see that an importer pod is spawned in the default namespace, which is responsible for all of the data transfer out of rev and onto OpenShift. If we watch the log files for this pod we can see that the progress is being outputted to the console. If we then switch over to rev, we'll confirm that our vm has been shut down, so it's safe to pull the data over, and if we look at our workload we'll see that it's no longer responding on the IP address, so it's definitely offline. If we revert back to the MTV console, the status will update automatically and it will highlight the amount of data being copied over and that the disk image is now being converted for compatibility reasons. Examples here could be ensuring that the correct drivers are installed into the guest operating system. When we navigate back to the OpenShift console we can see that our vm is now starting up and the importer pod is showing as complete. The virtual machine's boot up progress can be watched by the OpenShift console, showing that it's coming up as expected. And if we attempt to contact our workload again we can see that everything is migrated over as expected. It's still responding on the same IP address. Finally if we revert back to the MTV UI, the migration now shows as complete and we also have the option of pulling down all of the log files just in case we have to troubleshoot any failures. So that's a cold migration. Let's rerun the migration but let's do it warm to demonstrate the difference. I'll just clean up the environment by deleting the virtual machine on the OpenShift side, restarting it on the rev side because it was never deleted, and we'll remove the migration plan on the MTV UI, meaning that we're basically back to where we were before we started with the cold migration. Now I'm going to quickly run through the creation of a second migration plan where it will be almost identical to the first one but we'll use the warm migration type. Like before the migration plan is ready and I can start it. When I select start it will ask me whether I'm ready to start the incremental copies. Behind the scenes a snapshot of the virtual machine is being taken on the rev side allowing the snapshot data to be migrated without affecting the running virtual machine. We then take regular snapshots every hour to minimize the amount of data that would need to be migrated, enabling the administrator to cut over or in other words quickly stop the VM on the source and start it on the target in the quickest possible time, minimizing any service interruption. We'll hit start to get this process underway. After a few seconds we'll see that the incremental data copy count has increased to one, and if we navigate to the rev console we'll see that we have a new snapshot that has been taken of our virtual machine. In OpenShift we'll see a virtual machine in the provisioning state and like before an import apart is running, pulling the data from the snapshot this time, all whilst the virtual machine on the rev side is still running uninterrupted. All of this data is being pushed into a persistent volume claim residing on self-storage as per our mapping request. After a few minutes we'll see that the migration plan status moves into an idle state where it will schedule a further incremental copy later down the line to allow us to choose the cut over time. We'll force mdb to cut over right away by selecting the cut over button and opting to start it right away rather than scheduling it for later, for example during a maintenance window. What we'll see is that the virtual machine will be shut down on rev and when it's gracefully shut down it will be started on OpenShift virtualization. Again we can see this virtual machine come up by the console and if we refresh our workload we can see that it's immediately responding to our requests. MTV also shows that our migration was successful. So that concludes our demonstration today thank you for watching I hope that it gave you a better understanding of the migration tooling available for OpenShift virtualization.