 Good morning everyone or good afternoon. I'm still jet lag. So, you know for me It's like night middle of night or something. How's everyone doing? Good good. All right. Don't worry if you accidentally fall asleep because you are jet lag We won't call you out or you know make fun of you or draw anything on your face or anything like that So thanks for joining us. We're here to talk about How you would go about explaining open stack to a person who is primarily Been in the VMR space, right? Obviously VMR has a very large install base in the enterprise and they have a certain set of kind of Ways of looking at things and so there's a large group of people out there who have v-sphere in their environments who Are looking now at open stack and they may be struggling and Scratch on the heads on like, okay. How do I look at this open-sack thing? What's involved? And so Kenneth and I are here to try and provide some as the name implies bridging the gap right some mapping between opens that concepts and terminology and corresponding v-sphere Concepts and terminology, so I'll do a quick introduction. My name is Scott Lowe. I work for VMware I'm in the network and security business unit and a member of the open-stack team at VMware who's responsible for driving VMware integration with and support of open stack. This is my co-presenter No, you're not on It's on. Oh, there you go. Oh, my name is Ken Hoy. I work at rack space And I'm proud today. I worked for a company that focused on VMware so all right So I don't think you know either neither can or I are going to claim that we're open-stack experts Both of us have a long history in the v-sphere space But we think that that might help in priding this kind on this mapping for you if you guys are you know Die hard opens that folks and that's where you've been and you're trying having a hard time saying, okay Now I've got some other guys who are die hard VMware folks and we just aren't speaking the same language What we're gonna try and do is help with that a little bit today So before we actually get started just want to encourage you guys feel free to participate ask questions Interrupt share your own experiences anything like that So you're more than welcome to participate in the session be very interactive Feel free to post updates to whatever social media platform that you use Twitter or Facebook Instagram whatever, you know, whatever your poison is there Feel free to photo photos videos whatever we're gonna make this presentation available online after the event not only through the open-stack organization the summit itself, but Either I or Kenneth will publish the slides through like slide share or speaker deck so all right, I'm gonna kick off the session with a look at the architecture and then I'm gonna hand it over to Kenneth who is going to do some stuff on the Terminology and then some operational considerations and again the focus here is all about How do we take the expertise and the experience and the knowledge that you guys have with open-stack? And help make that consumable by folks who have not been exposed to open-stack And maybe these maybe folks within your own organization who are the VMware advocates Maybe you're not all that familiar with open-stack either and maybe you're coming from a VMware background And you're having some problems kind of a thinking about how this works and why we use different terms and how the operational procedures are different So on so forth, and that's our focus. We're not gonna be talking about specific technical integrations There is a demo theater going on tomorrow that I'll be doing and I'll have more on that at the end of the slide deck Where we'll talk about specific technical integrations. This is more of a people focused talk, okay? So starting out with the architecture. I think it's really important to understand and again If you're in the open-stack space, you know this but if you're someone who's coming from a VMware centric background You may not be aware, but these these products have very different origins Okay, they came from very different places and as a result those those origins have had a profound influence on How the product has evolved and how the the solutions are off So, you know vSphere originated as a way to provide virtualized infrastructure And so everything you see in vSphere is emulating the underlying infrastructure So we have these construction of virtual machines and again Ken It's going to go into more detail on some of the terminology whereas in open-stack. We talk about instances, right? And then and there's more than just a name change here There's actually it's a reflection of the underlying architecture and kind of the the mindset or the idea that was behind the creation of each one Open-stack originated as a way to provide consumable infrastructure Services and so we saw how many of you guys were in the keynote this morning saw the you know Acronyms as a service, right? So sometimes we get this whole as-a-service thing a little overblown I think but it really is applicable when we talked about the open-stack architecture said it was intended to provide services I'm not necessarily intended to provide infrastructure We don't expose the infrastructure as much in open-stack as you would see with a traditional Virtualization solution like a vSphere hyper V or something of that nature instead It's much more abstract and so as you're talking to folks who don't have a lot of open-stack experience and And perhaps they're coming from a VM or background What we really want to do is we want to get them out of this mindset right now They're in a mindset of I have a hammer and therefore everything looks like a nail It's a very common saying in the states. It may not be quite so common outside the states But we want to break them out of that and break them away from this one tool that they have which is just this tool to provide virtualized infrastructure into something more like this where they have a collection of tools and each of those Collection of tools is designed to fulfill a specific purpose. I'm generally speaking You're not going to use a screwdriver for the same thing that you would use a hammer for now I have known people to do that. It generally doesn't turn out. Well All right, and so everything we talk about as you're talking to these folks is helping them break out of the The one tool mindset into this idea that these have very different purposes and therefore evolved to in very different ways, so let's Talk about what I what I view as some of the key architectural attributes that really make a difference When you're talking open stack versus VMware right and this is again You know taking what you guys are very familiar with here And I'm not here to you know to go into great detail on the open stack architecture because there are other folks here that are Far more qualified than I to do that But these are kind of the key attributes that I think really make a difference when you're talking to someone who has a VMware experience and they're prominently a vSphere administrator and that's what they cut their teeth on these are some key things I think that are different that you want to point out, right? First of all, this is a loosely coupled architecture versus a very tightly coupled and I have a diagram talk about that in more detail It's again a reflection of the origin of the of the what's being built So where opens that came from was a very different place than where vSphere came from and it's evolved in different ways But one of those attributes is the fact of the way the the code comes together in a variety of ways API driven obviously everything is is driven through the API's right Inherently built to support multiple hypervisors Obviously vSphere. Well, it is a hypervisor. So not not built to support multiple hypervisors By the way, if you want more details on the specific hypervisor support, there's a link there to the hypervisor support matrix on the open stack wiki Multiple disc formats. This is a kind of an offshoot of the fact that we are supporting multiple hypervisors So we have to support multiple disc formats as well And the idea that a networking is really more integrated especially when we start talking about how neutron Is evolving it's much more about Networking being very consumable without having a deep view of the underlying infrastructure, and I'll talk more about that after Can't take some time talking about terminology and operations So just from a diagram perspective This is a very common diagram. You've probably all seen it before actually We're standing next to Ken Peppel who's the author of this diagram this morning while we're waiting for the expo session to come out So thanks for the diagram Ken appreciate that There's this link down there where you can find the diagram, but this kind of just shows you You know, it's it's a conceptual overview of what opens that looks like nothing new here You're probably all very familiar with this So I was a question. No just stretching. Okay, that's fine. No worries You're probably all familiar with this so no big deal here. No new surprises But what I wanted to do to present this to you and why I put this up on the stage was or on the screen Let's say then this is what you guys are familiar with right, but this is what a VM or person is familiar with All right, so let's let's flip back just to see right this Versus that right to very very different architectures now We could have long lengthy religious debates about which architecture is better or worse And that's not the point of this discussion the point of this discussion is to say that if you grew up with this and This is what you've become very accustomed to and you're talking to someone who is more familiar with this There's naturally going to be a disconnect in what you guys are saying, right? So hopefully the the kind of the Rosetta stone for you will be this right where we take those components that a VMware vSphere administrator is familiar with and we're going to map them on their corresponding pieces Where it makes sense on to what you're familiar with as an open-stack architect or open-stack administrator I'm sorry Blocks and Okay So, you know, there's some pieces that don't have a direct correlation for example, there's no object storage platform inside vSphere Doesn't mean you can't use one it just the product doesn't come with one Whereas that was an integral part of what opens that came with right and so as you're talking to a VM or administrator You're talking about architecture. You want to take in kind of just in consideration that You know when you talk about dashboard Or horizon depending on whether you're using the official name Which is another point of confusion whether we use the official name whether we use the code name, right? We talked about Nova computer or opens that computer. We talked about Nova and that throws them for for a loop as well They're not familiar with it is that you have to understand, you know, they may have a very different concept You know, there is no concept of a dedicated block storage service in vSphere block storage is just considered part of what the hypervisor does Right, so we go back to this architecture here ESXi is the underlying hypervisor inside vSphere and it's it provides block storage to the VMs And that's just how it goes right And this again dates back and kind of traces back to the underlying origins and architectures and purposes of the product But here you can see some brief mapping and hopefully that'll kind of give you guys some ideas of when you're talking Hope it's that architecture with a vSphere administrator This might help provide some of the glue that is necessary to help them understand All right, I'm going to turn it over to Kenneth here now and he's going to talk about some terminology differences Sure. Thank you, sir. Okay. So before I get started Just a very quick survey. How many of you here a minister or install VMware vSphere on a regular basis? Okay, good presentation. How how many you're doing open stack? Okay, looks like the same hands All right, so I'm going to walk through a little bit of some of the key terms that exist in vSphere And key terms that exist within open stack and I'm very purposefully using the term vSphere as opposed to vmware Because that's I like to tell people vmware is a company. It's not a technology So vSphere is the technology that tends to be talked about when you compare with open stack And so again another caveats. I'm going to be we're focusing specifically on vSphere, which is vCenter with exxi So there are things in here that you may say well, you can do that with vCloud automation center Or vCloud director, but I'm we're narrowly focusing right now on vCenter with exxi. So So a couple of things on on the on the right or to your left Right. It's a typical screen of what it looks like once you deploy a vm So if you think about the origins of vSphere, the idea really was how do we Uh most efficiently use Excess physical capacity on a server. So the idea was I'm going to carve up those physical servers Into virtual servers and now I basically get a bare machine and again think of it. This is at a time when Oh still is when companies are very much silo So the idea was a vmware admin may carve up by create a virtual machine and hand it off to another group that actually does the os Right and then later on the concept of templates came in to try to help kind of speed up the deploying process in contrast Open stacks kind of started from the very beginning of this idea of we are here to deploy not just bare virtualization server Virtualized servers to deploy an os that you can install an app on So here what there's no concept of deploying a machine with no operating system on top, right? You when you deploy when you choose to deploy an open stack instance You will actually have to choose an os image that sits on top when that instance is launched Any questions about that pretty clear? okay okay another thing you'll notice right in the in the vmware in the vSphere world typically That all the virtual a lot of virtual machines are purpose built. So you have a machine that runs oracles So you're going to deploy it with eight cores and 120 You know 64 gigs of memory and then you have maybe some following print servers They only need four gigs of ram and to see once one or two cpu's So ideas as you walk through a vSphere deployment, right? You would typically create The actual vm specs as you go and then maybe start copying images on them in Open stack world, right? There's the concept of flavors. So flavors are basically Like a think of a service catalog where you choose items of a shopping cart So the idea is you can pick a flavor that corresponds to a specific cpu virtual cpu or virtual ram Specification and that's what you deploy the image on And the key here is for the open stack to really work in your environment The assumption is you have a standardized infrastructure, right instead of giving people 200 choices For the type of instances they want to spin up you give them six And you try to get them to to use those because more easily works when you when you deploy them Any questions about the differences? so templates images so again in the As fees for has kind of matured along the way, right? It's kind of developed the idea of using these templates to spin up VMs with os on top of them in the Likewise in the open stack world, although you had it from the very beginning as the concept of Again os images in a repository called glance And what's interesting one of these you'll notice here is that Whereas in the vmware world in a v-sphere deployment the images kind of sit with the v-center server In the open stack world those images can sit on any Any device you want or any Sorry, any file repository that you want to sit on object storage. You could sit on block storage. It could sit on an fs share And the key there is for example in With the latest release of open stack you can actually deploy you can actually store an image in a public cloud system And so that enables you to do Image portability Again, but the idea of being a a cloud environment which is usually more than one data center one location questions So virtual disk and volumes as scott mentioned in the Again because of the origins of v-sphere on the xxi the concept was this is a Basically a server with attached storage on it So when you talk as you guys may know when you look at sphere Basically everything is a scuzzy disk No matter what the back end storage may look like Whereas in the open stack world The the underlying storage is pretty much divorced from the instance itself So you can have different storage services that map to different use cases like object storage block storage and ephemeral storage Any questions Make sense So as you so as you talk with a you're an open stack guy Or you're talking to a fees for admin or your fear vmware guy Try to understand open stack is pretty important to understand this concept again of that loosely coupled So the storage the storage services for open stack aren't as tightly tightly tied in So you can use a lot of different options for how you want to deploy instances Yeah Yep Yeah So yeah, so the so the comment was because in the in the v-sphere world Mostly everything's looked as a scuzzy disk Right, there's no concept of object storage per se So sometimes it's hard to explain to a vm v-sphere guy why you would need objects What it is first of all and why you would need it. So I actually have a section that talks about that later Hey, so I'm going to talk about operations So how many of you heard the kettles kettles versus pets analogy? Yes, okay, some of you have right so very Very simple concept right v-sphere again because of where it's grown up. It's it's essentially custom Virtual machines that you need to take care of you know You may have a legacy application like an oracle instance that sits on that virtual machine and the last thing you want Right it's for that virtual machine that gets sick Because then because it's not a trivial process to move that database necessarily sometimes off to another machine Or another often often that particular hypervisor node to another hypervisor node In in the open stack world. There's the concept of cloud instances Right, basically you don't really You don't really care about those those vm's right if a vm has problems You basically kill it and we start another vm somewhere else Right, and there's a lot of i'm kind of simplifying it But there's a lot of concepts behind that right because for this to work In the open stack cloud world if the assumption is being made that you have an application That can live across multiple instances, which is why no one single instance matters that much Right, so a good example with the if you're running a next-gen database like a mongo db Or react where you're going to have triplicate copies So if one of the machines that have one of the copies is having problems Don't worry about it. Just kill it right because you're going to continue running on other copies Then you just bring up a new instance and we attach the database and you're off on your merry way Right, there's no concept of let's let's see what can do to try to fix that vm. We don't care Hey, kenneth before you move on You know you're kenneth and i were talking before the session and and most people apply the kettle versus pets analogy when it comes to the instances of the vms But you can look at this a variety of ways as well I think in in in the people that i've talked to deploying, you know Any sizable open stack instance and and we run an open stack cloud inside Inside the network and security business unit at vm where that that we use for dog food and all kinds of other things And it's a you know, I would say it's huge, but it's fairly sizable The other way we look at this is the applying the cattle versus pets analogy to your actual hosts, right? Typically in an v sphere environment, you know the the sxi hosts are kind of you you look after them You make sure they're patched you take careful care of them all this kind of jazz But in a lot of open stack environments, it's like oh another hypervisor is dead I'll just just kill it will spin up another one, right? And of course there's a whole set of operational procedures that are far more common in open stack environments Like the use of configuration management tools and that sort of thing Then typically are on a v sphere environment And I think that's because of this underlying sort of approach to that So this analogy I think is applicable not only for the virtual machines, but also to the host Good point Yep And the key here is this is part of our is this part of one of the most important concepts For people that for you to understand or for you to explain to a v sphere administrator If they don't understand that difference, right open stack It's going to become frustrating For you because it is not going to have some of the features that you may expect In a modern hypervisor, so and I'm going to talk about some of those in a minute Okay, so the I talked to probably 80 percent of my Conversations of customers Involved VMware in some way and the number one question I get asked is What happens when I put my oracle server on kvm an open stack And the and the server and the hypervisor know underneath it dies And the answer is then you're down Right because it's a single is a state full single instance application Single with no replicas like you would do with MongoDB And so I when I tell them that the first thing they ask is It's what's wrong with open stack? And the answer I give them is nothing right because if you go back to that cattle versus pet analogy The concept here is that we don't think and in the open stack world We don't think application resiliency Belongs in the infrastructure layer belongs the application layer Right the assumption in open stack is a VM could die any time And so you you want to make sure that in the application side That's how you handle when a failure occurs. So that's why there's no There's not much having much of a focus on getting that kind of restarting automatic restarting of VMs So the closest thing to what you may think of as an auto restart of ha is something called instance evacuation And a concept of instance evacuation is this let's say I'm if I'm running let's say kvm And I'm using kvm a lot in my illustration because kvm is deployed in between to 70 to 90 percent of all open stack deployments today When it in when instances fail or hypervisor no fails There's an there's an ability to manually move VMs To recreate them on another on another hypervisor no With the same metadata on it But it's a manual process again because the underlying Assumption is you that application has never gone down on those on those VMs that were on the fail node, right? They've been running a lot. They've just rebound remove Oh, they've been running on the replicas on other hypervisor nodes So there's actually no rush in one sense to get to get a hope and get the VMs back up again All right, so and there's two two types of evacuation There's one with shared storage and one without in the shared storage. You basically retain the data user data that you had attached those VMs Any questions about so does that make sense why you don't have v-style ha? Yeah Except well, so in v-sphere ha is an auto is an automatic process right and you're basically A vm just kind of restarts on on another node in The open stack world in this is evacuation. It's a manual process You actually have to run a command to get the id's of all the VMs and then restart each one unless you script it and That's Right because there was there's no there was no need to have an auto ha function Because the applications are going to fail of on their own anyway Any questions about that? So I'm sure all you are from a v-motion and storage v-motion, right? So basic concept move a vm live from one hypervisor node to another hypervisor node and you typically do it In most cases in In terms of maintenance, right? If you want to do maintenance on a hypervisor node, you move the vm's off, right? Or if you're doing A dr s Distribute resource schedule you may use it to rebalance vm's across multiple hypervisor nodes so In open stack or kvm world, there's something called instance migration, which is essentially like a v-motion But you can actually move an instance live from one compute node to another compute node Again, it's a manual process, right? So what so one of the things that I get asked also is do you have in open stack? A distributed resource scheduling function where if I load up vm's I can rebalance them to another The exercise server and the question is no This is a Again, this is strict. This is really designed for doing maintenance On a on a specific physical compute node. There's no concept of rebalancing things But again the application layer Right is where you do the intelligence rebalancing workloads when necessary Questions about how this works So a little bit of eye chart. So let's talk about the storage piece a little bit quickly So here's something that That I actually have to take some time to explain to a lot of vmR guys Is that a concept of ephemeral storage? So again in the vSphere world Everything is a permanent persistent scuzzy disk Right that that the exercise server thinks is locally attached Or the vm's think is locally attached, sorry But in the open stack world, this is actually what came first And ephemeral this is basically a a volume That you That where the root where the os is also is where the root partition is The reason it's called ephemeral is when that instance when you terminate an instance in open stack The data is purged. This is gone any data that you have on it Right. So in the vSphere world you can you could kill a vm and the data would still Sit in the data store But in the open stack world, we just assume you don't need it anymore And again, it's back to that concept right kettle first kettle versus pets That data is probably sitting in multiple copies somewhere else with some other instance anyway So why bother even keeping it around just would be a waste of resources Okay Just a quick word is some people sometimes get confused and think that when you reboot an instance The storage goes away. It doesn't it stays but Any changes you've made may get lost Okay, so block storage So There is a there is a use case of course for having persistent user data For certain types of workloads and that's where the block storage comes in so a block storage In in a In the open stack context is basically an iSCSI volume that you can attach To a running instance. So think of it as it like going up to a machine and plugging in a usb drive So if you want to terminate that instance, you just unplug the usb drive and plug into another usb And to another instance again instances are completely disposable And the last thing I want to talk about is the object storage side So how many of you are familiar with object storage in some way of used it? Okay, okay decent number, right? So really the concept of object storage is what do I do What do I do when I when I have millions of objects? Right, what do I do if I am workday or I'll concur and have millions of receipts images? I got a store on rickipedia Right and I've got millions of web pages And when I need to retrieve them I can't because a file system takes too long to walk the tree So the concept of object storage is Every object actually has all the metadata for it sitting with that file or the object So therefore I don't have the scale of the limits that would have with an nfs or a sift share So now I can store millions of objects right in silver to retrieve them relatively quickly Right and again, and there's a concept of having multiple copies of this data everywhere Right again, so if one if one set of data fails, I can I can get it at another location And if you talk to certain people who are in the cloud world They would say this is a non negotiable for cloud That you have to have object storage because again the concept is of cloud is with scaling workloads To a very large environment So if the assumption is you should be able to handle millions of files You it's very difficult to do that if not impossible if you don't have some kind of object storage back in Any questions about object storage? No All right, so Scott's going to talk about networking and then we'll take some time if we can have answer any questions you may have Thank you, Kenneth. All right so hopefully you're beginning to get a feel for some of the Differences in philosophy and architecture and mindset between a typical vSphere kind of deployment or environment and a typical open stack Deployment or environment the last way we want to point out is is specific to networking And really as we look at networking particular with the deployment of neutron and moving forward as you look at some of the older nova network models, you know flat and Flat manager and flat dhcp and vlan manager those are a little more analogous But one of the key differences here is that networking in vSphere is The only term I could really find use was separate and I say separate because it wasn't typically something that Was done when you were deploying workloads now in the same way, you know You have to go into open stack and and create your networks and create your routers and create your subnets And that's sort of thing before you typically can consume them with multiple instances But the configuration in vSphere was was always a little more tied to the underlying infrastructure And and so you had to make sure that you were aware what the underlying infrastructure was that your configuration on the virtual side Matched the physical side if there were mismatches between them Then it caused connectivity problems not going to stuff and you didn't have the really the ability to decouple Your networking from the underlying physical network Whereas when we look at and again, especially Focusing on neutron and moving forward when you look at our open stack is deployed in conjunction with neutron Then we have a great deal of flexibility in how we deploy networks and attach instances to those networks In a way that's it's very decoupled and isolated from the underlying network Right and this is without us getting into any discussions about the various You know plug-in models for neutron and all that kind of jazz Obviously, that's a you know a fairly high level kind of statement to make there But if you want to talk in more detail afterwards feel free to grab me But just to give you sort of an illustration of what we're talking about here This is probably a diagram that if you've managed to vSphere environment, you've seen it at some point Right. This is a typical configuration. I believe this is actually taken from a vSphere distributed switch Um, as opposed to a vSphere standard switch But it shows that we have to know the specific vLan IDs that are in play And we have to make sure those vLan IDs are appropriately configured on the the trunks or the uplinks going into the servers and Unlike any jazz and if there's a mismatch anywhere along the way if you if you fat finger the vLan ID Or you forget to pass one of the vLan IDs across the trunk or something of nature Then things just don't work and and it's broken and that's that right and even the very concept of having like A distributed switch versus a standard switch is is very different as well because you know distributed switch you have this this Switching that occurs locally, but the configuration is elsewhere and a standard switch configuration switching done locally As opposed to when you look at how it's done in in neutron now this is a screenshot taken from My private cloud right which is a couple of ems running on my my home lab infrastructure But this is just running this is running actually grizzly Not even not even hibana right and this is the open vSwitch plug-in for neutron Quantum at the time because of the release But you know when I want to go in and I'm going to create some some networking All I have to do is go in here and say hey, I need a new network and Here's the subnet that I want attached to it and yeah I want some dhcp services or no I don't and yeah Here's the gateway or I don't want a gateway whatever it is And then it's just a matter of going in and saying oh, okay Yeah, this instance needs to be attached to that network and all the network connectivity plumbing is handled for me Right because of the way neutron kind of isolates The the opensack networking pieces from the underlying physical network. I don't necessarily need to know all of these details Especially as a consumer, right? I'm just coming in and I'm consuming Services and again that goes back to this philosophy this mindset of opensack being designed to provide services That allow you to consume them via your applications and you know can Point out that you know the applications are really they're intended to be distributed They're intended to be resilient resilient redundant so that the underlying infrastructure doesn't have to provide those things So it's a very different sort of mindset in how networking would be approached in a typical v-sphere environment versus how you would approach Networking in a typical opensack deployment using using neutron Now I'll we'll get into resources in just a moment and we'll go through these but Before we proceed are there any other questions or any comments anybody that would like to share before we move forward? Wanting back? Yeah, okay sure go ahead Absolutely, so the slide deck is going to be available If I recall correctly the opensack foundation will make it available through the summit site But then either Kenneth or I will also publish it through our own personal slide share speaker deck Sites as well. So yeah, so it'll be available on a variety of ways. Absolutely not a quite not a problem at all Any other questions or comments before we move forward? All right, Kenneth do you want to go over some of these resources real quick and then I'll do the next show so the first place if you're thinking about Possibly trying this out and deploying Open stack and maybe even open stack with vm v-sphere and kvm living together. Yes, they can live together It's kind of like fighting brother. No If they actually can't work well together So the configuration reference guy, which is new in Havana So they took in they took the hyper visors section that used to be in a computer compute Administration guy and moved it out to the configuration reference guy So you follow that it'll walk you through how to configure all the hyper visors that is supported by open stack so that You can do that So on my personal blog I've been I kind of did a series on v-server On open stack. So I you follow that it walks through a whole bunch of Things to consider and it also talks a bit about the difference between v-sphere versus kvm with open stack And that series by the way, it's uh, you know, I'm not just saying this because he's up here presenting with me But it's it's an outstanding series if you are a v-sphere ad man You're familiar with the v-sphere and you're moving into open stack or vice versa Definitely go give those a read. It's lots of great information in there lots of great diagrams I stole a couple for a document. I was creating the other day. So good stuff there. Absolutely have a look at that Other sessions and things that are going on here that may also be of interest to you tomorrow Dan Wenlandt is presenting a session at 8 15 titled open stack plus vm or customer success stories and what's next And at that point he'll be talking about some of the technical integration points of how v-sphere for example could be used with in conjunction with open stack As ken just mentioned that is certainly a possible thing and something's very supported and you heard Mark Schroeder worth talking about that and the key work the keynote this morning In addition tomorrow afternoon at 2 p.m. I will be over here at the demo theater Be doing fingers crossed a live demo if the network gods smile upon me and my latency back to the united states isn't too bad of Some new integrations that were released with Havana With v-sphere and also some stuff that hasn't been released yet that will be previewing For upcoming releases as well. So if you're interested in some of the technical side of that As opposed to the the people side that we've been discussing here Then feel free to either hit dan session and or my demo theater session tomorrow afternoon at 2 o'clock Here's our contact information. We'd love to hear from you feel free to shoot us questions Hit us up on twitter or whatever I think we have a little bit of time before the next session comes in So at this point we'll entertain any additional questions that you may have Or you can just take off whatever works for you. Yeah, right here. Come on up Okay, so the question was you can deploy with vmware Should you deploy with vmware and really that's a business use case question, right? You know that the as kenneth explained the kind of the the idea behind open stack was that this is for multi instance workloads That are stateless and exist across multiple instances and that sort of thing If you have applications like that and you want to deploy them on open stack running on v-sphere sure no problem If you want to kind of shift that mindset a little bit You want to kind of twist it and you want to deploy some single instance workloads inside Open stack because you like the way open stack kind of packages itself But you want to have a hypervisor that provides some additional resiliency to handle those single instance workloads That might be one use case where you can do that It's really driven by use cases business needs Great question any other questions you guys may have All right, feel free to grab us afterwards. Thanks for your time. Enjoy the rest of the day