 It's us. Yes. Hello. Thank you for coming out to the exciting demo theater to see Morph Labs talk about our MCloud solutions. Both of you, thank you for coming. And because there's only two of you, if you get up, I'm going to call you out. Unless you want to get up and come closer and get, you know, I may actually have a seat right there. Come sit on the front row. My name is Christopher Ado. I'm a Morph Labs CTO. This is my Andre Hunter. I'm Hunter Neal. I'm the director of development for Morph Labs as well. So we'll talk for a few minutes about Morph Labs and what MCloud is. Try and keep it brief, and then Hunter will walk through our UI. Our background, we are a venture-funded company. We've been around for actually about five years now. We're located in Manhattan Beach. We have offices in Tokyo and Singapore and the Philippines. And we are delivering a fully integrated infrastructure as a service platform based on OpenStack. We've been involved with OpenStack and founding foundation members since the beginning. And our mission, I guess, is to provide the lowest total cost of ownership for a highly-performance, highly-scalable OpenStack installation, targeting both enterprises and service providers. What makes this unique is our hyper-dense architecture. So we are always focused on finding the best balance of price and performance. I get out of the way of the screen here. Since, obviously, with any cloud solution, you can make it a ridiculously performant if you pour a ton of money in it, but it starts to make not a lot of sense if you've spent a fortune and you can only host 10 or 15 really fast VMs. So we try and find the best balance of price and performance by combining the OpenStack as the foundation and our unique dashboard on top of that and using enterprise SSDs and partnering with different hardware vendors to work out the best platform for the solution. So we started with what was called the MCloud Helix. We partnered with Dell. This is a 2U box, a C6220. And four-year cost of ownership was about $115,000. And it was pretty great. This is about a year ago. We were one of the first people with a enterprise-targeted ESIC solution that was actually getting traction in the enterprise marketplace. And since then, we've moved on and kind of restructured into using 1U building blocks. So our solution essentially allows you to build out an OpenStack environment with the 1U building blocks. So add as many compute nodes as you want. Add additional controller nodes for resiliency and high availability. And then storage nodes are based on using Nexenta. So for block storage, you can scale out the block storage for your environment pretty easily. And the price performance actually does really well. We outperform using Unix Bench on a loaded environment compared to Rackspace and AWS were significantly score better than with Unix Bench. Pretty high IOPS. And the suggested retail price of $40 actually costs the service provider around $15, which they can turn around and sell that for a lot more, match Amazon, and significantly beat Amazon on performance. And now I'm going to hand it over to Hunter. And he can walk through the UI. OK. Here you go. And if you want to go. Excellent. Thanks, Chris. So what we've done with our solution is we've actually built a custom dashboard. So something that operates in a similar way to Horizon, but we've found that we've got additional things that our customers would request. And working on a lifecycle that is something that we can adapt to much faster than the six monthly release cycles of the typical open stack. So the other things that we include in this for, say, our service provider customers is the ability to billing to be able to integrate in very, very short order to different billing providers, like Stripe, to actually be running up and charging your customers within a week almost. It's incredibly quick. And once the hardware is installed, its configuration, a little bit of setup with bank account details on the way you go for an installation. So the dashboard that we have for demonstration today, I'll try and set up a user for us. I'll use a real one. And we can just give it an account. It's 4.2. 4.2. It's 4.2. So as I set up a user here, we have the ability to be able to configure this as well so that a service provider can choose to say if they do or don't want billing and be able to have sign up for their accounts, but not necessarily enter credit card details. I'll go through and quickly add in the details. And so fairly straightforward sign up. And users then will have access to the system and to be able to use it and to start up resources and everything else. So while this goes through, if I can. And so once we log in, we then have the ability to be able to start VMs to monitor their health and also to keep track of billing and other things that go through with that. So if we go through and create a project, or we've created a project. If we create a VM that go along with it, we can then go through and get an idea of particular costs that are going there for particular sizes and starting up a number of other things that, of course, I need to give it a name as well. And so as this instance boots, we can apply all the other things that we typically would find that you would associate it. In this case, floating IPs in security groups. Images and snapshots can be taken from the running images. And finally, at least in the case of this particular project, adding collaborators who will be able to also share the responsibility of administration in the user interface itself. So the one thing that's missing from our demo here at the moment is volumes. It's really just in this case disabled for this environment. But we do offer the ability to be able to start up volumes, snapshot, and all the other things that you typically expect from an OpenStack installation. So from here, that if we can then go back to our monitoring tab and see here that we've got at least showing the health of the one instance that's running in there. If I created a second one and go through there, then I can create an instance and then get more of an idea of how the monitoring works in this regard. So it scales up showing the health of these instances as they're running. So if I go back across to the monitoring section and drill down, you can see here now that I have two instances running and can drill down further down in there to be able to get health of the CPU, the network IO that's going through there, and block devices if they're attached. So high level administration applying actions to a particular running instance will be as possible here as well to be able to do quick work on a running VM. And so drilling further down, usage can be then retrieved and get an idea. In this case, we haven't really had enough to be particularly to be billed, but it will give you an idea of running costs. And then once your billing period comes up at the end of a month, an invoice will be sent and charged to credit cards and things like that. So that really covers the demo that we've got today. Chris, is there anything you'd like to? I think you did a great job showing off the UI. And I actually don't have anything to add. Do we have any questions? Anyone? Yes, please? With? Correct. We're not with this one. Basically, this environment is targeted towards reselling UNIX VMs, and we are not, for the providers that we work with that use that are serving Windows, they basically have to craft specific Windows images for that. And because we're not deploying on top of what's the Windows hypervisor, this environment doesn't have any hypervisor compute nodes in it. So because of the licensing issues with the demo environments, we don't deploy Windows VMs. And the warning there is basically if you could upload a Windows image in a glance through this interface, but if you weren't using the kind of modified, the cloud init plug-in for Windows, it wouldn't ingest that password. If you did have a Windows image set up with essentially cloud init capability, it would pull in that password. And it would update the admin password from the instance metadata or the image metadata or from the metadata server. That's the right phrase. The question is, what do we use for the monitoring or where are we pulling that? So sure. For this one? It's pulling it out of from KVM. And it gets stored in Rabbit. And then is it SD? That's displaying it? So the data itself is stored in Graphite, so it's accessible for users who don't necessarily want to be able to consume it or don't have to consume it through the dashboard itself. So it's available on other ports and accessible there. So we don't inject any agents into the particular instances. That's all really taken from the hypervisor and the data that's actually returned there. OK. Thank you, everybody.