 there. I'm Justin Rackliffe, work at Fidelity Investments. This is Alessandro Pilotti, Club of Solutions. And we are talking about VDI on OpenStack today. I wanted to kind of start it off, kind of kick it off with, why would you even think about doing that? Oftentimes OpenStack, it's kind of pigeoned in the classical IaaS model. It's for hosted applications, 12-factor, you know the buzzwords. And VDI though is in many enterprises, it's in many places that we work today. And it's kind of just hanging out there. It eats up a lot of capacity. It costs a lot of money. It's primarily a Windows ecosystem. It has two primary vendors, you know their names. It can often be aligned with big proprietary expensive stacks. And it's heavily used again in areas where there's some data sensitivity that maybe the applications are a little older, a little more mature as some might say. But it's billions of dollars worth of spend goes into doing that work. Essentially what is a VDI? A lot of people think desktop, so therefore it's not something we can do in a stack today. It's just another workload. And it has characteristics. We have stateful machines. We have state less or ephemeral machines. We do capacity management. It can be a little bit more complex because it's a highly varied workload. And when we say like that, sometimes people are browsing CNN and driving huge CPU cycles and sometimes they're using Microsoft Word and almost doing nothing. So how do you manage that capacity and what do you do to have to allocate capacity to meet those spikes? One area that is always a little bit painful is that the service quality is always aligned to the resources that are assigned to the instances. And that can be a problem. I can't give you multiple instances and make you more productive. Much as if I gave you four, five or seven laptops, you're not going to be more productive. You're not going to run an application on each. And we have to always be focused on the fact that there are things outside of the infrastructure that are going to drive the user experience. And we commonly call that a connectivity protocol. So why would we consider using a private cloud or even a public cloud, but a private cloud for VDI? So one, increased utilization. Most often we have shift workers. You'll have your spike in the morning. You'll have your spike in the evening. And then most of the time it just kind of sits around. Maybe you get some patches. That's a huge opportunity. That's capacity that can be better used someplace else. We can offer better service diversity. An open stack that might be flavors. It might be different back ends that you're going to provide. And then you could correlate that with pricing. Elasticity. This is for me, one of the most important ones. Rather than having essentially to capacitize for that 95th percentile, can I burst into capacity? Can I take advantage of some just kind of white space that gets better utilized for test and dev or something in the event of disaster? And then also getting the teams to prioritize delivering value instead of that capacity. Too often they're chasing the infrastructure. The ops teams, the dev ops teams, the SREs. They're just trying to make sure that they have enough capacity to meet the needs. And that can often kind of, again, they're just chasing it rather than responding to their customer demand and listening to what the needs are for the rest of the business. Thanks, Justin. So why open stack for VDI? Well, let's start with a couple of questions. How many of you guys are already running some VDI solutions of some sort? Very well. Perfect. How many of you guys are running Windows instances for your VDI? So the main problem with traditional VDI is the fact that the solutions out there, let's say the market leader, the Citrix, the Horizon View, the markets of their BS and so on, they don't have a real infrastructure as a service framework behind the scenes. They're all built typically on top of some virtualization solutions. And that doesn't necessarily scale as well as open stack and it doesn't necessarily offer the type of software defined everything that we get so customized to use in open stack nowadays. So why should we use open stack? Well, the first answer is this one. So open stack will offer you a full infrastructure service solution. The second thing is that it offers a standard rest API. So it doesn't really matter who built your open stack cloud. You could have done it yourself. You could have done to any of the big vendors around here. Or you could have hired a consultant to do it for you. It doesn't really matter. In the end of the day, you're getting an open stack and in order to be called open stack has to have a given set of APIs to work. So you're basically zeroed at the point of the vendor lock-in that you might have by using one of the, let's say, regular enterprise infrastructure solutions for computing, for virtualization. Next, you have improved scalability on-prem or in public cloud. So if you run only a few dozen servers, it doesn't really matter. You can just plug directly into your VMWire, your Hyper-V, your Sand Desktop, whatever else, okay? Sorry, you sent server. But if you need to scale, if you need to run thousands of VDI instances, then you need to have a full infrastructure service solution behind you, okay? So the scalability that comes with open stack in the private cloud is something that really doesn't, I mean, you cannot really replicate it with many other alternatives out there. And then there is the series of options that you can have, no? So with open stack, you choose the app providers that you want. For example, you can use Hyper-V, which has remote effects. So it will be a perfect choice for running Windows workloads on top of your open stack compute nodes. Or you can use KVM because it's the de facto standard for many people in open stack. Or you can use VM, or you can use Sand Desktop or whatever you want, okay? And same thing as a private storage. You can use SAF. You can use whatever, iSCSI or fiber channel or whatever solution, okay? You can use scale outfall server or Windows server, whatever else, no? And same thing for the networking. You can have OpenV switch. You can have your preferred SDN solution. You can have a proprietary one. It doesn't really matter, okay? So open stack, it's all about choice. And the main idea here is to be able to put your VDI solution on top of a common infrastructure as a service layer, okay? When we talk about VDI, yeah, some of you might, of course, run Linux desktops in the context of a VDI framework, okay? But it's very uncommon as a choice because Linux desktop itself is not so common as a choice, okay? You might run Mac OS, but Mac OS has a series of limitations of where you can run it, right? So it never became particularly popular from that perspective. So at the end of the day, Windows is what most of the people use, okay? Just as an idea, how many of you run Linux as a VDI desktop? Okay. A few hands, actually. I'm quite happy to see that. So for all the rest, it's Windows, right? When we started our involvement, we as Cloudbase, of course, in OpenStack, our mission was always to make sure that Windows was a first-class citizen in the OpenStack world, okay? Many people think that OpenStack is a Linux-only thing. That's absolutely not true. OpenStack is an absolutely platform-independent solution, okay? A project or set of projects. We proved that by running the entire stack, of course, on Windows and Hyper-V, but we are also particularly concerned to make sure that Windows runs perfectly fine in any OpenStack compute node, regardless of what you're running. Could be KVM, could be Hyper-V, could be VM, or whatever else, okay? So the provisioning part is performed by Cloudbase init. How many of you are using Cloudbase init? Okay, cool. Very cool. So Cloudbase init is the de facto standard for provisioning Windows instances in OpenStack, right? So it's a real pity if you're running Windows instances or in general any operating system in OpenStack without having also a provisioning agent, okay? Think about Cloud init for Linux and Cloudbase init for Windows. So first it supports every possible Windows version, Windows 7, 8, 8, 1, 10 on the guest, and also Windows Air 2012, 2012 for 2N 2016. It works also on XP on 2003, but as you all know, those are not supported by Microsoft anymore. It supports heat templates and user data scripts, which can perform any type of customization. So if you're running VDI, most probably you will want to join your desktops in an Active Directory domain. You might want to apply some group policies, you might want to apply per-user applications, configurations, whatever else, okay? So Cloudbase init allows you to run whatever you want, okay? Of course, as part of heat templates, as part of user data, whatever, especially in terms of PowerShell scripts that you can run, meaning that you can automate everything. You can download it, of course, our site. It's on GitHub OpenStack, so it's a fully open source. And the lifecycle of Cloudbase init is, of course, handled by Garrett like every other OpenStack project. It has its own continuous integration framework and so on, okay? Available on any OpenStack hypervisor, so hypervasexikvm. It's a provisioning agent, user data execution, and we recorded more than 8 million runs of Cloudbase init in one year, it's like less than one year and a half, okay? So when people say that Windows is not a big thing in OpenStack, well, those numbers tells me something completely different, okay? So 8 million instances in this amount of time, it's quite a number. If you want Microsoft support for your Windows instances in OpenStack, so if it's running on Hyper-V, the support comes out of the box, okay? Since in Hyper-V we are using only documented APIs, it means that you're already fully supported by Microsoft. If you're running on KVM, you need to be, your stack to be part of the SVVV platform, so check with your vendor if you have this capability. This means that you cannot just take the virtual-your-drivers that come from the community, and even if they work, you won't have Microsoft support. You need to have actually the certified ones from Red Hat, Canonical, Suze, and so on, okay? VDI options for OpenStack. Let's now get a little bit more into the core, into the interesting part of things. Our main idea is to keep OpenStack as the common layer beneath, and put it on top whatever VDI solution you prefer to have, okay? We will focus on two, let's say commercial ones, which is the Microsoft Remote Desktop Services and Citrix and Desktop, that Justin will then go on and demo, and then we will introduce also fully open source one, okay? So we got a lot of users coming and asking for a fully open source VDI solution, so we say, hey, why don't we just build one, you know? Why do we eliminate all the vendor lock-in at every possible level except VDI? I think it's time also to get rid of vendor lock-in even there. I will introduce briefly the Microsoft RDS plus OpenStack idea. So let's go on with the questions to the crowd. So how many of you are using the Microsoft RDS VDI? Okay, a few of you guys. Cool. This is the Microsoft solution. So if you're running a purely native Microsoft stack, to say so, which let's say all the bits and pieces in your stacks are coming from Microsoft, this is most probably what you're using. It has a web portal that allows you to have, well, first an interface where you log in with your credentials and then you can choose what type of desktops or applications to access, okay? And it allows you to do RDP over HTTP. Now RDP is the protocol that you use for remote desktop, okay? It has a connection broker, which assigns a desktop to a user request, and the connection broker offers a plugin model so that any third party can write a plugin. So as you can imagine, we wrote a plugin for OpenStack. Now a plugin uses Keystone, Nova, Neutron, Glance, Cinder, APIs, and so on, okay? So I wanted to show you briefly the architecture of this thing, so you can have the gateway, you have the RD web, which is the web portal. Behind it you have the connection broker, and inside of the connection broker, you have the OpenStack plugin, okay? This plugin will basically receive requests from the connection broker, like, hey, I have a new user, get me a desktop for this user. Then the plugin is simply fetching one available instance in Nova out of a pool assigned to that user, and from that moment on, that user will always will be tied to that specific instance until the user decides, of course, to terminate it, okay? You have also different models, so this is the persistent one, and you can also have a pooled one, in which basically you might have, for example, help the users that in the moment in which you log off, that specific desktop becomes available for somebody else, okay? So in that case, you're simply having a pool of machines that get assigned to whatever user wants it. But the logic for that is inside of that OpenStack plugin, which behind the scenes is talking to Nova, and which in turn will talk to KVM, to Hyper-V, and so on, okay? If you want to have remote effects, easy, just use Hyper-V, and the glance image will know, will actually tell Nova to use remote effects, okay? Wait, one slide before. The pros of this solution is it's a very familiar user experience for Microsoft customers. It supports traditional shared RDS as well. You know, the old school remote desktop services is also available, and we can also handle it via the OpenStack if needed. You can have Active Directory single sign-on. On the outside, the default portal is honestly horrible. It's very old school. So you need, most probably, to develop your own and to improve on top of that. And it requires ActiveX, okay? This feels very, very 1995, but it requires ActiveX if you want to add to have a direct single sign-on, meaning that inside of your browser, you will have directly the session. But, I mean, that's definitely not working on top of a Mac or on top of different browser, which are not, let's say, Internet Explorer. How many of you are using Internet Explorer? Kidding, I hope nobody. Okay, what else? It has a PowerShell support for managing all your pools, but they say it doesn't work too well with third-party plugins and pools, okay? It works, but it's still not, let's say, designed, let's say, to work directly with that, okay? Okay, I think we can move on with Citrix. Cool. He's one of the few people outside of Redmond that can still write COM ATL code, which is what you would require to actually do this work, which I think is the most amazing part of that entire thing. Again, some people might think that if you're gonna use OpenStack as an IaaS, it's an all-or-nothing kind of thing. You need to go open-source, you need to go cloud-native. That's just not true. Many folks use Citrix, and unlike VMware, VMware vertical stack, highly integrated, not necessarily open to other things, Citrix does have some options to be able to integrate alternative solutions. Citrix, historically, like way back when, was one of the primary members of the OpenStack Foundation. Now they went off and kinda did their own thing for a little bit, there's a lot of history there, but as they kinda come back, it's starting to look at, okay, well, what can we do here? Now they don't have an OpenStack provider today. They go and you know the list inside Zen Desktop Studio. They have options, and all of those things are backed by a hypervisor compatibility library. If you are a Citrix-ready partner, which I'm technically not, but I have a lot of friends, you can actually get access to the provisioning SDK, and there are those who are actually downstairs who have gotten access and made integration libraries. And you can stage those things within Zen Desktop. And while not perfect, it'll allow Zen Desktop to talk to the IaaS of your choice. And in this case, we're gonna do a, I'm gonna cross the fingers and do a little demo, I'm gonna talk to OpenStack. And in OpenStack, I'm not necessarily just gonna say, well, it's the classical KVM style on SAP, yada, yada, yada. In this case, the lab I'm gonna be connecting into actually has an availability zone for KVM and an availability zone for Hyper-V. It's something that I could choose by just adding a little bit of PowerShell stuff. What you will see is that it's not in Studio. Let's say Studio being a classic, a more mature technology has a little flexibility problem. Citrix is working on that and the team is taking a look at those things. But for the time being, much of what Citrix is, is backed by PowerShell. So I can use a little bit of PowerShell to put stuff where it needs to be, to set it up and to get it going. Another challenge also when it comes down to this is debugging and it feels a little unnatural. Doing unit testing is what you wanna do, but in this case, I had to be looking at event tracing for Windows or in Citrix parlance, the Citrix diagnostic facility or framework and taking a look at all the data that's coming out of Zen Desktop and just kinda filtering off the stuff that I care about. Now it's not ready yet because like any good regulated company, I have a little bit of bureaucracy to deal with, but the intent is that I'm gonna actually put this up in our open source repo which is fmrlc at GitHub. And so that goal's there. I just have a few more hurdles I was not able to get over before making it happen. So again, there's some code, there's some PowerShell and when it's all said and done, it will show up in studio. You just won't be able to kind of manage the connections or manage the hosting units or some of the kind of more fundamental stuff. And again, I did write code in the past, but let's say a little crusty. So that's a call out to a local guy who happens to write a couple of comics. But yeah, I'm not gonna bore you guys with that. This is the flow. If you don't know what machine creation services is, which is essentially what's doing this work, not the provisioning services stuff, but this is what's going on in the background. This is what essentially the PowerShell is gonna orchestrate. And again, it's just a series of commandments. There's a couple links in there to find out some more data. Other folks have gone in and figured this stuff out. So it's not magic. Not well documented, but not magic. And then again, this is just a high level look at it. It can talk to any open stack. Regardless of curator, distribution, fill in the blank, you're pulling right off a route. It does not matter. You're just gonna be able to load a DLL on your delivery controllers. Call essentially an XE, register plugins. And what will happen is it'll become coherent to Zen desktop. And at that point, the PowerShell commandlets that are within Citrix's SDK will actually function and you can actually go in and do stuff. Demo time? Demo time. All right. Can we switch over to number two? So this is the code for sake for a better term. It's not a whole lot. This is essentially one. Most of the stuff I've isolated here. And it's pretty minimal. I'm actually using a project from Rackspace, openstack.net. So you go to the openstack SDKs, you'll see a call out for .net. It's not alien technology. And well, it needs some love, it needs some time to be invested in it. It works. It allows me to create VMs, update VMs, manage attachments. I did find some gaps. So I did actually have to do a couple of little web client calls to put stuff here. But it's functional and it's managed code. So essentially Citrix being a very heavily .net opinionated shop, it functions. And then the fun stuff. So I'm gonna pray to the demo guys and see if this thing works right. So I'm gonna pull up here and you can see that little start flashing through is CDF monitor. So CDF monitor, again, it's event tracing for Windows. Don't think you're gonna be able to read that. It's going by, it's basically any event that's going through the entire system. So it is going out there and essentially it's starting to, it's doing the full thing. It's registering the plugin, it's creating the connection, it's creating the hosting units, it's creating the catalogs, the provisioning schemes and everything. And then hopefully, we'll see. Oops, if I can type. Let's check out instances here. And you can see, it's actually already created the instance. So one of the things that's unique to machine creation services is this concept of identity disk. So cloud-based init does a lot of this similar work. But to try to stay, let's say, pure with Citrix, I followed what machine identity service is. It was previously part of the Ardence project and is what is used in provisioning services. So I create the 16 megabyte identity disk that contains one file, a 700 byte file. And then plop it into a Cinder volume that is one gigabyte. Incredibly inefficient. But it is essentially what it happens. It doesn't matter if you use in desktop on Azure or on AWS, they all use the same framework. There's some opportunities there to improve it. One thing is, and I won't be able to demo this because I wasn't able to fix it, creators update seems to have introduced something that is preventing MIS from actually working. But everything should be hanging out there. So if I go here, I can see an identity disk that's been attached. And if I were to go back here to my hosting, I'll try to refresh it. Let me cross your fingers. So connection and hosting units. Anybody who's seen Citrix knows what this thing looks like. It looks and feels like anything else. So all your Zendesk stop admins that are out there could consume these today. I put a machine in here. I got one machine there. I got a delivery group hanging out over here. Sadly, the machine is unregistered because Zendesk stop does depend on Kerberos. So it needs that identity work to actually work. So we see that we have one unregistered machine. But that was all just done. And it's coherent to the system. So if I were to actually go off script, because I don't have to worry about redoing this demo, I can actually delete it, hopefully. Let's see if it actually goes. If it doesn't, then it's not a big deal. And it'll actually clean it up. Because the basic functionality is already kind of tied into that system. So again, you can complement OpenStack as an IAs with things that you may have today. And that's going to reduce the barriers for your teams, for your DevOps and admin teams to be able to consume the solutions that they have with the knowledge they have. But that may not be enough. You may want to do something a little bit different. You may want to see, can you go open source? Can you do something that's more cloud native, because no one's going to say Citrix is cloud native, and offer a service that takes over a part of your environment? Maybe even all. And that's next. So back to number one. Let's retry Siri's switch desktop. Yeah, I need the keyword. Must be my accent. OK, there it goes. Thank you. So open source VDI. So we are introducing here for the first time publicly a project that we recently started, and we believe has a lot of potential in this space. So to begin with, the goal is to have a fully open source alternative, top to bottom. So the entire stack has to be open source, OK? Except in Windows machines, of course. So we'll start with a web front end, which will be HTML5. Behind it, we need something which is translating, let's say the RDP protocol, into something that can be displayed into the HTML5 canvas, OK? We have two candidates there. One is called Guacamole. It's a very nice project, which currently is under the Apache Foundation. And then there is another project, which is FreeRDP web connect, OK? So we are planning most probably to support both of them. This demo now will use Guacamole. Both of them, behind the scenes, are using FreeRDP. FreeRDP is an open source Apache 2 implementation of the RDP protocol, OK? The good thing is that Microsoft published the specs of the RDP protocol. So everything that we do today with RDP protocol is based on those specs. So it's not like all the RDP clients, like I think our desktop back in the days, that had to basically reverse engineer the protocol with a lot of issues here and there, OK? Modern open source RDP clients, like FreeRDP, are adhering to the specs, which are public, OK? Which is great. In browser, HTML5 desktop sessions, meaning that your HTML5 will just go inside of the desktop. Then the next thing that we will have to add is RDP over HTTP. So you take the RDP protocol, it goes to the gateway, and from the gateway, it goes out over HTTP. On the other side, you will have an RDP client, and that RDP client will connect to the gateway and behind the scenes across your machine, OK? So that's the next thing that we will add. This will allow also to have external native clients, so it will work exactly like the Microsoft remote desktop services from this perspective, OK? So if you're familiar with the remote with the RDP client in Microsoft, that's exactly what you're talking about. So it works on the Mac, it works on Windows, and it works, of course, on Linux. There are various clients for that as well. Let's talk about, well, let's move to briefly to the architecture. As usually, one picture helps a lot to get an idea. The architectural basic details are relatively simple. The main important thing is that we want to decouple all the logic of all the individual components here in a way in which each component takes care of one specific area, OK? So they are fully decoupled from a software architectural perspective. The web client is just in charge of displaying stuff and getting input from the user. The GuacD is the guacamole demon, which is, as we were saying, before it's translating from RDP into a web socket that goes to the web client, OK? GuacD has a plugin architecture to say so. So inside there, we will have communication, for example, with Keystone that will allow us to make sure that you are authenticated in the moment in which you are requesting a given connection. Otherwise, everybody could actually go out and request it. Then there is another component, which is the VDI broker, which is brand new, OK? The VDI broker is a new project, open source, of course, written in Python and written like every other OpenStack project, using, for example, Oslo service, Oslo messaging, and all the various OpenStack common libraries. It's using Keystone, of course, for authentication. And it's written like an OpenStack project, OK? So the main idea here is that we will most probably contribute it also to the foundation if it gets, of course, enough traction. Behind the scenes, of course, is talking to the same Keystone and the same environment. The VDI broker has an important goal, assigning requests from the user to get a desktop to an actual desktop. And there is not only one desktop. So for example, when the user logs in, the user might have a series of options. For example, it might get a development desktop, a help desktop, or whatever else, because you might have different profiles that will open different type of applications. And since the RDP protocol allows you also to control individual applications and not only entirely desktops, you might have one icon from Excel, one from Word, and everything, OK? I'm superseding here on the fact that it makes sense or not. But it's a very common way of handling VDI. So the broker will simply check the pool and check if there's an available desktop in the pool to assign to a user. Of course, if the user already received a desktop, we will make sure to get back to the return to that user that specific desktop, OK? If not, if it's a new one, we will fetch a new one. One thing that we want absolutely to avoid is that when the user comes in, we have to wait for Nova to boot an entire machine. That will generally kill the experience, right? So we want to make sure that, at least in most cases, there will be a desktop ready and unassigned, able to be assigned to the user. What we did in this case is that when you create a pool inside of the configuration, there is a REST API, for the VDI broker, you will tell it how many free machines you want to have in the pool, OK? You will have a maximum, a minimum, OK, and an preferred value. So this way, whenever you consume a machine, there will be a process in the background that will say, oh, I ended up running short on the free machines available in the pool. I have to spin up a new one, OK? So let's say it's 9 o'clock in the morning, everybody logs in. We have to make sure that we have a pool available in free instances that will be consumed very quickly. And so this process will make sure to instantiate new ones so that this pool will be always available up to a max level. Because you might say, well, my infrastructure won't be able to sustain more than, let's say, 10,000, for example, instances. So at that point, we will return an error to the user. But that will be, of course, a choice of the deployer to decide how many instances maximum this specific pool should be able to allocate. And since we are using Keystone, we will also be able who is able to access the pool and who is not. So based off your user profile in your identity, in Keystone, you will have these permissions. Next, before getting into the demo, here is the current location of the project, OK? It's in very initial stages, OK? But we will plan in to add more and more. If you guys plan to contribute or you know anybody that wants to contribute, we will be more than happy to have it. This is full open source. And we want it to become a cross-company effort, OK? So it's not only a cloud-based thing or a fidelity thing or anything else, right? What else? Think that we are pretty close to the demo. Open source VDIs are on the pros side, no vendor lock-in, no licensing costs. There is nobody that will tell you that any time that they use a lock-in, you have to pay them some money. Unless, of course, you have an agreement with a company that will tell you, yes, we will provide you support, we will provide you consulting and everything, we decide to charge you on that amount of money, OK? But if you want to do it yourself, it's open source. It can leverage remote effects on Hyper-V or anything else, because again, the choice on the infrastructure or service behind, it's up to you. You can use Hyper-V. You can use KVM. You can use UBM or whatever you want. On the negative side, on the cons, of course, it's lacking some of the advanced features that proprietary solutions offer. So let's not forget that VDI is a very established market, right? So vendors in that area ended up inventing new features every time to be able to outsell the competition, no? But at the end of the day, in our experience, when we asked around, the majority of the users just wants a simple solution in which you have a portal and the user can just click on its desktop, open a desktop and use it, OK? Then, of course, there is much more than that, up layering or whatever else, various type of profiles and so on. But we can also add, as the project, of course, gets more and more mature, also on the open source side. OK, demo time is that we can forget about the one who was using PowerPoint was directly here. OK, here is the portal. It's currently very basic in the UI, so don't expect anything fancy here. So I'm just logging in. I logged in with my user, which, of course, means that I talk to Kiston. Kiston got me a token, and I passed the token to the VDI broker. And I asked the VDI broker, hey, broker, what pools do I have? And the broker said, well, you have a pool called the helpdesk desktop and one pool called development desktop. And then, if I look currently into my instances here, I can see in Horizon, or if I do another list, that there are four of them, actually five, because one we already created. Those ones are simply the machines which are waiting in the pool to be instantiated. So now I'm just clicking here. The first click means that I allocated the instance. The second click will get me directly to my desktop. So this is what I'm all behind. The instance is coming, so it takes a little bit of time because I'm actually logging in into it. So this is actually the web interface. Going to WacD, WacD is seeing that I am authenticated, and I can actually access this desktop. Then coming back, asking Nova, hey, where should I go? Nova telling him, here is your end point, which is basically a floating IP which got created on the fly for you, and a security group which allows port 3389, of course, for RDP, and then reporting it back. What version of Windows you run is relevant. Then just for the sake of the demo, I have another one which is called a development desktop that I can log in. And I have a separate session with another version of Windows. Since it's development, this case we use that decided to put in a Windows server core. But it doesn't really matter. The important thing is to show that we are able to have a solution which is fully software defined and allows the user to enter in a simple portal and get a desktop out of the blue. And having, of course, OpenStack behind the scenes creating and doing all the work for you. So if I refresh here, I will see that I have, of course, more instances behind. Of course, I lost my session while doing the session. I could go. And we can see that there is a, you can see the two top here, but time seems created zero minutes and one minute. And this means that we got one of the others got assigned to us and the pool ended up under the minimal size so the broker automatically instantiated the extra ones. So this is everything we need for a lot of customer scenarios. Of course, the project is young. We need to add stuff on top of it. But you can see that we had single sign-on. We had everything that we needed to be able to deliver desktops to our users. Okay, that was it for the demo. I think we're also almost running out of time. I think we only had a thank you slide. Okay, we are at the thank you slide. So again, we throw up a couple of resources here, but thanks for coming. I know it's my VDI, it doesn't seem like a session you're gonna find here at the summit, but it is a reality for many of our companies and for many partners and many service providers. And I think there is interest. There's desire to try to make this better and to make it a workload that actually works for OpenStack. Thanks. Any? Thank you.