 What's the warning? All right, good afternoon, everybody. Welcome to the session, Moving AWS Workloads to OpenStack. This is a topic that comes up a lot, because in a lot of ways, OpenStack feels very much like a free alternative to Amazon, the same way that it feels kind of like a free alternative to VMware or a free alternative to anybody else is going to charge you a bunch of money to host your content out in the public cloud. The problem, of course, being once you discover that your developers have half of your company's production out in these public clouds, you realize that maybe that's not such a terribly great thing, and you want to bring it back inside. Now, how many of you are sitting here thinking, this is going to be a really short talk. He's just going to explain how I can import an AMI into OpenStack? Wow, I expected way more hands than this guy, and I know he's lying because he helped me put this together. So unfortunately, that ain't how it works. I thought that was how it would work, and I spent a great deal of time trying to figure out why I just couldn't find the instructions for doing that. It turns out it is not that simple. So just to kind of give me a little bit of a lay of the land here, how many of you are primarily OpenStack people? OK, and how many of you are primarily AWS people? Good, because that's what I assumed when I wrote this. OK, so let me talk a little bit about, why I can't get my slides to advance. Hang on, we have a, oh, cute, a little technical issue. I'll talk a little bit about me while my presentation comes back up. My name is Nick Chase. I work for Morantis, in case you couldn't tell from the incredibly subtle t-shirt that I'm wearing. I am the head of technical content, and also, oh, there's why it wasn't working. I am the head of technical content, and also the editor of a weekly newsletter called OpenStack Now, where we go through all the news of the week, and a mind-bogglingly large amount of content every week. Also, I've been a programmer for longer than some of you have been alive, not you, but some of you. I've also written a few books and stuff like that. So I know who I am. But also, I want to give some special thanks to Darren Sorrentino, who helped me out here. I had nothing to do with this. Yes, Darren had nothing to do with this part. OK, hold on. We'll just wait a minute. Yeah, to Darren Sorrentino, who is now with Vion Corporation for some, well, actually, he wrote the run book on which a lot of this was based. So what we're going to talk about here, if my presentation, there we go. Thank you very much. We're going to stay in edit mode here, because my computer hates me. And right now, the feeling is totally mutual. So what we're going to do here is we're going to start out by talking about OpenStack for people who are mostly familiar with AWS. So if you're coming from the AWS world and you're going, I know I need to know this OpenStack thing, but I have absolutely no idea what this is all about. We're going to start out with that. And then we're going to talk about some easy ways to go ahead and move your workloads that are sitting in Amazon over to OpenStack. I didn't. Why do you have it? OK, excellent. Hang on. We're just going to pinch it here for a second. Anyway, while we're pinch-hitting here, so we're going to talk about some easy ways to make this transition from AWS to OpenStack. I really actually do know what's in the presentation. And then we're going to talk about doing it the hard way, actually going and doing the hard work of taking your workload, taking your VMs, and physically, manually, painstakingly, rip your hair outingly, moving them over to OpenStack. OK, so that's what we're going to talk about today. So let's start by talking about some of the different projects. So if you're not familiar with OpenStack, it consists of a group of projects. And by the way, the slides will be available online, so you will be able to see all of them, all at the same time, or at least on demand, when we are all done. Anyway, so OpenStack consists of a bunch of projects. For example, most of you who are working with AWS will be using EC2, which is compute services. That's where you get your VMs. In OpenStack, that would be NOVA. The NOVA project is what you use in order to create VMs. If you're using S3, the corresponding project would be Swift. If you're using EBS for block storage, the corresponding project would be Cinder. Basically, I shouldn't say most. Probably about 1 third of the projects that there are in AWS have a corresponding project in OpenStack. The identity management, we have Keystone. Even the NoSQL database, there's MagnetoDB. Oh, thank you so much. So there we go. There's Container Service. So you see here we have Magnem, which is the new container service within NOVA. You can use Kubernetes through Morano. There's the Trove Database as a service, CloudWatch. We have Solometer for monitoring. CloudFormation is probably the most germane in this case, which CloudFormation, of course, being the AWS orchestration service. Here we have Heat. And then some other sort of miscellaneous components. You've got the queuing service. You've got SWF, the workflow service. We've got Mistral. And of course, the management console for all of this, you have Horizon. And again, all these slides will be available. I think they're probably available now, but if they're not, they will be very shortly. So for those of you who are AWS users, I've grabbed this very simple look at how a lot of this works together. Those of you who are primarily OpenStack people looking going, what is that, from like three years ago? Well, yes, because I didn't want to explode the heads of the AWS people with all of the complexity that has come up in the last few years. But basically, as you can see, you've got the dashboard that provides management for all of the other layers. And everything hooks into the identity service on the bottom. So that's sort of a very, very, very brief overview of OpenStack for AWS users. Now, easiest way to move a workload from AWS to OpenStack? Don't. Now, I'm not really being facetious here. Well, I kind of sort of am. But what I'm trying to say here is if your application is a cloud application, then moving it is actually pretty simple, because a cloud application has certain architectural features that make it pretty simple. Because it's made to scale horizontally. It's made so that you can have lots of different machines in lots of different places. It's made so that it's stateless. It doesn't matter. You can have a session that hits this machine, and then it hits this machine, and then it hits this machine, and that machine doesn't matter. It's all based on microservices. So this function is made by making an HTTP call, and an HTTP call. If this machine over here goes down, it's fault tolerant. It doesn't matter. The whole thing's not going to come crashing down. And the thing about having a cloud application is that when you have a cloud application, it doesn't really matter which cloud all this stuff is in. So if your application is really a cloud application and it's all set up, you can gradually kind of move stuff over into OpenStack, and gradually just kind of shut down the stuff over there. And that's fine. A lot of people are like, I have a cloud application. I took my database, and I put it on Amazon. Yeah, that's not a cloud application. I took my enterprise, this, that, the other thing, and I put it on Amazon. Yeah, you know what? Taking an application and putting it in the cloud does not make it a cloud application. That makes it an application in the cloud. And congratulations on taking that first step, but you're not done yet. So that would be actually the first thing and the easiest way, but probably not the way that you want to do that if you're in a hurry, which I apparently was last night. So we'll just move right along. OK. Come on. You've been at the summit all week. You know how tired I am. OK, so the second easiest way of moving from AWS to OpenStack would be using orchestration tools. Now, if you've been walking around the expo floor, you've seen a bunch of these. These are tools that, basically, they are the layer of your application that deals with the cloud. It's not what's actually doing the calculations. It's what's deciding where to send that work. Typically, your orchestration will be versionable. So the logic behind, OK, well, I'm going to run my first 10 instances over here. And when there's too much traffic for that, I'm going to put it in that cloud over there. This is normally done in a way that you can take that and put it in Git or wherever you're going to put it. And usually, this is going to be for hybrid cloud environments, where you've got your internal data center and then you've got your public cloud presence. And that's going to be a lot of the situations that you're dealing with if you're trying to move from AWS into OpenStack. And so here you've got some different options. So you've got some cloud-specific orchestration tools. For example, when you're in AWS, you know about, those of you who are in AWS, you know about CloudFormation. That's the AWS orchestration tool. For the OpenStack people, there's Heat, which was originally based on CloudFormation. And again, there's some backwards compatibility that's still there. So these are some that are cloud-specific. On the other hand, there's a lot of tools. And actually, I haven't even listed all of them here. There's StackStorm, which is open source. There's Ericsson has a cloud manager. AppSara has a hybrid cloud operating system. This morning, I was talking to Beth Cohen over at Verizon about their Secure Cloud Interconnect, which is that kind of thing. Every day, it seems like somebody is coming up with a new way to orchestrate workloads between clouds, which is great. So just taking kind of a quick look at these. StackStorm is a workflow engine that started out in OpenStack using the Mistral project. Again, as I said, it's open source. You can go and grab it. Nice guys over there at StackStorm. Pretty smart. You can get a look here at sort of their notion of how this works. You've got various automations that work with sensors and actions. And they are sort of cloud-independent. They don't care what cloud it is. You look at Cloudify. I obviously did not finish this slide either. Boy, I was really tired last night. We'll correct that. But this is really their slide. This is really their image. It's a long week. Anyway, so you can see here now what Cloudify sort of the main thing about Cloudify is they're based on Tosca, which is a cloud orchestration standard that's been around longer than OpenStack. I remember working on Tosca years and years and years ago. And I thought it had gone away back into the deep recesses of my subconscious where I wouldn't have to think about it anymore. But no, it's still there. And somebody's actually done something useful with it, which is really awesome, because it's very powerful, Tosca. Another look here, you've got AppSara. So their whole idea is they're a hybrid cloud operating system where they've just got everything there. You just put all your apps in there, and they all talk to each other, and it doesn't really matter. So that just kind of gives you an idea. Now, that's all terrific. But the thing about cloud applications is that they are cloud applications. It's the whole pets versus cattle thing. All of those systems assume we're dealing with cattle. Get sick, shoot it in the head, get another one. But maybe you have puppies. You don't want to shoot your puppy in the head? Well, I don't want to shoot my puppy in the head anyway. I don't know what you're doing. But maybe you've got a pet out there. Maybe it's been out there since 1998. And you can't possibly replace it. And so you're just going to have to move it. So there's only one thing left to do. You're going to have to do this the hard way. Now, this is the part where we were talking about earlier, where basically what you're trying to do here is you are starting out with an Amazon virtual machine. And you want to wind up. So over here, you've got your Amazon virtual machine. And over here, you want to wind up with an image that you can load into Glance. For you AWS people, Glance would be the sort of image repository. Like when you go to launch an instance, they give you all those choices, that would be Glance. Now, problem is, lots of steps between here and here. Too many to really give you a demo. But what we're going to do is we're going to kind of do a brief run-through of them. And I will give you also a link to Darren's book that has the very specific, here's all the registry entries, and here's all the drivers, and all that stuff. But when you walk out of here, you at least have a good idea of how the process works. So when you read it, you're not going, huh? OK, so let's start with Windows. Just to kind of look at the general idea. So the first thing you have to do is you need to install the Vert.io drivers. And the reason that you need to do that is because otherwise, OpenStack doesn't know how to communicate with your VM. It's like when you take me, if you're going to put a new video card in your machine without the drivers, the machine doesn't know how to talk to it. It's exactly the same thing. So we're going to install the Vert.io drivers. We're going to prepare the registry. And ultimately, we're going to make a VMDK. So at this point, some of you are going, wait a minute. I did anybody say VMware? Anywhere? No, I haven't said it yet. But the fortunate thing is that VMware makes a tool that allows you to take an Amazon instance and bring it into VMware. But they also make a tool that allows you to bring a VMware instance and bring it into OpenStack. So, aha. Finally, we can talk. So we're going to create a VMDK. And then we're going to make that VMDK into a QCao 2 image, which is how we're going to bring it into OpenStack and then upload it to OpenStack. Any general questions before we go on? OK. So I'm going to kind of fly through the steps for a little bit because, again, we're not going to do it right at this moment, but I just want you to. I had a professor in college who once explained that survey courses are to make you think you know more than you really do so that when you learn them for real, your brain doesn't rebel. So that's what we're doing here. This is kind of a survey course in how to do this. So what we're going to do is we're going to open up the firewall on the Windows machine and then you're going to enable remote desktop access. We've got that in as a step, but honestly, it's almost always already open in a VM that's in AWS because otherwise, how are you accessing it? So we're going to allow access to the firewall. And then we're going to install the Vert.IO drivers. Now, how you do this is going to depend on whether you have administrator privilege privileges for the VM. If you do, great. You can install it right on the machine while it's running, done. If you don't, and you can't get it because the machine's been running since 1998 and the person who installed it got hit by a truck in 2006, well, that's OK. It's not the end of the world. But basically what we'll do is we'll take the VM, we'll take it, and we'll make the VMDK, and we'll convert it, and we'll do all that. And then we'll inject those drivers afterwards. OK. So first, we're going to go ahead and get the drivers. Got the URL there. It's an ISO. And then if we have admin privileges, we're going to go ahead and install it from the ISO. So first, we're going to install Damon Tools or some other emulator and mount the ISO. Just a quick note there. Make sure that you do install SPDT, or TD rather, even though it says you have to reboot. Otherwise, this will not work. All right. So then this is a very long URL, but it's an even longer set of instructions, so I just opted to put that in there. This is how you actually do the actual installation. When you go to do this, it will say blah, blah, blah, driver type, blah, blah, blah. OK. The driver type via store. OK. Trust me. Took me like three hours on that one. And then Darren looked at me and went, you know, says it right here. So there you go. All right. Now we're going to import the registry configuration. Again, full instructions at that particular URL. And then you're going to add a second administrator's account. Now, you need to attach a new volume to the VM. And you're going to do this in the AWS console. So you'll go to EBS, create a volume, attach it to the VM, and then grab the vCenter converter, VMWare vCenter converter. I'm going to talk to you about that. Sure. You're going to be able to download all the slides afterwards. OK. You're welcome. All right. Because I know I moved too fast. OK. So grab the converter. And then in using the converter, you're going to create a new image. And your source is going to be the powered-on machine. And you're going to choose VMWare workstation as the product. Now, everybody here heard Alice's restaurant from the song? She says, and there on the other side, in the middle of the other side, away from everything else on the other side, read the following words. Don't use the system desk. I've told you. I've warned you. Don't use the system desk because you will destroy your entire machine. And your house will catch fire. And your boss will fire you. And you'll be homeless. And your children will hate you. Don't say I didn't warn you. All right. Now, so once you have that on the volume that you attach to the machine, you're going to go ahead and convert the VMDK. So you're going to copy it over to a Linux box. If you don't have a Linux box, well, you got to open stack. Make yourself a Linux box. Install Kmoo IMG. And then go ahead and convert it. Got the command there, sample command. Now, if you had administrator privileges, congratulations, you're done. If you did not, then you got to take a few extra steps. So now you're going to go ahead and tell, you're going to have to use guest fish. Guest fish will allow you to inject all this stuff into the VM, into the image. So you're going to go ahead and tell guest fish where to find KVM. And you're going to copy the same vert.io files that you used before. And you're going to create a script. And again, all of this is in that document. I'll make sure there's a link here to the document. But there's a long list of values that are going to go in the script. And then you run the script. And this kind of fell off at the bottom. But you'll have a registry. You'll have a file that you're going to inject the registry. Basically, it's the same steps you did before, only you're doing them after instead of before. So now you have a QCAL image, which might as well have come from anywhere. Didn't have to come from Amazon. But you're ready. You can go ahead and you can bring this into OpenStack. And you can do that one of two ways. If it's small, you can use Horizon. If it's large, large being a relative term, depending on your system and all that, do yourself a favor. Just use the CLI, because otherwise the browser times out. And then the upload stops. And then you pull your hair out. And just trust me. And then from there, you're ready. Watch your VM based on that image. So that's a lot of steps. But it's certainly better than trying to recreate everything you've done since 1998. Any quick questions before we move on to a quick look at Linux? OK. So doing this in Linux, we have one slight problem in that Amazon uses a custom kernel, which is great for them, lousy for us. And the reason for that is because they use this custom kernel, we can't just export everything and bring it into OpenStack. Instead, we basically have to find a way to make a machine that's like the machine that you have. And the way that we're going to do that is we're going to note what's already on that machine, create a new VM, and then make it like that machine. So let's kind of take a look at those steps. So first thing we're going to do is we're going to go ahead and get a list of all the installed packages. So we get that list off onto the local machine. Then we go list of the file systems. So we know what we have to build. And we copy that machine. Yes, sir? I could be cynical and say that they have some nefarious purpose, but I'm sure they have some technical reason for it. I just don't know what it is. OK. And then finally, you want to make sure that you get a list of all the services that are started at boot time. And you want to back up all your startup scripts, because I'm sure you're going to wind up with something that only lives here. And of course, if you have any specific application files that are in use, you're going to want to grab those as well. All right. So then you're going to go ahead and create a new Linux image. And you're going to create a new SSH key so that you can get into that Linux image. Boot it up, as you can see. The flavor, it's kind of cut off on the bottom here, but on the one that you download, it'll be there. You'll want a flavor that's something similar to what you had on AWS. So obviously, if you had an M2 large, you're not going to go with a tiny on OpenStack. That is awesome, by the way. OK. Next thing you're going to do is get the IP address. You can do NovaList. You can see we have the IP address there. So that allows you to log in, even though you can't see it, because it's underneath the bottom of the page. But trust me, it's there. Now, so you're logged in. You've got your files that say what was on the old machine. This is how you're going to put them back. So the first thing you're going to do, sudo over to root, update. And basically, you're just going to go ahead and reinstall everything. And that's it. And then once you have that, you are again, you have your machine. You put your files back on it, and you're ready to go. OK. And that brings us to Q&A. And I think we are bang on time. OK. All right. So does anybody have any questions? Yes, sir? The find systems of any database or anything? You know, I will confess that I have not tried a lot of different workloads with this. Darren, have you tried a lot of different workloads with this? The instructions there, if you're real full, who would you have taken over? You're really not going to want to do this. You don't want to stand up for questions and say, well, you have to take over there. Are we getting picked up? Wait, hang on. Do me a favor. Go talk into the mic there, Darren. And repeat the question. Sorry, I forgot. We have to go to the mics. So the question was, how many workloads have we actually seen people do perform this for? For the most part, think of it along the lines of back in the days when Windows got released, doing an upgrade. It's safer to do a fresh install of Windows, right? And this is the same thing. You're basically taking the underlying hardware, virtual hardware, and taking the OS from that and moving it to a different set of virtual hardware. So in reality, for real workloads, you're going to want to stand up a fresh thing and deploy your application. If your application isn't portable to that degree, you guys probably should really look at rewriting your applications. Yeah, this is kind of like last ditch, really. I mean, really, when you come right down to it, the first way of making a cloud application and do it that way, that's really your first line of defense. This is like, I can't do that. What am I going to do? Other questions? Can you, I can't hear you in the- Just a simple comment here. Oh, OK. OK. Outside of Windows. Sorry. Do you have similar recommendation from operating system other than Windows? Such as? Let's say I have a pretty, one of the things, I have a web app, but on Linux-based. Unfortunately, it's a pretty old one. Again, nobody's there to what was the exact config files and all that was set up for the DB and all behind it in SQL DB. So do you have a- Well, I mean, I think this process is going to give you a lot of that, right? The registry part is what I have a question for. Well, so in Linux, there is no registry. So if you haven't like an application that's installed on Linux somewhere, Chance Star is probably installed to a specific file system. While the thing's up, you probably want to use LSOF, find out what hooks it's using into the environment, and then basically port it over that way. Tarr it up, move the files over, use R-Sync or something along those lines to pull it over. But yeah, if the person's gone, it's going to take a little bit of investigative work in order to find out what you need on your destination system. Other questions? Is that it? Is that really it? So I kind of see two methodologies that you're using. You're doing the actual snapshot image copy over and just transferring files over. So with a snapshot, the other thing that hasn't been talked about is a sysprep process, because if you just copy one exactly over, like Windows, you're going to have the same MAC address as the old one. Oh, yes, I'm sorry. So you're going to have a few things like that that need to be edited and modified. That is correct. You need to, when you create your, see, he warned me about this. By the way, Darren used to work for Morantis. So yeah, Darren warned me about this yesterday. When you create your, well, yes, last week, when you create your networks in OpenStack, you want to make sure that you match up the MAC addresses that are on your original virtual hardware, because when you pull everything up, yes, it is going to have the same MAC addresses. And then a ladder one of copying it over, the data over, I mean, that's probably the general one that you should do anyways. So that's kind of a different solution to me anyways. And it's kind of like, it almost seems like the cheating way, because most people just want you to do the snapshot image copy over. And I understand that's a bad try to solution to try to shove something in a different size peg hole. It really is. And that's why I said at the beginning, I was like, this is not the way you really want to do this. This is like, you absolutely don't have any other alternative. And you just got to do this. But I mean, let's be realistic. I mean, anytime you're standing up a new machine, don't you want to start fresh anyway? Generally. And it's a great opportunity for applications to say, hey, if you want to upgrade to a different OS. So I mean, if you're stuck in an older version of RHEL, hey, this is now a good opportunity to say, I'm going to upgrade to the newer RHEL and say, my application now runs on RHEL 7. Exactly. It's just, you really don't want to do this if you don't have to. Yeah. So just to comment on the Sys Prep, basically what you're actually doing is you're avoiding that completely. So what you wind up doing is you create your ports in Neutron using the CLI, because then you could define your MAC addresses. So your ports are already there. So when it comes up, the metadata is there and it'll already automatically plumb up. So yeah. So you're basically skipping the whole Sys Prep stuff. So what we're talking about for databases, it's best to do a data backup and then restore. Other questions? OK. Well, thank you all very much for coming. And thank you again to Darren. Let's give him a huge hand. What's that? Wait, wait, hang on. What? Just go back to mine. Oh, OK. Go back to your slide. Well, yeah, it's just so. Oh, yeah. Oh, because we didn't get it on. We didn't get it on the same. Yeah. I just want to say, I did write the document. This slide has my email address on it. That's my new company. So if you do have any questions, you could email Nick and he can get a touch to me or you can email me directly at my email address right there. Right. Yes. So thank you all very much for coming. I know it's late in the day and late in the summit. So give yourselves a hand for lasting this long. Thank you.