 Can everyone hear me? OK, so how many of you were here at the last session? OK, good. So I'm not going to say all that stuff again. So if you weren't, basically at the last session, we kind of went over VMware, how they view OpenStack, how the high-level components fit together. We had a couple customers like Wells Fargo and Intel talking about how they're using OpenStack and VMware. This session is entirely going to be live demo, which means things are probably going to break. I'm probably going to look like an idiot. But the goal is really just to, I'm sure you're all kind of PowerPoint saturated by this point. So I'll have two PowerPoints, and then I'll be on to just live demo. I've got a handful of scenarios that I'll kind of walk through. The general model, kind of think of me having a split personality here. There'll be Dan, the IT guy, and there'll be Dan, the developer. And that's kind of typically the situation we see in our customer engagements. It's about someone, an IT architect or an IT administrator, who is looking to enable developers by giving them access to the OpenStack cloud, give them access to great programmatic interfaces, and in a way that access to the infrastructure is not tightly coupled to the underlying vendor. So with that, I'm going to just jump in, assuming this actually works. Let's see, come on. Oh, we're not. Let's see. OK, I'll get all the clicks at once then. So just a little bit about the demo hardware. So this is just running off a small cluster of five Dell servers with Intel's EM processors, 64 gigs of RAM. Initially, we'll show how this works with just a pretty low-end NFS storage array. But one of the things we'll want to emphasize in this demo is that you don't need actually any dedicated shared storage to use OpenStack with VMware. And in fact, we'll highlight a technology called VSAN, which takes the hard drives and SSDs that are inside the hypervisor itself, and effectively creates a virtual SAN. And so that's why we're calling out specifically. We've got 12 1 terabyte hard drives in here, and two 200 gig SSDs. And you'll see when we make a volume on SSD, it's fast. So cool. So let's move forward. And just a word of warning. So just today, we released Vova, which is this lab trial appliance that people can use to get experience with OpenStack on VMware. And it's based on IceHouse code. So based on our testing, there's still some issues in there. So we may stumble across some here. So this is a high-level picture of what we're demonstrating. We'll show people using Horizon, the CLI tools, or the API tools to provision the standard OpenStack interfaces from Nova, Neutron, Cinder, and Glance. So again, when you're using OpenStack with VMware, to your developers, to people consuming resources, we use only the standard interfaces. Anytime in this demo where you see a VMware tool, it's me operating as the cloud administrator or the cloud architect, troubleshooting an issue or doing capacity planning. If you're a developer in this environment, you only ever end up using the standard OpenStack tools and APIs. So first off, I'll just cut over to a desktop and show you a bit about the Nova vCenter integration. So let me start off. This should look familiar to many of you. Nobody? Oh, come on. You're all in the thick client still. You don't like the web client, right? I get it. I get it. Yeah, join the club. So let me see is this live? Oh, come on. Yeah, my view desktop is over. So I can actually cut over. I've got it over here. So I've got backup windows. So let me. So this is obviously the Horizon Portal, and we'll be using that in a second. And then it's 10 to 145 to 101, you said? OK, so what I'm pulling up here is the vSphere web client for that cluster. And I'll just give you an idea of the background infrastructure that's in place with those Dell servers. Now, unfortunately, the reason we're using a view client was because that's local at VMware, and the latency is a little better. This will take a little time to load. So while that's loading, I'm going to go try to kill. We knew we were going to hit problems. We didn't think it was going to happen before we started. Come on. Oh, our view's back. OK. Maybe it's the internet here then. So OK. So here, this should look familiar. So I'll just show you the basic setup of the infrastructure. So pretty common for a small open stack deployment, you just have one or two clusters. This is actually our compute cluster here. So you can see those five Dell servers that we talked about. If I go over and look at the cluster settings, for example, I have, you can see the summary. Again, this is me as kind of an open stack administrator preparing my infrastructure to be consumed by open stack. So you can see my capacity over here. I'm running vSphere DRS to balance the workloads evenly across the hosts. I'm running vSphere HA so that if any of the individual servers goes down, it'll be transparently restarted. And you can see here, I've already got a set of open stack VMs spun up. So this is the compute capacity. This is actually what the cluster that the tenants will be consuming. And then over here I have a management cluster, which right now is just running on one server in a real production environment. You'd run it on a handful so that you could have HA enabled in your management cluster as well. But you can see we've got a set of supporting VMs. So here's our open stack controller. This is where all the open stack services are running and the APIs are getting served up from. You can see we have a set of NSX appliances for the networking. And we have a set of management tools like log insight, VC ops, and obviously, very importantly, our vCenter. So we'll kind of touch each of those points as we go through this demo. Then if we've got time left over, I'll take open requests for a demo. So again, this is the administrator view. But if you're a tenant, you would just log in using the standard tools. So I can do whatever I want. I can terminate instances. This is an instance we'll use later. So I'll leave that one here. But I can go to launch instance. And again, this is all standard. If you guys have seen open stack APIs, there's nothing different here by the fact that it's on VMWare. So I'll do, I can't even spell. OK, so I'm going to name my VM, blah, blah, you've probably all seen this. I'm going to pick an image. I've just got a couple images, Debian images. These are both VMDK formatted images. We've now recently started supporting OVA as well. And I can just click launch. So again, from the end user experience, they just see all the standard open stack. I could have done this from the CLI. I could have done it from the APIs directly, which we'll show later. So now that it's in spawning, that basically means that it's now talking to vCenter. And so if we go over to vCenter here, and if we actually go and, for example, look at the set of events that are happening on this cluster, we should, or I can actually just use the tag to find it. So was it Atlanta? So one of the cool things we've done is we've integrated vSphere and OpenStack. So as you provision a VM onto the vSphere cluster, automatically gets tagged and put into the vSphere inventory as an OpenStack VM. So even though I can search on the actual OpenStack name and click on that tag and find the underlying VM. So again, it's about making sure that all the operational tools you already know and are familiar with make it easier to run OpenStack. So I can go find this VM. If we look at its hardware, we'll see that it maps exactly to that flavor that we picked, which was the nano flavor which had one vCPU and pretty small VM. But you'll also get great information that you can use for troubleshooting, for example. You can see here that I can find out what host it's on right now, really easily, the resource pool, the storage. And I can see how much memory it's using. If I go down here, I can see, again, all of the OpenStack information about the VM. So you can use a single pane of glass to be able to drive this. And we'll highlight later. I think this takes a little bit of time to fill in, because the VM was just provisioned. But we're actually hooking into vC operations management as well, so that it can monitor the VMs. So I think one of the things that I wanted to highlight as well is that, obviously, it's important to, it's one thing to give your developers the APIs, but it's really important to have enterprise-grade infrastructure underneath. So for example, let's imagine you need to do a maintenance on a host. And don't even necessarily know what all these VMs in your OpenStack cloud are being used for. You don't know if you can take them down now or not. But obviously with VMware, what I can do is I can just, this host right now has two virtual machines on it. But there's nothing that prevents me from putting that guy into maintenance mode. And what you'll see over in the upper right-hand corner over here is VMware will automatically start vMotioning, transparently vMotioning those VMs off that server so I could perform a maintenance on it. So you'll see up here, right, the server's entering maintenance mode. I think there were two VMs on there. Yeah, so two virtual machines here. So as it goes into maintenance mode, it will identify the set of VMs that are on the server, it will identify additional targets. And it will vMotion those over soon. This environment's nested, so it may be a little slow. OK, so now it's going to go. But anyway, so we've got the idea. We can check in on that in another couple of minutes. So obviously compute is kind of the first thing. Compute alone doesn't really make a cloud. But I just wanted to do this. Even the simple use case, you can kind of highlight how the value of VMware still is relevant just from a compute perspective, making sure that you can provide enterprise-grade infrastructure to your tenants. So maybe there weren't any. It took them off. I guess it didn't tell me that they were migrating. But you can now see that there are zero VMs on this host. And it's now in maintenance mode. So let's go back. So that's a very simple scenario. Let's say now the world gets a little more complicated. Your developer is not just spinning up individual VMs. They're actually building an application. That application needs to have its application servers and its database servers on separate network segments. This is where we go from just having to worry about compute virtualization to worrying about full network virtualization. So if I go over, let's see if I'm logged out here or not. So you can see here, this is the open stack network topology screen that a tenant would see. And right now I just have a really simple network topology. I've got that VM I just spun up here and one that we'll use later to show you some volume stuff. And the world's pretty simple. You notice when I booted the VM, I didn't even pick a network. I was just putting on the one network that's there. But let's say now I need a bunch of development environments because I'm going to do continuous integration for this app. And I want to test it in a realistic setting where it's actually on two different network segments because that's the recommended deployment model. So instead of subjecting you to a whole ton of clicking, I will highlight the fact that, of course, not only can you use Horizon, but you can use all the standard open stack APIs and tools. So what I have here is a simple Python script that basically what it does is it talks to the open stack APIs, talks to Neutron APIs and Nova APIs. And it says, create a router, attach it to the public network, create an app and a database tier, a network tier behind that, and spin up two app servers on one of those networks and two database servers on another. And then what we'll do is we'll go behind the scenes again as an administrator and take a look at what's happened within NSX. So again, this is what the tenant would see. Great. Everything seems to have worked. And the tenant would go back to his or her network typology. And great. Now we've got that same network from before, Net1. But we also have this, we've got a new router with two different networks behind it. Not sure why the colors are all changing. It might be an open stack bug. It's like a Christmas lights or something. Here you can see this is our database network. This is our app network. And there's our app server 2 and app server 1. And this will be database server 2 and database server 1. So anyway, at the press of a button, I can go pop up not just VMs, but actually virtual networks. And it's cool to show this. And actually, there's probably a lot of companies who could give a demo like this that shows the multiple networks being created by open stack. What really kind of sets VM or NSX apart is the underlying implementation of it. So what we're going to log into, oh, that's not good. Was I really doing cross-site scripting on that? I didn't know I was that talented. OK. I probably had an old cookie or something. So anyway, this is the NSX dashboard. This is kind of, again, the administrator dashboard for NSX. So you can see, again, this is a pretty tiny demo environment. We've got 22 different isolated networks that tenants have made. What you can see here is, again, here are five ESX hosts that we're putting VMs on to, and that NSX is managing from a compute perspective. We have one Ubuntu host. What that is is that's actually the open stack controller that's implementing the DHCP functionality, if you're familiar with that. So again, NSX is completely multi-hypervisor. We could have KVM hypervisors in here, too. And you create networks where some VMs from KVM and some VMs from ESX. We even have tons of customers who use this purely on Zen server or purely on KVM. So there's no ESX required. It's multi-hypervisor. It can work with whatever hypervisor you have. This is a pretty simple setup. Normally in production, there would be three controller nodes for HA and scale out, all of that. So what you can do is, for example, you can go and there's a lot of cool search functionality in here. So what we'll do is we'll actually search for the port we just created. So we can kind of look at how NSX implemented underneath the covers. So what do we call that DBE something? Where's the database nut? Cool, so here's the database nut that I just created. I probably could have browsed through it here, but you should see in our internal setup where we've got, I think, at times 5,000 different tenant networks. That's why this is a search-based interface, because once you give the people the ability to just dynamically create networks, they find all kinds of cool use cases for it. So I can look into here, and so this is the DB switch. So you would expect trick question. You would expect four ports on here. Does anyone know why? This is an OpenStack deep dive question. I used to run this project, so I'm into the details. So there's four ports on this nut where there's the two database servers. There's the uplink to the router, because we gave it an uplink to a router. And there's the DHCP agent that's listening on there. So what we can do here is we can actually pick one of these ports, and we can look into the individual configuration. What I'm going to show you is a really cool troubleshooting tool that you can do to find out if a tenant calls up and says, oh, I'm having connectivity problems. You're like, well, I don't have access to your VMs. How am I supposed to do that? You can pull up the VM on the network, and then there's this port connections troubleshooting tool. Let's see. So what I'm going to then do is say, basically, let's say between these two hosts on the network, tell me what that connectivity looks like. Tell me if the physical network is actually implementing it, or if there are problems in the underlying infrastructure. So NSX, for example, is actually constantly sending probes into your physical infrastructure to understand whether there are faults in your physical infrastructure that would then be impacting your logical networks. So again, this is an example of something like I said, anyone could do that first part of the demo. But really having, this is the kind of stuff you have in a product when it's been in production appointments for two-plus years. So here what you can see is that you get a full mapping of where these two hosts are, what hypervisors they're on right now. So you can see this guy is actually on one of the ESX hosts, and this is actually the DHCP port here. This is the KVM. So this is a connectivity that's being created across hypervisor. I can see, for example, this is using overlay technology, so they're tunneling. So I can see the IP addresses that we're using for tunneling, and I can see the liveness checking that all those tunnels are up and fully functional. So at this point, I know the problem's not in my physical network. If one of these shows up as red, that's when you get a hold of your physical networking person and say, for some reason there's not connectivity between these two addresses. Another really cool thing about this is that we fully control this V-switch, and so there's a lot of cool things you can do that you can never, you know, don't have the flexibility to do in hardware. So for example, I can actually just dynamically request a ping that gets injected into the logical network. So I can ping from this port to that port. I can see it got injected and it got delivered. I can ping from this port to that port. So again, this is all using, you can see, it should say right here, yeah, so it even tells you what type of tunneling it's working. So STT is a really highly optimized overlay tunneling protocol, so you can get full wire speeds with very low overhead. Overhead is definitely something when you're looking at a network virtualization solution, you should be very aware of. So again, I used to be the product manager for this, I could talk for an hour about this, but come up and find me or come to the VMware booth afterwards, NSX, really cool product, really kind of game changing in terms of the set of scenarios that you can enable for your customers in terms of letting them just build their own dynamic networking topologies in addition to just requesting VMs. Cool, so I'm gonna then cut over, or did I just log, no, so that's fine. Okay, so then let's say that I'm gonna go in and talk a little bit about storage. So this is an Ubuntu VM I have, and right now it's got a volume attached. So let's say I've got your database, I've got your database on a persistent volume, so if the VM fails, you can attach it to another one and you won't lose your data. So what I can do here is actually log into the console, and so I don't know if you guys are familiar with FIO, maybe FIO is a basic Linux input output benchmark tool. And so, for example, what you can see here is that I have, let's see, I have a basic volume for my NFS data store mounted here. And that's, like I said, with the VMware integration you can use any data store that can connect and work with vSphere. You can use to store your primary disks, your volume and your glance images. So it's very, very simple. So I can run FIO and I'll just run it for 10 seconds to show, this is not the world's great NFS storage that I'm comparing to. So I'm not trying to say NFS is good or bad, this is just something we had. My main goal here is to show you that it's very easy to create multiple tiers of storage inside your open stack environment when it's based on VMware. So what it's doing is actually splatting some files onto the volume. And then you can tell it's very slow storage. And then what it will do is it'll basically run a 10 second performance test. And we'll come back to this. I'm gonna show you over in the vSphere web client that at this point it is, let me find that guy. See, isn't that convenient? Not even, let's see, as long as it loads. Oh, the list, okay, that's any ball one, right? Not as convenient as I was hoping. So, okay, so yeah, so now it's running. You can see very low number of IO operations per second, about 300. So what we can do is we can go back to the instance and see E3F. So I wanna show you really quickly the setup in vSphere right now. So there it is. And you'll see that because of this volume there's one extra disk attached, but that disk is currently mapped to, it's currently mapped to an NFS data store which I mentioned is quite slow. So as you can see right, there's a primary disk that's 40 gigs as you expect. There's a one gig volume attached and it's attached to the NFS data store. So how many of you are familiar with vSAN? A decent number, all right. So like I said, this whole setup is vSAN enabled. So that means that, that means if I go click on here, one of the really cool things about vSAN is if you've got the SSDs and the disks in the servers, it's basically a one button or two button or something click to enable it. So compare that to managing an entirely different storage, all right. It's very, very slick. So I think you can probably, is it over here, right? Yeah, where I click on vSAN and there's a, so yeah, so vSAN has turned on and I could click edit and turn it off. But I won't do that because I wanna show it in the demo. So and then there's storage policies as well. How many people are familiar with storage policies? All right, it's not too many. So storage policies is actually a new capability or I think it was new in 5.1 but that lets you kind of create different tiers of storage and expose it instead of on a data store by data store basis but as groups of data stores. So we have two policies and actually we created a gold policy, probably should have been bronze because that NFS is pretty slow. But and then we create a new platinum policy that uses the vSAN data store. And what that enables us to do is again, this is me as an administrator, I would configure these policies. But then I could as an administrator, I could expose the ability for my tenants to create different volumes that map to these different policies. So right over here, you can see that database volume that was of type gold that I created earlier. And now that I've got vSAN in the environment, I'll also have the option of clicking this and creating a platinum volume. So I'll create another one gig platinum volume. Oh, cool. And then I will just attach that to that exact same VM so we can basically just run that same test again but point it at a different mount point. So again, that VM was boon to vol test. So this will take, so basically what this is doing is now it's reaching out, it's creating a VMDK on that vSAN data store. That's one gig. And attaching it to that VM. So what we can do is actually, we can probably go back over here, find that VM again. And by the time this guy's saying attached, we should see a, so this is the, the initial attaches a little slow because it's actually going out and actually provisioning the capacity there. So watching paint dry, huh? Let me see this. So one of the interesting things about, oh, there it is. So remember hard disk two was on the NFS data store, hard disk three should be on the vSAN data store, right? And it is. So now let's actually go into the VM. We'll go back into our instances. Vol test. And I'm just gonna run a quick script to mount that volume and splat a ext3 file system on it and all that jazz. And then I will run the exact same test. So let's see if this, it's worked in my environment. Yes, proceed. Okay, so now let's, okay, great. So now we've got these two volumes mounted and I've got just a version of that same file config that just points to that different directory. So if you look at it last time, we got about 300, 300, is it 300 IOs? Yeah. So now again, this is not saying vSAN is this much better. This is just because it's reading from flash, right? So you'll see it's something insane that it gets like 16,000 or something because it's, but the point is just that a vSAN lets you enable flash and expose flash to your, yeah, sequence is like 14,000 IOs. So again, I'm not claiming, this is almost entirely due to the fact that it's flash that's locally in the hypervisor versus this pretty slow NFS storage. But the point is that it's very easy to expose all kinds of different tiers of storage and that even within vSAN, you can expose different tiers. So even if I didn't have that separate NFS storage, I could have vSAN data stores that get more access to the flash and vSAN data stores that just get access to the spinning dish and a tiny bit of flash. And that's, you do storage policies for that. So incredibly powerful tool. Can you actually hold till the end? Unless you're gonna clap. I'll take a pause at any point. Nah, I was kidding. Okay, so let me quickly show two other cool tools. Am I, 10 minutes or what? About 10 minutes. About 10 minutes, okay. So this is vCenter operations management. How many people know VC Ops? Pretty good, pretty good. Okay, so again, VC Ops, you can already use VC Ops to monitor your underlying vSphere NSX infrastructure. What I'm gonna be demoing here is actually taking that to the next level and actually having VC Ops manage OpenStack itself. So first off, if I'm an OpenStack administrator, it's a complicated beast in and of itself, right? It's how many different services running? How do you know that they're all up? How do you know they're all healthy? Let's see, is this loading? So for example here, now I'm looking at the OpenStack storage service here. And what I can see here is the overall health of the storage service is good. I can see that this is the actual Cinder processes. They're up, they're running just fine. And I can see that all my data stores are healthy, they're fully connected, and they're fully operational. And in terms of things like capacity planning, right? I can go over, I can actually look at all my data stores. And all the thresholds here are tweakable. I'm just using the default ones. But you can see here that these, this is our demo cluster. So this is our compute cluster. And you can see that, for example, the vSAN data store is, what, maybe this one? I can't even read this out. All right, yeah, this was the vSAN data store, right? So that thing's huge. We just put one volume, one one gig volume on it. That's way green. But the NFS data store, we've put enough stuff on it that it's at 37% capacity right now. So you're starting to see yellow, starting to get some sense of, oh, that's the type of storage I may need to get more of. Now might be a good time. And then there's also really cool OpenStack awareness in terms of individual tenants. So let's say a tenant calls up and says, I've got a problem. You can go into VC, you know, I already showed how you can go into vCenter and pull up their VMs. But you can even go into vCops and put in their, you know, look up their tenant and get more information about them. So for example, here's the tenant that we've been using. Let me spot that out. So what you can see here is now all information about all my VMs is the Dan Went tenant, right? And again, this is OpenStack awareness. So it makes it much easier for you to troubleshoot. You can see any alerts that apply to me as a tenant, either because they're directly my VMs or because my VMs reside on the hardware that is having an alert. So it makes it very easy for you to understand, you know, what problem might be triggering what this tenant is talking about. And then I can traverse the relationships from my OpenStack VMs, the OpenStack networks to the underlying VMware infrastructure like the ESX host and the NSX servers that they're currently on. So again, it makes it very easy to traverse these relationships and understand that a tenant might be seeing a problem or a whole group of tenants might be seeing a problem because of one fault in your underlying infrastructure. So this could probably be a one-hour demo on its own, but I gotta keep moving. So the last tool that I wanna show is something really cool. Probably not many people know log insight. How many people know log insight? Yeah, that's what I thought. So log insight is actually a really cool tool. We use it in our internal OpenStack cloud that we run at VMware. And it's not doing it's service to call it a log collector because it does so much more than that, but basically all the logs get sent to it for analysis. So there's a set of auto-populated dashboards. So for example, I can monitor my vSphere infrastructure in here, I can monitor my NSX infrastructure. I can really highly customize a set of dashboards that are shown that comes with a lot of baked-in dashboards, but by far the coolest part of log insight is the dynamic analysis you can do. So this is actually a real error that we had in our demo environment about yesterday morning. I was like panicking. I was like, oh, the DHCP is down. Why is it down? So if you actually just search for DHCP and error in these logs, I need to go to, because it was yesterday now, so let me go. Or no, not six hours, any last. So what log insight does is it's incredibly powerful machine learning that actually matches, goes through all of your logs and does pattern matching to understand when you're getting a bunch of log messages that are basically the same thing. So what you can see here is there were, this is open-stack for you, right? There were 105,000 of these log messages in a period of just about a day because DHCP wasn't happy. But log insight says, well, this is really one problem. And so we're able to see when they started. And actually this, I realized that when we started we had just restarted our open-stack controller and that's actually what triggered this problem. So that combined with being able to look at the log message, I was actually able to go and clear out all my existing DHCP state and reboot again and after that it was working and it's been working since then. So you'll notice what I can do here is I can actually take this query and for example, I could take any dynamic query that I do and turn it into a dashboard that's on one of my pages. So what we're doing as an open-stack team is actually doing a lot of this work for you and going out and finding what types of errors, for example, probably won't have time to demo this, but anytime someone hits a quota limit, right? That's something interesting because that user is experiencing a problem. So what you can do is you can create dashboards, you can also create alerts, right? To say that maybe if there's over 100,000 DHCP log messages, error messages in a day, send me an email, because something's probably not so hot, right? So it's highly configurable from that perspective. So here's an example of an email, oh, come on. Okay, well, I won't show that, but believe me, my VMware email got an alert when we were testing last night and went over our quota limit, right? So again, the thing about open-stack, people tend to focus on, oh, how do you install open-stack? How do you get it started? That's not even the, that's not the half of it, that's not the third of it, that's not the 10th of it really. It's how do you successfully operationalize these environments? So the combination of the core vSphere and NSX troubleshooting capabilities, combined with VC ops and tools like Log Insight, really fill in a lot of key gaps that exist in what you can get as raw open-stack. And so I think with that, was there anything else? We were, yeah. So I can, one of the cool thing to show is you can actually, so let's say this instance had gone to an error state. It obviously didn't, but anyone who's been in open-stack for a while knows that that can happen. So I can go to Log Insight, just take this UUID and paste it in. And I don't want to event types, I want events. So now I just basically want every event that's been related to this particular VM booting. And what's really cool here is you can see it going through all the different services, right? Here's a neutron message. Let's see, more neutron, neutron's pretty chatty. Here's a v-center. Here's actually from the ESX host itself. So I could trace this all the way through open-stack, all the way to some issue that happened on your NFS data store where it ran out of space. That's just extremely powerful from with respect to having a well-integrated solution that helps you get to the bottom of problems quickly. So with that, I think, probably good, we'll probably just take questions. I think there was one over there that I cut off earlier, then I'll go to you. So you want to step up to the mic or you can ask me to demo something? Yeah, really nice and impressive set of tools for open-stack. Thanks. My question was about the Cinder demo that you gave. And you had storage policies, gold and platinum in the v-center. And then when you went to the horizon and we created a volume, it showed you those two options, gold and platinum. So does it mean that any storage policy that I create in v-center automatically comes as a volume type in Cinder? No, it's not automatic because you may not want to expose all of your storage policies out. So there's a Cinder command that basically lets you create these volume types. And what you do is you go Cinder type create, and then you set what's called an extra spec. And there's a special extra spec format that is the kind of VMware colon storage policy, then you put the storage policy name. Okay, so that's how you... So Alex is giving the talk on vSAN at 5.20, and so there'll be more of a deep dive on the storage policies specifically. So it was because of the configuration that the names kind of matched? Yeah, they don't have to match, actually. But it's, yeah, so you could expose it to the tenant as some other name if you preferred. Okay, thanks. You got a question? Yeah, I mean, my goal is, again, it's about letting developers get the same set of behavior regardless of the underlying platform. So everything we do... So yeah, OpenStack's notion of snapshot is not quite the same thing as VMware's notion of snapshot. So what we do is we conform to the definition of the OpenStack API and give you an OpenStack-like snapshot. Okay, thanks. Yeah, great question. So when creating volumes via OpenStack, you don't have the options that you would do vSphere, you know, thin, thick, lazy, eager. Well, so that's another good question. So the same kind of the extra spec mechanism that I talked about where you're able to, on the specified storage policy, you're also able to, for example, say, thick versus thin, several of those things. So you could, you know, you as a cloud administrator can create a service offering. You know, maybe you have a enterprise grade volume and you have a, you know, cheapo volume or something. And enterprise grade is, you know, lots of flash and thick provisioned and your low end one is thin provisioned. It's a good question. All right, well, I think what do we have? Next up we have the hands on, oh, sorry, one more question. So if you have multiple clusters in your data center, then from OpenStack, when you're creating a VM, can you pick which cluster you want to choose? So the general model of OpenStack, right, is that it's just kind of one pool of capacity. Now OpenStack, and so that would kind of be the default configuration, even if you had multiple clusters. Now OpenStack supports something called host aggregates, which let you kind of say, oh, well, this infrastructure is not quite like this infrastructure. Maybe it has a different type of storage. Maybe one has HA enabled and one doesn't, something like that. And so VMware integration does work with host aggregates. And typically what you do there is it's kind of similar to what we've been talking about the volumes, is that you can create Nova server flavors that map to different backend host aggregates. And again, so, you know, you might have an enterprise grade server that maps to a vSphere cluster that has HA enabled and has really good storage on it. And the features like HA and DRS, they have to be enabled on the cluster or? So DRS does at this point. It's basically, we don't have our Nova driver dynamically spread. We just kind of rely on DRS for that. It's not a fundamental thing. It's just pretty much every customer we've engaged with wants to have DRS enabled there. HA is entirely optional. It's up to you in terms of whether you want to enable that on your clusters. Thank you. So what time is the next? Let me pull up. So we, so again, thanks for coming, folks. We have another set of, I think it was probably a break. It was a 10 minute break and then another, we'll be doing the hands-on lab with some genius bar in the back and then we'll have other open stack vendors kind of demoing how their technologies work with vSphere and NSX. Thanks.