 How's everybody doing? Good. So before I start, a real quick show of hands. How many of you are, like, sysadmin, operate an OpenStack infrastructure cloud operators, OK? And how many of you are, like, managers of a group of people that run those? And how many of you are neither of those? What do you guys do? What are you doing here? No, I'm kidding. Are you developers? Developers? OK, cool, all right. Awesome. All right, so I just wanted to gauge who's in the room. Thanks for coming. My name's James Lobaki. I work in product management for solutions at Red Hat. And I want to spend a little bit of time today walking you through what we call the infrastructure migration solution, give you a little bit of background on why it is we're doing what we're doing, and then show you guys a live demo, spend more of the time, I think, on the live demo, and then answer any questions. So I don't intend to take all 40 minutes. I'll probably take 30, and then let you guys get some coffee. All right, so first off, just to summarize why it is we actually are doing what we're doing. This is just a little bit of background. What we are finding in most of our customers is that they're actually, this is their IT spending. It's a report from Gartner called Grow Run Transform. There's a technical conference, so I'm going to get to the technology very quick, but just hear me out. The big problem a lot of our customers are facing right now is that 11% of their budgets are being spent on transformation, and 70% are being spent on maintenance. So in a context of OpenStack, I'll ask it this way, you guys all, how many of you are running OpenStack-based clouds today? OK, so the majority of you. How many of you have virtualization outside of OpenStack that runs in your environment today? OK, so the 11% is what we would consider transformational with OpenStack, and the 70% is what you're probably spending on the existing virtualization footprint potentially outside of there, spending that's going on there. So the question is, how do we actually help you increase that 11% to a much larger number so that you can, instead of spending all this time maintaining your existing footprints, you can actually transform? And this is basically what we're finding is that customers get in these sequences where every few years they're renegotiating contracts with licensing, software licensing, particularly with proprietary vendors. And every three years, their capacity and their capabilities stay roughly the same. So maybe they get an incremental feature here and an incremental feature there, but their costs continue to rise much faster. And so the problem that we're intending to solve with the solution, and that I'll show you, is allowing customers to break that cycle. In other words, we can give you increased capabilities, increased capacity, and at the same time, we can level out your costs. So this is the intention of the migration solution as a whole. So what I do want to talk about is that this solution for migrating to OpenStack, and really, we have a solution to migrate you to basically a KVM-based virtualization, whether that's OpenStack or a scale up virtualization platform, is a journey. And so I want to walk you through what this looks like and then take you through the technical aspects of how we actually mass migrate virtual machines and then give you guys a demo. So the first aspect is what we call a discovery session at Red Hat. This is essentially just a one to two day session where the people from our organization that have done these migrations before come on premise sit with the application owners, the change managers, system administrators, and ask a laundry list of questions. So there's a templatized kind of questionnaire that we go through. It primarily focuses on the workloads, understanding what workloads are running in your existing virtual infrastructure, then understanding the requirements. How are they monitored? How are they backed up? How are you performing your day two operations? With that discovery session, there's a number of things that come out of that. But one of them is actually an approach document that actually shows how you can begin to migrate. So an approach document doesn't necessarily always mean you're just going to simply lift and shift your virtual machines from one vendor to OpenStack. It could be that you want to refactor your application into microservices and actually begin to re-architect the application. Secondly, we have a migration pilot. So what this pilot is, it's an eight to 12 week pilot that is led by our services team. It'll stand up up to 16 hosts of OpenStack and get it up and running with day two operations. It will configure the migration framework that I'm going to show you all. And it will actually migrate a subset of those virtual machines with you. So we'll show you exactly how to use the migration framework tooling and make sure that you know how it works. And then third is this migration at scale, which is ongoing. And this is what you'll do afterwards with the support of a Red Hat support organization. So we've had several customers with tens of thousands of virtual machines that have wanted to migrate away for the purposes of cost savings and the purposes of moving towards a more API-centric infrastructure in OpenStack. This started probably four years ago, where we started to see the demand for this. We worked with a very large financial services company to do this four years ago. At the time, it was entirely services led. So this meant that we actually had to build all the workflow and all the discovery of the virtual machines. Everything had to happen manually. And when you have 70,000 or 100,000 virtual machines, the return on investment is still there. You can hire somebody in services to do this and actually get a great return still for migration. But as you start to go to smaller and smaller virtual machines, it didn't make sense for our customers to have a consultant on premise for two years migrating virtual machines by hand. And so we began to invest roughly 12 months ago to build out the tooling that I'm gonna show you, which basically productizes the migration capabilities. This way, you can discover your existing virtual machines, you can migrate them, and then if you have a failure, you can call Red Hat for support. All right, so without further ado, how does this work? So the predominant platform that we support, migrating virtual machines for them, obviously VMware vSphere, right? Largest virtualization footprint on the scale up virtualization side from a paid standpoint. So the way this works is, again, as I mentioned, the customer, yourself, and a Red Hat services person will actually sit down and do a discovery of this, discover all your virtual machines. So this is a business-level conversation that happens, what's the uptime requirements, all the different requirements you would have around an application and a workload running on VMware at the time. And then essentially what we do is we architect our Red Hat OpenStack platform to make sure that it meets those requirements of those workloads. And it should be noted that sometimes we may look and say, hey, 10% of your workloads, you're just gonna leave where they are, you're not gonna migrate them, or there might be another platform beyond OpenStack that you need to move to as well. Then what we do is we deploy Red Hat CloudForms. So how many of you have heard of Red Hat CloudForms? Anybody? All right, so quite a few of you, but not all of you. So Red Hat CloudForms is a cloud management platform. We acquired a company called ManageIQ in 2012 now. It's six years ago. And when we acquired ManageIQ, similar to how you have RDO and the upstream OpenStack, we have ManageIQ, which is a cloud management platform, and we basically sell a subscription to Red Hat CloudForms, our cloud management platform. CloudForms is actually included with Red Hat's OpenStack platform, so it's not additional fee you have it if you have Red Hat OpenStack platform. And so what CloudForms does as a cloud management platform is it has a concept called providers where you can essentially add multiple providers. So it supports VMware vSphere, Microsoft Hyper-V, Red Hat virtualization on the infrastructure side. It supports OpenStack, the OpenStack under cloud, the infrastructure. It supports Azure, GCP, AWS. You can add all these providers and it basically goes out without agents and discovers all the assets in there. So all this discovery happens without any agents and you can actually do introspection of those virtual machines that are running for, in this case, in this example on VMware. So I could see all the way down to the process table, the MSIs, if it's a Windows box that's running on it, the users, all the information you need. This is really important because our consultants can actually use this information and you could use this information to understand which VMs you wanna migrate. So you can look in there and say, let me see, show me all the VMs that have SQL server on them, maybe we'll leave those, show me all the ones that have Tomcat, maybe we'll try and move those over to OpenStack, so on and so forth. So you have CloudForms, it's deployed, and what we do is we'll extend the VM networks from your VMware environment into your OpenStack environment. So the VM network in OpenStack will map to your OpenStack environment. Then what CloudForms will do is it will reach out to OpenStack. So let me pause for a second and just preface this real quick. So the technology I'm gonna show you today is actually all upstream. I figure it's okay, this is an OpenStack summit, right? And it's gonna be shipping in January. So what I'm gonna show you is an alpha, but you could pull it down from our upstream, and then in January it's gonna ship with OpenStack. So what happens is you wanna convert VMs, what you need is conversion hosts. So how many of you have heard of the tool VertV2V? Anybody? All right. So VertV2V is a tool that's included in Linux, and it basically converts VMs, right? It takes your VM from one image format to another, it'll replace the para-virtualized drivers, take care of any kind of tooling that you need installed. So if you wanna move from VMware tools to a QEMU KVM based agent in there, you can do that. So VertV2V gets installed in the OpenStack environment, and it gets installed via a conversion host. So a conversion host is a small image that we run inside of your project on OpenStack, and CloudForms basically can communicate with that conversion host. So we only need one instance of CloudForms, but you can have conversion hosts in each of your projects in OpenStack. So you could say, and per project we'll spin up a conversion host, and that conversion host is basically going to then talk to the VMware environment. I'll show you that in a little bit, kind of step-by-step, in a little bit uglier diagram that's a little bit more technical. So what's important though is that these conversion hosts, you can actually then, in order to talk to VMware, there's a couple of ways you can do it. You could certainly use SSH, so you can actually SSH to there and convert the VMs off of the ESX host via SSH, over an SSH connection, I should say. You could also use something called the VDDK. How many of you, does anybody know what the VDDK is? All right, it's the VMware Disk Library basically. The reason we actually pointed out here is it's proprietary, so we can't ship it with our software, otherwise we run into all kinds of problems, but you pull it down from VMware site and Ansible. There's actually, we have an Ansible role that you can execute on these hosts and it installs the VDDK for you. So now you have a conversion host running and you're ready to go. Then, inside of CloudForms, what we built is a little migration, basically some componentry that helps you map, actually execute your migration. The first concept is something called infrastructure mapping. So in order to execute a migration, we actually start to map the VMware infrastructure over to the OpenStack infrastructure. So in this case, we map clusters in VMware vSphere 2 projects in OpenStack. We map data stores in VMware to a Cinder backend. So this would be which Cinder volume type, for example, you wanna use. And then on the network side, which provider network you want to migrate the machines to. So you basically can build multiple infrastructure mappings inside of CloudForms. And then after that, you're gonna create a migration plan. So a migration plan is then how you're going to execute the actual migration. And here you'll see that the migration plan, you select the infrastructure mapping that you wanna use because that's going to inform which machines you can actually migrate. So what this is doing is making sure that once someone has created the mapping, you can only migrate VMs that will have the ability to migrate between those resources there. And then you execute the migration. So I'll walk through kind of step by step what happens there. But that essentially will then allow you to start migrating those virtual machines. So if you wanna take a little bit more of a technical view of this, sorry, it's a little faded for the boxes on here, a little washed out. But the user in step one would go in to CloudForms and basically configure the infrastructure mapping and the migration plans. When they actually execute it, what happens is step two, you basically, you know, CloudForms reaches out to VMware and begins to orchestrate the shutdown of those virtual machines. That's actually all happening with Ansible Automation underneath. So CloudForms uses Ansible Automation for the automation functions. And then what'll happen is you see the conversion project over there on the right hand side will actually reach out and basically talk to the ESX host and then begin converting this data store, the VM that's the disk that's sitting on the data store that will get converted directly to a Cinder volume. And so that Cinder volume, you know, is now, the virtual machine is converted. It's running all the proper drivers, so on and so forth. And then CloudForms reaches out to OpenStack and provisions the virtual machine for that and then connects that Cinder volume to it and basically mounts it up and runs it. So pretty straightforward, makes sense so far. All right. Okay, so one thing I just wanna mention is that, you know, what we've built is pretty prescriptive basically maps networks, data stores, and compute to projects, volume types in Cinder and provider networks. We find a lot of people asking like, can I also do X, can I also do Y? We have purposely built in pre and post playbooks, playbook support so you can leverage any Ansible playbooks for automation that you've built to do things. Like for example, if you wanna take a VM out of a load balancer before you move it, a load balancing pool, if you want to fire off an email to someone, make an update to a change management database or an IP address management system, you could do that there. So with that, you all look like you might have had a good lunch and not enough coffee, so I'm gonna transition to the demo. That's okay and then we could kind of open it up for questions. Can you all see this fairly well? Good. All right, so what you're looking at inside of CloudForms is the infrastructure mappings page. So this is the Cloud Management Platform CloudForms interface. There is a whole lot more than just migration inside of here but we're zeroing in on migration. Previously you would actually just go in and set up the providers to put your credentials in for vCenter, put your credentials in for your open stack tenants and all those sorts of things. Wait a second, that's why. We're at the end, that's not good. That would have made for a really short demo. All right, there we go. There's the full CloudForms. So you see it here, you have the entire menu on the left-hand side, a bunch of things happening but what we're gonna go into is focusing on migration. So you're gonna go to compute and migration and click on overview and the first thing again that we have to do is start mapping our infrastructure so we have to map those two together. So you're gonna hit create infrastructure, mapping and we're gonna name it. So in this case we're gonna migrate VMs from VMware to OpenStack so we'll go ahead and name it VMware to OpenStack and call this our default mapping. You'll notice that the target provider supports Red Hat Virtualization and Red Hat OpenStack platform so we'll select OpenStack is where you wanna migrate to and then the mapping is gonna begin. So here we're gonna grab our OpenStack cluster on the left-hand side, sorry our VMware cluster and map it to our OpenStack project. Second, we're gonna map our storage. So this is the data store inside of your vSphere cluster here and you're going to map it to the Cinder volume type that you wanna migrate it to. So you'll select those, add a mapping and then you'll map your networks. So here we have the VM network and you'll select the provider network. So one thing to note, we don't support tenant networking here. So we are leveraging provider networks. The majority of the people that we've spoken to when mass migrating VMs are not using potentially tenant networking, although it's something we wanna add in the future. So you go ahead and add a mapping for that and hit create. It's pretty straightforward but you'll see now we have an infrastructure mapping created from VMware to OpenStack and we can, if you click on that it would actually expand and you can see more details about it. You can edit it, delete it, all the things you'd expect. But in this case we're gonna go back to the migration page and now you'll see we can create a migration plan. So I'll create a new migration plan. You have to select the infrastructure mapping. So since CloudForms has discovered, let's say several hundred virtual machines in your VMware environment, in order to limit which VMs you'll be able to migrate and know that they will succeed, we actually, that's the whole point of having an infrastructure mapping. And then what will happen is you can actually choose to run, select your VMs from a list of VMs or you can import a CSV. So a lot of times customers have a large CMDB that they want to import VMs from so we'll have that as well. So you go in, in this case we're gonna choose, so we'll hit next. And since CloudForms knows about all the VMs on my VMware cluster they show up here. Only the ones that I could actually migrate. So here we have a database server and a couple of web servers. The thing to note is that when we hit next it's actually gonna take us to this instance properties. So what's happened here is we can actually set the security group that we want it to migrate when we migrate that we want it to be set into. And you'll notice that there's this little open stack flavor box. What happens here is CloudForms has a little bit of intelligence about the open stack flavors. So it's gonna choose the open stack flavor it thinks is best based on a very non-complex algorithm. Closest match, right? And then, but you can choose a different one. So if I actually wanted to migrate this to a large I could choose it here and then it would know what size to spin up to match and mount my Cindervoin to. So in this case there was a customized flavor called conversion host that someone created and that's what it's gonna migrate to. And you'll notice that little asterisk by the extra small. That's just indicating that that's too small. So if you select that you're actually not gonna get a very good experience we're assuming. Or you might because maybe they provisioned too much on VMware but. All right so you can select that here and then from here we can actually hit next. Well I think we've changed the security groups to web servers for two of these. And then I can go ahead and hit next and I'll get my advanced options. So in the advanced options you'll notice that you could select pre-migration playbooks and post-migration playbooks. So again you could then, and you could actually pick which ones you want to be on each server. So some of them let's say for every database server you wanted to run a playbook that queases the database and takes a snapshot you could do that here and actually have those done. So in this case we're not gonna do anything we're just gonna straight shut them down and run this. So again you could start the migration immediately or you could run it later. If you select run later you will then basically be given the ability to schedule it as well. You'll see here. So at this point we'll close this and you'll see I have my migration plan that's created. You can see that it's using the VMware to open stack infrastructure mapping. You can see there's three virtual machines in there. And then you could either schedule this for a later time or you could migrate it. These are also available via API so if you're using something like ServiceNow, Remedy, some ITSM system and wanted to give the application owner the ability to decide when they wanna migrate you could do that as well. And then from there we'll hit migrate. So what's gonna happen when you hit the migrate button is that flow that I showed you. CloudForms is going to reach out to vSphere. It's going to shut down the virtual machines if they're running. It's going to collapse the snapshots. It's then going to call the conversion host in the tenant that was there. And it will begin to convert those virtual machines via vert v2v and map them directly to a cinder volume. And then once that's, by the way, it'll also inject the correct pair of virtualized drivers, all those different pieces. And then it will actually, so you'll see here all three of them running and migrating at this time. And then what'll happen is this will, once that's finished through the magic of Hollywood, we are speeding up time. And you can see that those are converting here. The nice thing about this, you could actually mouse over the info button here. It'll show you the exact log file with the entire vert v2v output and all of those pieces right there. So if you have an issue, you could just pull that log file, send it to us. You could download the log straight from here as well. We've been doing a lot of work around some of the performance work. We were working with a customer in Latin America that's in the migration process. And they actually, they were using vert v2v standalone and some of the performance tuning that we did here. They said they saw a 10x performance improvement in throughput. Not only that, but we're now running these in parallel. So the way this will work is, I'll wait for this to finish. Each conversion host is limited right now to 10 VMs concurrent migrations. So 10 VM migrations at a time. It's a fairly arbitrary number based on some performance testing we did. You could, but you could spin up multiple conversion hosts. So if you wanted to do like a massive amount of VMs at the same time, not that I'm recommending this, but you could certainly pull that off if you wanted to. So we basically scale by conversion host for migrations. So here are the migrations have completed. If you were to go over to your open stack environment, those would be running in the tenant that you've now mapped over to there. So, all right. Let me see, let me see. So, let me, I told you I'd be fast. All right, so real quick. If you are interested in learning more about this, whether it's the low level V2V tools, the Ansible playbooks, all the way out to cloud forums, the business justification and business creation for why you'd want to migrate, all those different pieces, I would encourage you to reach out, just send an email to migrate at redhat.com. Somebody from our team will respond, whether it's upstream contributions or help with something that you might think is silly. We'd love to hear from you guys and know how we could work together to help move more workloads towards KVM and open stack. So, with that, let me, I guess, open it up for any questions? Questions? The question was can you move workloads between open stack solutions? Now, why would you want to do that? Open stack is great. I'm just kidding. So, no, that's actually a question we get very, very often. So a lot of people want to do this. Maria, who was here in the talk earlier, we've been discussing that. We think there might be some opportunities for that. So it's something we're exploring. We haven't done yet. As a first priority, we were trying to get workloads onto open stack and then between there. But there are a lot of partners of ours, I would say, as well. Companies like Highstacks, for example, that do replication of workloads that we have worked with in the past as well. And our services team also can help with that as well. So this is the productized. This is shipping in January. Our services team built something like this that basically they were calling it the migration factory at Red Hat. And it did most of what you saw here. It just didn't have support and a nice, as nice of a user experience as we built here. So it's still very possible to do that using that. Does that help? Yeah. So related to that, what about if you want to move a workflow from AWS to open stack or vice versa? Or even GCP? Yep. So migrate at redhat.com. I'd love to hear about any platforms like out. So right now the supported path is VMware to Red Hat virtualization, VMware to open stack. In our roadmap, we are actually going to take this to, I don't know, have any of you heard of the project called KubeVirt? Any, anybody? So KubeVirt is a Kubernetes project for running virtual machines. And our goal is actually to support migrations to KubeVirt. So you can actually migrate your workloads, still running on KVM, but orchestrated by Kubernetes. But outside of that, we've had a lot of requests for migrations from cloud stack, migrations from AWS. To date, we haven't really committed to any of those platforms, but I'd love to hear about the demand and what's going on. Or if you guys want to contribute, we'll take your patches. Thanks. Yeah. Let me get him real quick. I'll come back. Yeah, go ahead. That's me. What's that? Hey, the question is, is there any option to do this migration without any downtime? Yeah, it's a great question. So no downtime upgrades. Short answer is no. And the long answer is there is a lot of work that we have in the Virt V2V tool to minimize the downtime by doing some replication. There's work happening in, there's been a lot of work happening in change block tracking in upstream Linux and that sort of stuff that we're driving. So we are working on things. We don't have any intention of having zero downtime, but having minimized downtime is a goal of ours. Thank you. Yep. What's the story about rollbacks? So if, for example, one VM fails to migrate, is there an option to rollback back to VMware, for example? Yeah, it's a great question. The question, it was a little quiet, was what if one of your VMs fails to migrate in that migration group, what do you do? Well, the short answer is you don't panic. You just go back to VMware vSphere and you power on your VMs that were there. So we don't delete the VMs off the source side so you can restart them. So you basically shut that down and start it back up. Any other questions? Yep. Yeah, yeah, it's a great question. So the question is, if you have tags like, or characteristics of your virtual machine like CPU affinity or DRS rules or things of that nature, do they get taken into account? Again, this tool is really about mass migration and conversion of the disks. At this point, it's not in scope for us to do a lot of those extra, you know, kind of mappings, but that's where the pre and post Ansible playbooks come in. So if you needed to set CPU affinity, we would expect you to do that through like an Ansible playbook. The reason for that is there seems, one, we don't have a good grasp on how many workloads are using what at this point in mass. So we're trying to allow for a stable way for you to convert the VMs as a first step. But I think as we go, if we see there's a large amount of workloads with a certain pattern, we would certainly start to add it into here as well. Any other questions? Great. Well, I will be here if you have any questions for the next 10 minutes of my time. I intend to fully use it. I will just stand here. But also, thanks for coming. I would, you know, I'd love your feedback on it. And again, if you email us at migratoredhat.com, if you own OpenStack, you'll get this feature in January from Red Hat OpenStack platform. I'd love to hear how it works, how it doesn't work. And we could partner together and make this, drive some more workloads to OpenStack, yeah? All right. Thank you. Thank you.