 Hello everyone, my name is Alessandro Pilotti. I'm going to talk a little bit about migrating workloads from VMware to OpenStack, okay? How many of you guys have a VMware environment? Okay, how many of you have an OpenStack environment? That was a kind of a rhetorical question since we are an OpenStack summit, but hey, okay So so first one important thing. This is actually a very short lighting talk Well, it's like 10 minutes, but we have another full session tomorrow That's actually about the same identical topic. So this is kind of like the teaser That that will basically explain a little bit of the concepts that we will be able to talk a little bit more in depth tomorrow with Them or something else, okay? 5 30 p.m. Room are 312, okay Okay So the context How many of you guys are moving from VMware to OpenStack? I mean migrating workloads, okay? Okay, good so a lot of people are asking how to do it what is the best approach and If they decide actually to move the entire virtual machines, how should they automate all the process? Okay, so that's something that we went into a lot of times in our in our career Let's say doing open stack is probably lots of you know us from You know the Windows related workloads in OpenStack, right? So that's where we started and that's where we we arrived at doing this specific type of activities So there are quite a lot of options that you will see pretty soon The important part is that companies are moving from a traditional way of Interpreting let's say the way in which operations have to run in either company to two model way Let's say a DevOps way of doing it Let's say the path that we are having is from physical servers VMs. So that's what happened typically now 10 years ago or more and then from VMs to infrastructure as a service Which is actually the part we are interested with in this moment So the VMs in this case I mean VM work system center in also traditional virtualization to say so an Infrastructure as a service in this case is OpenStack, right? then from there without content containers and of course what most people talk about today is the serverless model now So applications which don't rely at all on something which resembles somehow a server think about a Azure service fabric or things like this The typical thing that everybody will tell you if If you ask them, hey, how should they move to OpenStack the answer is well you rewrite your applications Which is very easy to say but a little bit more complicated if you have like 20 years of investment in some land-of-business applications In the end what we care about is to improve your total cost of ownership, right? You're TCO So why migrating workloads? Well TCO as we just said you might have a new on-premise cloud infrastructure So you simply have some old hardware you move to some new hardware to some new hardware and you have you know some new technologies that you want to deploy there You might move from on-prem to public cloud, you know So when the public cloud arrived a lot of companies moved workloads to from on-prem is let's say physical service of Windows machines over to our machines to To Amazon for example or to Azure or okay now to our cloud GCE and son Vice versa you might have public cloud on premise. There are a lot of reasons to do that and Of course, you might also have an on-premise redeployment. So a lot of people are asking. Well, I have OpenStack Let's say kilo. How do I to move to to meet a cut to Newton to a cut our to pike tomorrow? No, so then migrating from or moving from one one version of the other of OpenStack The next contiguous version. So let's say from Newton to Ocata, for example, it's well documented and relatively easy Okay, quote unquote, but moving from a Version which is older gets more and more complicated to the point that moving from for example from kilo to Newton It's an absolute nightmare. Okay, unless you want to do all the intermediate steps So we have quite a lot of companies which come to us and say well, how how do I do that? You know, and then I Will show you some of the options that we have in mind so I took this picture actually from Steven Orwell from Amazon because I think it's very clear and on what you can do from from From a migration perspective I will get into details tomorrow about the various options, but Let's just say that the ones that we are caring about are the replatforming and rehosting Replatforming basically means you take your applications and you Re-transform them in something else think about the past Containers and something else. Okay, again, we have only ten minutes. So tomorrow we'll get into details on here But for now just take it as an option Rehosting consists in taking your virtual machines Moving them to the target and put them there. No Which is what we are talking about during this very short session Coriolis is the project that we did for that. It's called migration as a service It's a fully automated lift and shift migrations from and to any cloud slash Virtualization solutions. So it's not limit only to VMware in OpenStack. It can do a lot of other things It's meant to be scalable. So doing one migration or a thousand at the same time really doesn't matter Well, honestly, if you just have to migrate one machine Well, you can do it manually, right? If you have to do a thousand well, probably your time is better invested in doing something else It has a it has to have a fully rest API for full automation So it has to look and feel like an OpenStack service and It has to have a keystone identity management because most probably will have you users tenants and so on So here is how the architecture works So this is taking from our website cloudbase.it You have a rest API You have a client, which is of course a common line or a GUI that I will show tomorrow Then you have keystone that will provide you of course a token after you get successfully authenticated and then from there all the internal components are talking via MQP Now so you go to a conductor the conductor will talk to a scheduler and all and then the conductor will talk to some workers The worker processes will talk to a source cloud and a target cloud in our example to VMware and to OpenStack Okay Supported cloud virtualization solutions while OpenStack any hypervisor Azure AWS vSphere Hyper-VN system center send server over it Oracle VM and will add also GC pretty soon How to use it well, there is a common line interface as we already mentioned and a web UI again demo tomorrow and Let me go back to the diagram for a little bit of additional explanation here So what's happening is basically that the initial worker will connect to the source machine to the source or environment Ask information about the virtual machines you want to migrate Get all the details about for example a disc which are attached the networks and everything and pass it on to the worker on the target The worker on the target will recreate the volumes for example in OpenStack for each one of those discs and There would be a process that can either take the entire disc Convert them on the fly for example from VMDK to QQo2 and send them on the other side or In a smarter way It can use a temporary virtual machine running here fully automated that will receive the data streamed over SSH here and it will Didi them directly into this here. So that's actually the most fastest approach. We have as you will see pretty soon Secrets are stored in Barbican. So no password for connecting to source or target cloud will be leaked additionally There is another thing that will allow you to have disaster recovery as a service this consists in Using the backup API that the source cloud can provide you To extract the data and move them to the other side. Okay, so for example in Vmware case we use change block tracking So we take a snapshot Which is typically up consistent and we ask Vmware to give us only the blocks that change since the previous Replica process how we call it. No, we take those data. We moved them to the other side and then we are pretty much done The last thing that we do Is what we call internally OS morphing So what's happening basically is that you have a full copy of your data on the target side But that machine will not be able to boot because it's configured to run on Vmware So it won't be configured to run on on on KVM on the other side, okay So sorry if I go very fast and explain these things but again the time is short again tomorrow We will talk into details about this What's happening now is the OS morphing part? We boot a temporary Vm. It's attached to that we attach those discs those volumes and We run some scripts inside of the Vm which will look into the discs Mount all the possible partitions even if you have LVM or whatever else and and look for an operating system and then based on the operating system that this process will find Execute a given series of commands. So let's say that for example, we find a Red Hat 7 or Windows 2012 for 2 on a Ruboon 2 16 or 4 or whatever else now We will perform a given set of operation for example for red hat We will rebuild all the in it are these because you will have the virtual drivers on one side And you have the VR tools on the other we remove the Vmware tools We reconfigure the networking so that the interfaces will have the same name We reconfigure st Linux so that the machine will be able to boot We will inject cloud in it because of course you don't have it on the source and a lot of steps imagine if you Google for How do I migrate? How do I move a machine from Vmware to open stack? You will find all these steps which here are fully a completely automated Okay, that that's the main idea. I will show your demo tomorrow if you guys will join of course It will take some time to run it Last thing and then we are done You can do validation and testing so that to make sure that your machine will run and You will be able to have a full business continuity because the machines on the source cloud are continuously working Because the backup operation will not oblige you to shut down the machine and with this I ran out of time So, thank you guys