 So, hello, guys. Welcome to this session. My name is Alessandro Pilotti. I'm from Cloud Bids Solutions. We're going to talk a little bit about how to integrate OpenStack and Windows. How many of you guys have worked with Windows workloads in the cloud? One, two, three, a little bit? OK. All right. So we'll have two, let's say, main areas during the quick presentations. One is related to a guest operating system, so running Windows workloads, actually, in the cloud. And the second part is related to using Hyper-V as a hypervisor. I apologize for my terrible voice. I just got a terrible cold by coming here to Hong Kong. Usually it's the other way around. While moving to colder climates, you get a cold, but this time it went this way. OK. So Windows is a guest. Windows can be executed on any hypervisor, usually no. So you can have it on top of Hyper-V, of KVM, of ESXi, of XEPX, and server, and so on. So it's absolutely relevant for this perspective. You have only to take care to optimize the images in order to run in the best possible way. But that's more or less the same thing that you will do for Linux images. There is no particular difference, as I was saying, compared to Linux for image handling. You just create your image. You throw it in glance, and off you go. Let's say the only major difference is that you don't have AMI, AKAI formats. For the simple reason that you don't have a kernel, you don't have a RAM disk, and you don't have a root disk for this perspective. So you will always work with entire images. But that's so different from what you already do with the QCOW images, just as an example. Another big difference is that your images, most of the time, we will have to be cis-prepped. This is a new thing, probably, for people not used to the Windows domain. When you have an image, in Linux, you just copy it, you put it in glance, and just duplicate it. In Windows, you have to make sure that when it boots up, it will have a different SID. It's actually a little bit of a myth, this. It's not true that in every single condition, you need to have a new SID. Let's say, to be safe, it's better to do it. But if you need absolutely to squeeze out another few seconds from your boot time, you can avoid it. It's up to you. Just don't think that you're obliged to do it. It's just better. OK. Guests initialization. Well, you know that in OpenStack, or for the sake of written in any cloud environment, you have quite a lot of work which goes on in the cloud provisioning system, including, of course, the compute nodes, in which you're preparing an image, creating a virtual machine, booting it up, attaching resources like volumes and so on. But from the moment in which the virtual machine starts, the machine is on its own. It's a very bad practice to operate on the internals of the machine from the hypervisor itself. For example, resizing at the east coast of LaGrad. That's a job that competes to the machine itself. Well, most probably you guys are used to cloud in it for Linux images. So when we started this work, you probably know that we are handling almost everything which is Windows related in the OpenStack domain. So when it was time to take care of the guest operating systems, what we did was to look at cloud in it and think about porting it to Windows. Unfortunately, even if cloud in it is a very nice piece of software, it's very coupled with not only with the POSIX APIs, but also in the way which you interact with the operating system or Linux. For example, for creating users or managing initialization of processes and stuff like that. So what we did is to create a separate project. And this project is called cloud-based in it. It was actually the beta name of the project. They say the code name of the project, it just stuck afterwards. Why to separate projects? Well, why? Because it was simply impossible to just port the code without refrading it. And the second part is that we wanted something that was also Apache 2 licensed. Because as you probably know, cloud in it is GPL. Well, we wanted a license which was giving more freedom to our customers in a banding of course this code in their projects and having a license which was more compatible with the rest of the OpenStack world. We still plan to merge it back. And one important thing, since we've right it in a completely decoupled way for the operating system, including Windows, let's say there are factories everywhere when it's about instant city classes which interact with the operating system, we have in the works also port to free BSD. So if you guys need to have free BSD workloads on OpenStack, well, let's talk about it. So one important thing, working out with Microsoft technologies, of course, we come from the C-Sharp school, C++ and so on. But we wanted to be sure that this project was absolutely friendly for everybody in the OpenStack domain. So it had to be written entirely 100% in Python. There are also some technically interesting things inside of the project. For example, the resize of the volumes is entirely done in Python by interacting directly with common classes and common interfaces. While lots of other activities will just use C-types to load Windows native APIs and operate with them. I have to say that Python gives a lot of flexibility for this perspective. So the code is there. Currently, it's on GitHub on our cloud-based repository. We are planning to move it to Stackforge. We are just thinking about if we want to limit it to OpenStack or open it also to other clouds, like, for example, Cloudinit does. It has a plug-in architecture. So each plug-in can be executed the once or more times at boot. And the status of fixed plug-in is maintained in the registry. This is kind of similar to what Cloudinit does. The difference is that Cloudinit uses the file system. Here are the most important plug-ins. Create user, set user password. That goes without saying, OK, what I do. SSH public keys. You might wonder why the heck we deploy SSH public keys with us. Well, the idea is that some customers or some users like, anyway, to deploy an SSH service or Windows. We don't do it by default when it's possible. And the second part that we will see pretty soon is that we encrypt through that specific key the user password in a way that is going to be available to the user directly to the novel client. Extend volumes. That's another pretty interesting one. So whenever you boot your machine, you have different flavors with different disk sizes. It will simply resize all the volumes to the maximum size. You can also tweak it by specifying which volumes you want to resize. By default, it will do it forever for all of them. User data. That's, of course, the most important one. You're able to execute any type of user data. You can execute bash. Of course, you need to have a bash installed on Windows. But most important, you execute PowerShell scripts or command power scripts. PowerShell, if you ever heard about it, it's an amazing scripting environment. I'm a big fan of bash myself. But PowerShell, it's object-oriented programming combined with shell scripting. There is simply a comparison out there. We support multi-part as well, which means that we support heat. Tomorrow, I'm going to have a session, a workshop, actually for one and a half hour and five o'clock, in which we're going to show quite a lot of different type of templates. For example, how to deploy an exchange server environment with an Active Directory Exchange Server, a front-end server. How to deploy, just with one click, a SharePoint environment. How to deploy an Active Directory Domain Controller, or just an AES server. Heat is simply bringing that touch, let's say, of platform as a service that we really needed. Especially because this way, we can hide all the complexity of the Windows environment from the user or from the DevOps, which typically is more Linux-skilled. And this will actually increase the opportunity for adoption of Windows-type workloads in the clouds. And for you guys, which work with customers, which require Windows-type workloads, this actually will give you the possibility to deploy this type of applications without necessarily knowing them in detail. OK. From the metadata perspective, we support the main ones, so the HTTP metadata, the old school 169254169254. We support config drive, and we support EC2-style metadata. So all the main things. There is, of course, one important thing that we have to take care, which is related to the password management. So in Grizzly, we have a new option, or better said, since Grizzly, in which you can generate your password during boot. So sadly, in Windows, we cannot yet, by default, deploy a public authentication system. You can do it with smart cards, for example. Use smart cards all the time. But you cannot do it with SSH-type public yet. We are working on that. We will come out with something later probably this year. But for the moment, the idea is that you need to have a situation in which you will never, ever pass a clear text password over on a safe channel to the guest. And the only way to do that is having the guest generating the password. And send it back on a secure channel. To do that, we simply generate a random password in the guest. CloudBaseinit does that. We encrypt it with a public key of your SSH keeper. And at that point, the only way to decrypt it is by using the private key. So this way, the encrypted password goes on the metadata. So this is an extension on the metadata that got in Grizzly, which consists in not only getting data from the metadata service, but also posting them. So you're posting back this encrypted data, which is encrypted so nobody can do anything with it. And from your Nova client, you just issue a Nova get password, name of the machine, and path to your private key. Et voilà. So it's a 14 characters random password. So it's made for cut and pasting. It's not paid for being read manually. The idea is that, of course, you can log in in the machine via RDP, for example, a remote desktop. And for that moment, all you can change it to whatever you want. But the important part is that we made sure that everything is safe and secure all over the way. One problem, this requires the HTTP metadata, especially considering that the cloud-based init, like cloud init, falls back to config drive if the HTTP metadata is not available. It means that sometimes, if your HTTP metadata service fails, you might not see the password. In that case, well, is that infrastructure an issue, from this perspective? Because anyway, it waits two minutes of time out before giving up and going on the config drive. If this happened, you can still go on the console, the BSE console, for example, and look in with the administrator password. Which is the administrator password? It's not set. You're obliged to reset it when you log in. But you have to do this only on the interactive console. No way to do it over the network, for security reasons, of course. A very important thing, we got authorized by Microsoft to release an official OpenStack Windows Server evaluation image. We released the first one. It was the Windows Server 2012 last year, actually, for the Grizzly release. And now, two weeks ago, 2012 R2 got released. And we released the new version. It's very important, the fact that it's a Microsoft endorsed release, meaning that you cannot just go and unload it, you have to go, accept the Microsoft devices. We made sure, of course, that you cannot just unload it directly. So if the question is, can I just have you get the image, the answer is no. Have to go there, press accept, and then you can get it. It's available for KVM. It's available for Hyper-V. And pretty soon, also for ES6i, vSphere, and XEPEX and server. How to build an image? Lots of people are asking us how to build an image for Windows. So to the point that we decided to provide our scripts. Those are fully unattended. So it's completely automated. Think about a kickstart, or a preceding. It's very simple. You just provide the name of the image. That's a KVM example. You provide a floppy, which contains an unattended XML file containing all the instructions. You provide the ISO. In this case, you see the ISO form, the evaluation version, but you can provide any other version. Then you just create the QCOW image. And you issue the KVM statement to random machine. It will actually do everything. And when it finishes, it automatically shuts down. So you can just wait for the KVM command to finish. When it's done, you can just take it and put it in glance. No need to press a single button in the Windows UI. What does it do? It's fully automated. It set our wallpaper. This is the most important feature, of course. It performs the drivers and tools installation. So for example, in HyperV, there is no need to do anything because, of course, everything which is related to HyperV, it's already integrated on the Windows machines since 2008. It installs the virtual IO drivers. So actually, it detects on what hypervisor you're running. If you're running on KVM, it will look for the virtual IO drivers. If you run on ASXI, it will look for the Enver tools. If you're running on XS server for the XS server tools and so on. So you have one single image to rule them all, to say so. It does the Windows updates. And that was pretty tricky because Windows updates means that you have a full cycle of updates. And then you have to reboot. And this goes over for two or three times, usually. Well, no worry. This script will do everything for you. Just reboots, another check, new updates, reboots, and so on. Finally, cloud-based init, installation, fully unattended, sysprepping, shut down. Over. Image ready. So the scripts are there. Please feel free to take them, tweak them, use them, do whatever you want. OK, we are running over time. Just very quickly, we have a heat template for Active Directory, Exchange, SharePoint, SQL server, IAS. If you guys have additional workloads that you would like to automate, just let us know. It will help us. We have, of course, an enormous experience in unattended installation of everything which is Microsoft related or Linux related. So it's pretty useful for us. OK, last thing, Hyper-V. Hyper-V is free. So I don't think that just because it's Microsoft, you have to pay for it. It's absolutely free. More free than SXI, for example, because you don't have any limitations. You have all the memories that you want. You have all the features that you want and migration and so on. Please take a look at our website. We're going to publish quite a lot of tricks about how to use it, even if you don't, are not used to it. It integrates perfectly in OpenStack, like anything else. OK, Neutron. We are porting OpenV switch to Windows. If you want to see a demo code to our boot, we are almost done. We have a release by the end of the year. And that was it. Thanks for coming.