 Hi, thanks for coming. I'm Tim Smith from GridCentric. And I'm going to be talking about virtual memory streaming and how it enables scale-out virtualization for OpenStack. So GridCentric makes an OpenStack extension called virtual memory streaming. And I'll be going into a bit more detail about what it is exactly later. But what it enables is something we call scale-out virtualization. And by that, we focus on three main things. Being able to rapidly scale virtual infrastructure. So taking a virtualized application and scaling it from a single virtual machine to dozens or hundreds of virtual machines on the order of seconds. That also plays into kind of high performance and getting the most out of your physical infrastructure. And finally, by increasing efficiency and reducing the amount of resources, physical resources, that your virtual infrastructure is taking, effectively lowering your total cost of ownership of your OpenStack cloud. So on the rapid scale front, what I mentioned earlier about taking a virtualized application, something like a web service or a virtual desktop pool, and being able to instantly scale that on demand. So as more users come to your website or as more of your desktop users log into their machines in the morning, being able to instantaneously scale up the virtual infrastructure to be able to handle that load and then being able to shrink it back down on demand as well. So VMS enables this ability to rapidly scale up and down in demand to workload in a time frame that essentially allows you to construct real-time auto-scaled applications. Virtual memory streaming is based on this ability to create what we call a live snapshot or a live image. And the idea is essentially that you take a running virtual machine as a template and create what we call a live snapshot or a live image of it. So this goes beyond just taking a regular disk snapshot. It's also the CPU and memory state of the virtual machine. And that live snapshot, we can essentially launch new virtual machines from that on demand that come up ready to run and ready to service requests. Because these virtual machines are clones of this live snapshot, we're able to do a lot of memory optimization and memory sharing among them. And because they skip the boot process, they're able to skip a lot of the boot-related network in storage I.O. that would normally occur with a full boot cycle. So moving on to the products that we provide. As I mentioned, the main technology we provide is virtual memory streaming or what we call VMS. And it eliminates that boot store I'm associated with booting up virtual machines. So if you run a lot of Windows on your infrastructure or you run a lot of application servers or web servers, that booting them up and getting them to the point where they are ready to perform work takes a lot of time and will actually put a lot of load on your network. I'll be showing a demo video shortly of booting up some Windows machines and how quickly we're able to get them to launch without using a lot of I.O.P.s. Because these virtual machines are launching from these live image snapshots, we're able to efficiently stream in the memory used that their memory footprint on demand. So they don't occupy their complete memory footprint up front. So we're essentially doing copy on write on the memory. One of the features of VMS is that we're fully integrated with Active Directory. So you can bring up Windows VMs. And as you're bringing them up, they can auto register with Active Directory. So you don't need to go through a couple boot cycles. The second product we offer, which is an open source project called Reactor, is a scale manager and load balancing piece of software that essentially can sit in front of VMS. And you can define metrics for an application that when Reactor sees a large number of users coming in or sees your response time starting to go up, can increase the number of virtual machines on the back end using VMS to quickly bring them up and then scale them back down. So all of this stuff is fully integrated with OpenStack. At the top, Reactor acts as kind of an application front end, a load balancing scale manager. We have a lot of OpenStack code that goes by the name of Cobalt that acts as a kind of interface with VMS that sits at the actual hypervisor layer. And we currently support both KVM and Zen hypervisors. So the use cases that VMS is really good for fall into a number of categories. One is your horizontally scalable web services. So these are things like WordPress or Apache or Nginx or Hadoop where the way that you go from getting a little bit of work done to getting a lot of work done is spinning up a bunch of virtual machines. And if you're constantly spinning up virtual machines, you'll find that the hit on your resources is actually big enough that you end up spending more time waiting for your virtual machines to come up than you actually do performing work. So because VMS is really good at being able to quickly spin up virtual machines, and once they're up, they're extremely memory efficient, you get a lot more out of the hardware that you have. Another use case is memory intensive middleware. So if you're running a big Java servlet, these applications typically take minutes to start up and to be able to warm up. They occupy a lot of memory. And so they're very hard to scale normally. But with VMS, you can essentially create a template live image of a VM that's already started, already warmed up, the application's ready to run, and create this live image from that and then be able to spin up new instances of your middleware servers very, very quickly. If you're doing a lot of development and test, especially across multiple platforms and multiple versions of operating systems and, say, browsers or different test configurations, you want to be able to do that efficiently. So you want to be able to do, you want to have a wide variety of environments that you're going to be able to test on. But you don't necessarily want to have them sitting around all the time. So what you want is a way to be able to quickly spin up a large number of virtual machines of one type, do your testing, and then collapse them back down. So VMS, again, because it's very quick to spin up complicated virtual machines, is very good for that use case. And finally, for Windows desktop or Windows server, Windows, when it starts up, performs a lot of IO on your storage devices just to get to the point where it's ready to be logged in. We found that it's somewhere in the order of 20,000 up to around 70,000 boot-related input-output operations. So storage IOPS, just to get to the point where Windows 7 VM is sitting at the login screen. And with VMS, what we do is we just take a single VM and we get it to the point where it's sitting at the login screen, and then we take this snapshot. And then from that point on, you can spin up new desktop VMs very, very quickly. So I'm going to play a short demo video just to show that principle kind of in action. So we've got a live image here created with a Windows 7 desktop. And what we've just done using the regular Nova client, which is going to talk to our extension, is spun up five of these clones. You can see they've got their network addresses and they're in this building state. And meanwhile, in this Horizon plugin, we can see that at the lower part of the screen, our disk operations are remaining low. And our memories, I guess we'll click over to that right now, the operations on our disk are remaining low at around 200 input-output operations per second. Normally, if you're going to spin up five desktops, you would see something around 20,000 to 70,000 input-output operations IOPS per desktop for around somewhere between 100,000 IOPS and 350,000 IOPS. But we're able to get to the point where these five VMs were ready with much, much fewer, somewhere around just around 5% of that. And as you can see, the VMs are ready and you can log into them and so on. Another thing to point out is that the memory usage, for these five VMs, they're two gigabyte VMs that they would have normally occupied around 10 gigabytes of physical memory on our host. And currently, they're sitting around two gigabytes. So just sitting there idling, they're occupying about a fifth. If we're actually to log into these VMs, start running off, start running all our applications, it would still hold steady at probably around four gigabytes total, so around a 60% reduction in memory. Anyhow, that was the demo. And we've got a booth just on the other side of this wall here. If you'd like to come by later and ask us questions or come see a live demo, we'd be happy to show you one. I'm Tim Smith from GridCentric. Again, thank you very much for coming.