 Hi everybody. My name is Omar Frenkel. Welcome to my session about Overt and Cloudinate. So, let's start. Okay, so first, who am I? As I said, I'm Omar Frenkel. First, I am a software engineer. This is what I do. I work at Red Hat for the last five years, a little more. And what I do on my daily basis is working on the Overt project. I'm a maintainer in the Overt Engine project. I would like to know, do you guys, anyone here knows about the Overt project? Yeah, you guys tried it? You guys played with it? Yeah? Good. That's good. And what about Cloudinate? Anyone heard of it? Okay, great. Good start. So, what am I going to talk about? So, first I'm going to talk a little about Cloudinate. I'm going to give introduction. What is Cloudinate? How does it work and how you can use it? I will give also introduction to Overt. And I will go a little deeper to Overt architecture. So, it will be the base for later on I will talk the implementation that we did for integrating Cloudinate and Overt. I will give an example of how Cloudinate is working with Overt, how Overt is using Cloudinate within. And then a little about what else is needed to make this integration more complete. So, Cloudinate. By definition, it handles early initialization of Cloud instances. What it means is that Cloudinate is a service. It runs when the VM virtual machines. Cloud instance is actually a virtual machine. I also call it VM in a short. So, when the VM boots, the Cloudinate service runs, and what it does, it looks for some user data that is provided from the cloud provider. So, for example, the EC2 metadata service, you can see the links here. If you have instance running in Amazon EC2, you can get this URL from within the instance and see some instance-specific metadata about the instance, its instance ID and some more information. And the other one, the user data, is a way to pass user custom information into the instance. OpenStack has something similar. They call it a config drive and basically the same way to pass user data, user custom data into the VM using a drive attached to the VM. And it's important to say that this data is instance-specific. Every VM has different user data passed to it on the creation. So, what you can do with it? What is this early initialization? So, basically, anything you would like to do when you first boot into your new created instance, if it's setting the hostname and root password and other simple stuff like locale and timezone, and also some more advanced things like network configuration, virtual interface configuration, if it's DHCP or static IP, better stuff like SSH keys that allows connecting to the VM without sharing the root password. So, this is a really good one. You can just post the SSH key into the instance. It will have it set already and users could log into it using their SSH keys. And the most important thing is running user custom scripts. Basically, do whatever you want. Install software. Do other configuration, create files, manage things inside the VM automatically. So, this is the fun part. How to use it? This is very easy, actually. First, you have to have on your base image or template depends on your cloud provider Some Linux distribution installed. Many distributions are supported by cloud in it. Fedora, Ubuntu, Rails, CentOS, and so on are supported already. And once you have this, you only have to install cloud in it. On it, it is as simple as you can install cloud in it and you have it. And once you have this base image, this template, just create a VM of it, create a new instance of it. Start it with the specific user data, with the specific configuration that you want to run on the VM. And cloud in it will read this configuration and will execute all the configuration according to the specific distribution. Okay, so how does it work inside just a little, because I'm going to mention these things later on. So, as I said, cloud in it is a service. It starts when the VM boots. It first looks in his configuration, in the cloud config file, what data sources it should read. There is a sample list, how it looks like the data source list. So, we have here as an example, how over it is using it with no cloud and config drive. By default, it looks for what I showed you before, the EC2 meta data service, the user data. Assuming some data source was found, it reads all the configuration from it and executed according to the specific distribution. So, there is per distribution and implementation of some commands, because they are different, like setting hostname in Ubuntu and Fedora is different, because the file locations are different and stuff like that. So, so far on cloud in it. Any questions about cloud in it? Great. Okay, so what is over it from the beginning? By definition, it's a large scale centralized management for server and desktop virtualization. What it means is that this is an open source platform for virtualization, for a data center virtualization. It provides a good alternative for vSphere and vCenter if you know it. Over it has a focus on KVM. On KVM feature, it's tailored for it and take advantage of the KVM features. And it also focus on ease of use and deployment. So, if you saw our booth yesterday, you could see a really simple all-in-one installation that was done in just like five minutes. So, environments you can deploy over it. You can have the simple one host, one data center, run a few VMs on this host. This is good for evaluating over it. If it's good for you, what are the features? How does it look like? How easy is it to use? It's also good for demos and private usages. And of course, over it can grow and have multi-data center, multi-host, multi-cluster. Cluster is in over it is a migration domain. So, all VMs in a cluster can migrate, live migrate between hosts. And basically over it can manage many data centers and many clusters and many VMs, so on. So, the over it present three ways of looking at it. Three ways to use it. First, you can see on the screen, a screenshot of the user portal. This is the basic portal that provides the basic actions simple user can do with the system. Basically, it's just look what VMs I have. I can start and stop them and I can connect to them. Some information on the side about the VM, what operation system and memory and stuff like that. And that's it. This is the simple user. All you need is here. For advanced user, what we call power user, we have the self-provisioning portal. This portal, in addition, provides a ways to create VM, provision new VMs, create templates and manage them. So, it's like a simple administrator portal that allows more power for Gizels. And, of course, we have the administrator portal. This is the full administration portal. Everything administrator needs in order to manage its data centers, manage a host, storage and network configuration, creating virtual machines, a user's permission. Everything is here and this is, I'm going to show you a little about it later on. Okay, so high level architecture of OVR. First, we have the engine. The engine is a Java application. It runs on Jbos and basically most of decision-making and business logic is done there. All user interaction, all user requests are processed in the engine and then executed. And all the metadata and configuration is saved in the engine. So, the engine is using a database, of course. We're using Postgres in order to save these configurations all via metadata. And we also use some kind of LDAP server for user authentication. So, we can connect with other LDAP servers. On the other hand, we have a REST API for integration with other components for scripting and stuff like that. And we have, of course, the web clients that I just showed you, the three web clients. And Python and today also Java, SDK and CLI for extensions for user scripts and so on. So, the engine works with the hosts. So, we have a host. On the host, we have the host agent. We call it VDSM. The VDSM is responsible for all host-level configuration. If it's connection to storage, if it's network configuration. And the VDSM is using Libert to manipulate VM. Starting, stopping VMs, all VM commands are done with Libert. And we also use a MAM project for scheduling if it's ballooning and CPU shares and stuff like that. VM images, the disks of the VMs are saved on local storage if it's a one-host setup. And for multiple hosts, we, sorry, we use shared storage. So, shared storage can be an NFS, POSIX, file-based, or it can be a block-based if it's an FCI SCSI and also, of course, GlusterFS. And finally, and most important, the VMs running on the host. We also have a guest agent. It is written in Python. And it is responsible for sending information from within the guest outside, like applications installed in the IP and stuff like that. And also responsible for some actions like single sign-on. Overt is also using spies and spiced client to connect to the guest. And actually, there is a session today at 2, if you're interested, more about that in the Overt workshop. So, what we had before clouding it, back to clouding it, now that we know about, yeah. Do you mind going to the mic or I will repeat? Great. So, the question is, you are showing a database with the Overt engine. Where did, I mean, speaking in a high level, where does all this reside? I mean, what happens if you're over the machine falls or whatever it's sending? Is there a way to give it high availability? Yeah. So, as I said, the Overt is a Java application over Jboss. So, there are HA solutions for Jboss. And in case it fails, it's important to remember that the hosts that actually run the VMs are still operative. So, VMs are running and users can still connect. The only downtime is when a user tries to create new VMs or start new VMs. So, basically, user requests are blocked while the engine is down. And your database is also highly available? The database is a Postgres database. There are also solutions for highly available, but not inside the engine, outside of the engine. So, I mean, where does it, they have, they migrate the virtual machine that has the vCenter. So, they would do that as they migrate normally. There was actually a presentation right on this, it's called the Hosted Engine. Yeah. Okay, so there is the Hosted Engine, but I will not go into that. What it means is that the engine runs on a VM, on a highly available VMs, and it's managed by another HA solution. So, basically, it gives you high availability for the engine as well. Okay. Exactly. Okay. So, back to clouding it. What we had before clouding it. So, over today, or before today, had integration only with Windows sysprep. For anyone who doesn't know Windows sysprep is basically a way to configure Windows VMs on boot. It allows to set the Windows key, it allows to set the Active Directory domain, and setting times on, basically, this is it. We had integration for this since the beginning. Yeah, probably, as you can see, it's pretty simple, times on domain, only for Windows VMs, and this happens during the boot of a Windows VM. And this is what we had so far. Now, we're missing something similar for Linux. This is where clouding it comes in. So, let's have an example of how to use a clouding it with Ovid. So, first, what we need to have is template. In Ovid, we have templates that has a Linux installed in it, and we need to install clouding it also, in addition to the operation system. Of course, you can also install any other software like the Ovid guest agent. Another thing that is optional step is sealing the VM before creating the template. Basically, you can do some un-configured command that basically set some parameters for the operation system to show the first setup on the next boot. This is not so related, but this is nice to know that you can do it. Then, you create a template from this VM. So, now we have a template with Fedora and a clouding it. Now, we need to create a VM from this template. So, how does it work in Ovid? That means ask from the engine, again, to create a VM from this template. The engine goes to the database and brings all the template information and save a new VM, a metadata configuration to the database. In addition, we need to go to VDSM and ask for it to create the disks for the VM and save them on the relevant storage domain. This is how the clouding it looks okay. This is how clouding it configuration screen looks today when running the VM. So, now that we have the VM, we know it has Fedora inside. We know it has clouding it and now we need to use it. So, this is how we pass all the user data that I talked before into the VM. So, you can see everything I talked about. Setting host names, setting network, if it's interface specific or no, DHCP, DNS, the SSH keys that I mentioned to allow connecting to the VM without password, time zone with password and below is hidden the setting of files into the VM. So, I will show it later on. Okay, so how does this work? That means ask to run the VM and it fills out all the information that he likes in the screen. The engine first create this clouding it config drive. So, we have to create the drive in a way that clouding it knows to read and looks for. Then we have the scheduling mechanism that we look for the best host according to the scheduling policy to start this VM on. And once we have it, we ask for VDSM, please create this VM for us. In its turn, it uses a libvert, creating this libvert XML. And we have QML process with our VM, hopefully with the clouding it running inside. So, what do we do for this implementation to work? On the other side, we used an existing feature that is called VM payload. VM payload basically allows user to inject files into the VM and use it as a CD-ROM or a floppy. So, you can see an example of usage in REST API. Basically, you can see the payload type is CD-ROM. This is the file name, only one file was supported. Some content and that's it. When you run the VM, this file will wait in the CD-ROM for you. Other stuff that we had to do is to create the specific CD-ROM drive. It's called the name has to be config-2 and organize all the information inside the CD-ROM in a way clouding it will know to read. There are some stuff that over does in addition to actually configure clouding it to work as we expect. So, first clouding it has something that we call instance ID. Basically, every configuration has an ID in order for clouding it to know that it already ran. So, if you run the VM on the next time, you don't want all the configuration to run again. But if the user wants specifically to run clouding it again, so we set a new ID for the run. As I said, we are setting the data source configuration, the data source list to have no cloud and config drive. So, clouding it will not look for the metadata service because we don't have it in OVIRT. It's only for EC2. And the most important, inside the drive we have two parts. One is the metadata JSON file. It contains all user configuration that is supported by clouding it out of the box. Hostname, network configuration, keys, everything is set in this JSON file in a nice formatted XML. And the other part is all the custom user data. So, here we put our own configuration for clouding it. We are setting files in this part and in the future also custom scripts and stuff like that will be here. So, in clouding it, we just needed to use the config drive data source. We just had to make sure that we are sending the right volume ID, the config dash 2. We didn't have to do much more in clouding it. We contributed only a few patches that were mainly some fixes to work right with Fedora and Drel. If I remember correctly, it was some system D related issues. And looking for the config drive device in SR0 and SR1 because this is how it works in Fedora. In VDSM, all we had to do, VDSM is the host agent. All we had to do is to extend the VM payload that I talked about before. So, we had to support multiple files first because we wanted to allow the user to send more files into the VM. And also, we had to support renaming the drive to be the config dash 2. In the engine, we had to do a little more work. So, first is the same extensions to the VM payload feature. But in addition, we had to first create the UI for this. The user could actually fill in all the information. And also, we have REST API for passing this information. And the most important stuff is the actual login, actual logic for building all this nice screen into the right formatted way. So, what are we missing? First, we would like to have all the cloud-init user data persisted into our database. This is today missing. And, sorry, we needed for better automation. What does it mean? It means that we will save the user data with the template and basically allow when you create VMs from this template better automation because if, for example, you set the SSH keys and you set the hostname to be the VM name, it will be done automatically. Another thing that we are missing is not everything that is supported today in cloud-init is supported in Overt. The most important thing is the custom user scripts, basically allowing the user to write whatever he wants to run when the VM boots, so we don't have it yet. A nice feature that we thought about that, hey, we could use cloud-init to do that, was actually allowing the user to check if he likes the Overt guest agent installed. So we could use cloud-init to install it as a custom user action. One thing that is a long shot in case that cloud-init would be supported in the right way on Windows, we might be able to replace Windows XP or maybe enhance Windows XP with cloud-init. So I'm not sure about this one, it's thinking, but maybe we could do that as well. Another thing, if you remember at the beginning, I told you that Overt is a platform for data center virtualization, but actually you could use Overt also as a cloud provider, as a cloud infrastructure. And we have on our roadmap some features like instance type that will allow better cloud flows. For example, setting hardware templates and flavors and cloud-init could fit in to make these flows even better. So questions, I have a demo, I don't know how much time do I have. Questions? Okay, so I have a quick demo if you like. So basically what does it look okay? Because I changed the resolution. Basically what I'm going to show you is creating a VM from a template that I already made and setting some cloud-init information and run it and you can see it working. So what I'm doing here, excuse me, it's a record, I wanted to do a live demo, but my server is in Tel Aviv and it doesn't work well, so this is better. What I'm going to do here first, I'm going to create a new VM. So I'm selecting my cluster and selecting my predefined template. You can see it's Fedora 19 with cloud-init template that I made before. Now what I'm doing is selecting the optimization. We have two types of optimization, one for server and one for desktop. There are some small differences, whoops, what did it do? There are some small differences. The main thing is that desktop does a thin provisioning and server does a cloning. So desktop is of course more faster. Now all I have to do is just type in some name, no hands. And go for it. So let's see that happens. Great. It takes really quick, as you can see because this is desktop, this is thin provisioning. No much work need to be done. And what I'm going to do now is start the VM. So I'm going to the initial run tab and I will click that I do want cloud-init. I set here only hostname to be the default as the VM name. For simplicity this is usually what user wants. And I'm going to attach a file to the VM. This is the part that you couldn't see in the screenshot before. So I set here some file. No, this is not a custom string. This is part of cloud-init. Okay, so clicking OK actually starts the VM and the process that I showed you before. Creating the config drive, sending it to VDSM, QM process started. And the VM is run. This is the first time that I ran this VM. And now I will connect to it using Spice. So you could see the Spice client opens. And Fedora is starting. I think you could also see here this is the first boot. It says all the red stuff on the first boot. Okay, so this is Fedora coming up. It will take only a second or two or three. What's going on? And now I'm inside the VM just checking that those two configurations that I did actually happened. So if you remember I set the hostname and I put some file under temp. So you can already see the hostname is whatever we set there. And the file is here. And the content as we entered in the user portal is here. In the administrator portal is here. So this is a quick not-so-live demo. And that's it if you have any questions. Thank you.