Getting cross-platform: bringing virtualization management to the PPC world
Frenkel, Omer
This talk will cover * a short intro to ovirt * a bit about the code contribution effort by eldorado.org research center that made this happen * design consideration of multi arch support - objectives and constraints * basic flow for provisioning PPC enabled clusters * some code, config files etc to demonstrate what ties it up altogether Target audience: Whoever is interested in data-center virtualization in general, ovirt-engine specifically, and PPC support. Getting cross-platform: bringing virtualization management to the PPC world oVirt, the open source data center virtualization management solution is expanding the x86_64 architecture support to PowerPC hardware, among them IBM Power processor based hosts. Entering PPC world raises challenges of managing mixed arch data-centers with the need to distinguish PPC from x86_64 VMs. In this session we'll cover the main differences in virtualization needs, how we enabled the support for that in our management engine(a.k.a ovirt-engine) PPC virtualization main differences is in virtualized devices supports. Built around x8664, ovirt-engine needed to expand its cluster and VMs provisioning to fit multi architecture, and to keep migration support and proper VM configuration solid for the supported operating systems. Since some parts are work in progress (e.g live migration) for the PPC VDSM, the engine has to also manage features which are not supported for PPC while is supported for x8664 To cope with a change that span various parts and components a repository for Operating Systems and they're hipervisor's demands was created along with strategy functions around the code to ensure correct provisions and life cycle related VM functions. The session will cover what is now supported (hypervisor and VM OSs), how we provision PPC clusters and VMs and a little deeper dive to explore the mechanisms which enabled this multi-platform support along with some code examples (yes, we're going to see some code!)
 So hi everybody, sorry for the little delay, hope it's better now. So yeah, it's my talk, so I will just start. Okay, so who am I? My name is Omar Franco, I'm a software engineer and team lead in Red Hat, that's Red Hat, and I'm also an overt engine maintainer in the overt engine project. What I'm going to talk about today is how we made Overt to become a multi-platform management capable, starting with x86 and PPC64, and basically how we got Overt to be a multi-platform. I will go through a little background of what we did to make this happen, a little bit about the people that did this work, and a little bit about Overt for anyone who less familiar with it. I'll discuss the problems that we had to face, the solution that was accepted, what we did, I will show a little code and configuration, and then discuss a little what is still left to do. So, somewhere around. Our goal was bringing a multi-platform management capabilities to Overt, starting with x86 and PPC64, and basically having Overt to be a multi-platform capable. Why? Why now? So KVM on Power System was announced recently, and also there was another announcement of the Open Power Consortium by Google, IBM, NVIDIA, and some other big companies, so this becomes relevant now. Also it was a good opportunity to have infrastructure to have more platforms support in Overt, just in case more platforms will support KVM in the future. So, something very important. Everything I'm going to talk about today was contributed by developers from Eldorado, Brazil. Eldorado is a not-for-profit organization. They are located in Brazil and focused on technology development, and basically these are community members that contributed this support, and it was a really nice walk with them, and I want to talk about this just a little, because it was very interesting process with these guys. So, these guys wanted this integration. They sent a design to the Overt wiki. We, the maintainers, and other community did some review to this design, some enhancements, and once this design was accepted, the development and implementation phase started, and again we over IRC to make it a short cycle, because this guy's in Brazil, so it was a big time difference, and also over mails we solved all the issues. Our maintainers work really closely with these guys, helping them figure out all the issues that they had making sure all the code has been reviewed in a timely manner, because we really wanted, and we actually succeeded, to make it part of the current 3-4 release for Overt. So this is a really great success for us. Okay, so a little bit about Overt. Anyone here already knows Overt? Okay, good. So I'll go through it quickly, just to make sure everyone will know after that. Okay, so by definition Overt is loud-scale centralized management for server and desktop virtualization. What it means is that we have open-source alternative for applications like vSphere and vCenter, and it allows managing virtual data centers. The focus is on KVM for best integration and performance, so we are using KVM, and there is a big focus on ease of use and ease of deployment for the users. So Overt is really easy to deploy and use as administrators to create your virtualized data centers and for users as well. So it looks okay. So you could use Overt for small environments like this single data center single host, running a couple of VMs. This is basically good for demo and testing because here you don't have some really important virtualization features like live migration. Now you can grow with Overt to multiple multi data center and multi cluster environment. Basically you can see here, I hope you can see here, Overt manages multiple data center. Each data center has multiple cluster, and each cluster has multiple hosts. So cluster is some kind of a migration domain, and within cluster you can live migrate VMs from one host to another. I want to give you a really quick high-level architecture for Overt just because I'm going to talk about this components later. So I'm not going to go too deep to Overt. So we have the engine. This is a Java application, runs on Jbos. This is basically where all the logic relays and all the decisions are taken in our engine. If it's scheduling decisions and other decisions, and this is also the gateway. All user requests are sent to the engine and engine process it and do something with it. The engine talks with the hosts that actually runs the VMs. In the host we have agent, we call it VDSM. The agent has a couple of important responsibilities. So first it does all the host level configuration, if it's storage or network, and of course handles everything that related to the VMs on this specific host. We are using LibVirt for all VM operations, if it's a start, stop, and migrating. We also have another package called MAM that is responsible for scheduling and the SLA services. Finally, of course, on the host we have running a guest, so VMs, virtual machines. The guest agent within is the package that is responsible for sending information from within the guest outside. If it's IP or applications that are installed, there's information that we want to show up in the engine web admin. And also responsible for some commands on the guest inside, if it's for example single sign-on, that we really have to communicate with the host inside the guest. Okay, so what was the idea? If you remember before I showed you there are multiple data centers and each data center has cluster. What we wanted to achieve is that we could have a cluster which is x86 as today, and also have clusters from other platforms like PPC64 cluster, and in the future, if available, anything that supports KVM. So ARM is the question mark. And the goal, of course, was adding this support with minimal, as far as possible, minimal changes to the architecture inside the engine and to the UI to use the existing infrastructures and so on. So what is the problems that we had to deal with? First, Overt was designed and developed with a single platform in mind. We only had x86 supported for KVM, so this is what we developed for, and this is the only thing that we had in mind. What happens is that there is no platform specifications. For example, VM devices like network and display and disk, just the same as in the physical world, not all the configuration are supported on all platforms. So for example, in Overt you can have disk interface IDE, Overt, Overt, Oscasi, and we found that PPC64 doesn't support IDE, so we had to do some filtering to block users from trying to use it on PPC because we know it will fail. More problems that we had, so many assumptions were made without taking a platform in mind. So for example, PCI addressing is different between x86 and PPC64, so we had to deal with it in runtime. We had to change the code that does the addressing, and I will show that later. Also, some features are not supported in our platforms. For example, live migration is still not supported in PPC64, so again, it's a feature we had to block according to the architecture. So the solution that was suggested and eventually we used was using the strategy design pattern. I have some diagram of it, basically the strategy design pattern, what it says that you have the interface of what is supported, what are the actions that are supported, and you can have different implementations. So implementation one and two will be implementation for x86 and implementation for PPC64. What it allows us is a couple of important things. First, selecting the behavior at runtime. We don't need all kind of special ifs and cases in the code to select which code to run. It gathers the specific code altogether. It encapsulates x86 code in the x86 strategy and the PPC code in the PPC strategy, and it allows people that are entering the code to find the specific code very easily because it all encapsulates it together. And very important is that it allows us easily to add more architectures in the future. Other stuff that we had to take in mind is we are defining architecture in the cluster level. So we could have in one data center different clusters platforms. So you could have as I showed before cluster for PPC and cluster for x86. The CPU type is reported by the host. It allows us very easily to decide if a host can run in the cluster or not. And also in Overt we have two configuration packages that are... We are using it as infrastructure for deciding if some feature is supported. So one thing we had to do is add the architecture awareness to the configuration. So one is the global configuration for features and another package that we have, we call it OS Info. It allows us to manage capabilities in the guest OS level. So for example Windows has a set of devices that it can use and Linux has a different set. So we are saving it all in one configuration and what we had to do is to add architecture to this configuration as well and you will show an example later. Okay, so what was done so far? We can divide it to three main phases. First was to identify and move the specific code to the strategy classes. Then changing all the configuration and creating the new configuration for the new architectures that we just added. And finally some specific coding for the PPC64. So we had to, as I said, add the architecture field to the cluster and also supported CPUs. We have a supported CPU list in Overt that we are supporting. And once we implemented the strategy design pattern so we could move all the specific code to the right place and basically create some encapsulation for the x86 specific code. Configuration. So I will show, I think it's the next slide, I will show you how the OS Info configuration looks like and it gives us great flexibility because the guys that contributed the code didn't have to invent pretty much anything. They were using an existing infrastructure so they would basically just add the new architecture and the new values for the guest OSes and configuration and it was just walking out of the box. It gives us flexibility in the UI for filtering and we'll show that as well. So this OS Info, how does it look like? So this is a snippet of one OS and you can see that we added the PPC64 OS and we added this CPU architecture class within and the value for this OS is PPC64. So basically there is hierarchy so all we had to do is add x86 to the base OS of the existing OS and just add this one and all new OSes that we are going to add if it's real 6 and so on will inherit from this OS so basically it will be really easy to add more supported OSes once we verify they are working. Also you can see that here we define the devices per OS so for this specific OS since it's PPC64 the display protocols that are supported are only VNC because spice is not supported on PPC64 and this is how we use it in the code so the OS Info just you ask for the package give me what display types are supported for this OS in this compatibility version for the cluster and it will understand from the OS what is the architecture and returns the list. I will show in the UI how it looks like as well. So specific code that had to be done so first is the specific addressing that I talked before because the addressing in the PCI addressing in PPC64 is different than x86 and I will show that. Also we added the specific PPC64 devices for Vlon and Viscasi the spapper or how you pronounce it. A lot of frontend adjustments and I will show you right after that to filter out only the relevant choices for PPC and we had as I said before to block unsupported features if it's snapshotting and migration. In VDSM the host agent that I mentioned before there was some changes in the topology we added a processor name for the reported information and also how do we information that had to be changed according to the new PPC. So how does it look like in the code? You can see that one way this is the code before when we were building VM drives so there is no ask about the platform here this is just if it's virtioscazzi this is what you're gonna do there is no addressing code here because on x86 we were relying on automatic addressing from we were relying on automatic addressing from Librit and in PPC64 we had to be aware of the addressing so is it clear I hope it's not too small. You could see right under the case there is if that's a okay if there is no address so let's create it and basically you can see here we are getting the strategy by the VM and yeah we are getting the strategy by the VM architecture so this way the code is not aware of what architecture it's running right now because we are getting the right strategy and then running the code so basically running the assign scasi address code so basically the the code doesn't is not aware of the specific architecture because of the strategy. We also had a visitor design pattern which has the specific implementation in the sub project and it comes in handy the strategy gives you the correct code for the architecture and the visitor is responsible for actually executing the code that for the specific command if it's for addressing and so on. I will show you an example so you can see here that we have assigned scasi address and it's architecture command and we have implementation for run for x86 and implementation for run for PPC and you can see that for x86 it's still empty because we are still relying on the old libvirt logic and for PPC we have different addressing if it's a virtioscasi or if it's a spupper vscasi so the controller the addressing on the controller is different. So what we have ready you can create cluster and mention the architecture VMs templates and pools everything that Overt has importing and exporting keeps the architecture information attaching disks according to the specific strategy architecture sorry searching we can search VMs by the specific architecture and managing VMs if it's starting stopping you know of course. So a little bit how it looks like I hope you can see it okay so this is the new cluster dialogue and you can see that below we added the new supported CPUs so it's all a family of IBM power and basically once the user selects the specific CPUs then the architecture is set from this CPU so every CPU has architecture so it's automatic. This is the new virtual machine dialogue so you could see that above the cluster is a PPC cluster and so the operation system is filtered out and I can see only the supported so currently we only have other OS but once we have verified more VM OS this list will for sure grow. This is still the new virtual machine dialogue you can see as I mentioned before SPICE is not supported on PPC so again this is filtered out in the UI and this is really nice because it's pretty much magic it's all the infrastructure of the OS info does this for us so it was really easy and nice to do. Adding new disk for VM dialogue so again you can see that the disk interfaces are filtered out according to the architecture so we know that we are adding a disk to VM which is a PPC VM so we will filter out IDE because it doesn't work. What still need to be done so there are still some issues booting from network on PPC VMs and this the guys from El Dorado are checking this out but more important we have blocked features on PPC because they are still not implemented or not exactly working so live migration is the most important one also taking snapshots VM snapshots is still not supported and hotplug for disks is not supported we do have hotplug for NICs for network interfaces but disks still not. Okay so some in it up. Today thanks to this work the Overt Engine is multi-platform ready today we have x86 and PPC64 already in in the 34 release but it's very important to say that we now have the infrastructure to easily add more architecture really easily so once we have KVM supported on more architecture it will be should be easy work to edit. There is a lot more information so there is our website and the wiki that the guys from El Dorado created for the engine and for the VDSM which are the projects and all the information and implementation is there. That's it. Yeah. So basically we have difference between CPU because the virtualization features are different KVM is different on this on this versions because you have different features that you could use and I don't know the IBM features by heart but let's say that one CPU has some features that KVM can use and the other doesn't so I have to specifically say what is the CPU type for this cluster because I want migration to work. So basically you don't have to fill this out if you leave it blank the first host that you will add to the cluster will set this for you. Yeah we have automatic setting if you set it if you leave it empty. Yeah. Yeah. I think there is some issue there with the storage. I don't know exactly what was the problem with snapshot but on PPC so maybe I'm not updated. I hope it's working as you say. Yeah. Did you integrate that all in O-word or did you integrate it in lib-word as well? So they also did work on KVM was announced regardless and I think they did some work in lib-word but mostly it was VDSM and the engine so I think that lib-word does support it but there are issues in in VDSM. So it works better on O-word than in lib-word itself. Sorry. It works better than in lib-word when I just use plain lib-word with the shell for that with the virtual. That's good news. I ask you if that's the case. I don't know. It should work. We are using lib-word the same as using vish so VDSM is using lib-word as well. Okay. So it's in lib-word. Yeah. Okay. And then another question you said arm. Yeah. You know I'm quite horny on the till and I can't wait till March because I'm dead set about the new arm up to runs. Do you know of any work in that? I have no idea. I have no idea. I'm sorry. I don't know if they if they work on KVM for arm. I don't think there is work on KVM for arm. I don't think so but I didn't look for it. Okay. Yes. Sorry again. Okay. So the question was actually at this point what you're displaying or what I understood from your display is that you already have Linux running on the machine and then you can build other Linuxes on top of that. Yeah. That would mean that the L-par had to already be defined. Is there any plan? What would be defined? The L-par the logical partition on the machine itself. Okay. So is there any plan to interact with the HMC so you can do configuration of the L-par or do dynamic L-par on it? Actually I don't know. I don't really know about this. I'm sorry. On IBM power. So yeah I think it's below because we are using KVM and KVM is is user space so I don't I don't think it's it has any interacting there. Okay. We are off time. Thank you very much.
 So hi everybody, sorry for the little delay, hope it's better now. So yeah, it's my talk,  so I will just start. Okay, so who am I? My name is Omar Franco, I'm a software  engineer and team lead in Red Hat, that's Red Hat, and I'm also an overt engine  maintainer in the overt engine project. What I'm going to talk about today is how  we made Overt to become a multi-platform management capable, starting with x86 and  PPC64, and basically how we got Overt to be a multi-platform. I will go through a  little background of what we did to make this happen, a little bit about the  people that did this work, and a little bit about Overt for anyone who less  familiar with it. I'll discuss the problems that we had to face, the solution  that was accepted, what we did, I will show a little code and configuration, and  then discuss a little what is still left to do. So, somewhere around. Our goal was  bringing a multi-platform management capabilities to Overt, starting with x86  and PPC64, and basically having Overt to be a multi-platform capable. Why? Why now?  So KVM on Power System was announced recently, and also there was another  announcement of the Open Power Consortium by Google, IBM, NVIDIA, and some other  big companies, so this becomes relevant now. Also it was a good opportunity to  have infrastructure to have more platforms support in Overt, just in case  more platforms will support KVM in the future. So, something very important.  Everything I'm going to talk about today was contributed by developers from  Eldorado, Brazil. Eldorado is a not-for-profit organization. They are  located in Brazil and focused on technology development, and basically  these are community members that contributed this support, and it was a really  nice walk with them, and I want to talk about this just a little, because it was  very interesting process with these guys. So, these guys wanted this integration.  They sent a design to the Overt wiki. We, the maintainers, and other community did  some review to this design, some enhancements, and once this design was accepted,  the development and implementation phase started, and again we over IRC to make it  a short cycle, because this guy's in Brazil, so it was a big time difference,  and also over mails we solved all the issues. Our maintainers work really  closely with these guys, helping them figure out all the issues that they had  making sure all the code has been reviewed in a timely manner, because we  really wanted, and we actually succeeded, to make it part of the current 3-4  release for Overt. So this is a really great success for us. Okay, so a little  bit about Overt. Anyone here already knows Overt? Okay, good. So I'll go through it  quickly, just to make sure everyone will know after that. Okay, so by definition  Overt is loud-scale centralized management for server and desktop  virtualization. What it means is that we have open-source alternative for  applications like vSphere and vCenter, and it allows managing virtual data  centers. The focus is on KVM for best integration and performance, so we are  using KVM, and there is a big focus on ease of use and ease of deployment for  the users. So Overt is really easy to deploy and use as administrators to  create your virtualized data centers and for users as well. So it looks okay. So  you could use Overt for small environments like this single data  center single host, running a couple of VMs. This is basically good for demo and  testing because here you don't have some really important virtualization  features like live migration. Now you can grow with Overt to multiple multi  data center and multi cluster environment. Basically you can see here, I  hope you can see here, Overt manages multiple data center. Each data center  has multiple cluster, and each cluster has multiple hosts. So cluster is some  kind of a migration domain, and within cluster you can live migrate VMs from  one host to another. I want to give you a really quick high-level architecture for  Overt just because I'm going to talk about this components later. So I'm not  going to go too deep to Overt. So we have the engine. This is a Java application,  runs on Jbos. This is basically where all the logic relays and all the  decisions are taken in our engine. If it's scheduling decisions and other  decisions, and this is also the gateway. All user requests are sent to the engine  and engine process it and do something with it. The engine talks with the hosts  that actually runs the VMs. In the host we have agent, we call it VDSM. The agent  has a couple of important responsibilities. So first it does all the  host level configuration, if it's storage or network, and of course handles  everything that related to the VMs on this specific host. We are using LibVirt  for all VM operations, if it's a start, stop, and migrating. We also have  another package called MAM that is responsible for scheduling and the SLA  services. Finally, of course, on the host we have running a guest, so VMs,  virtual machines. The guest agent within is the package that is responsible for  sending information from within the guest outside. If it's IP or applications  that are installed, there's information that we want to show up in the  engine web admin. And also responsible for some commands on the guest inside, if  it's for example single sign-on, that we really have to communicate with the  host inside the guest. Okay, so what was the idea? If you remember before I  showed you there are multiple data centers and each data center has cluster.  What we wanted to achieve is that we could have a cluster which is x86 as  today, and also have clusters from other platforms like PPC64 cluster, and in  the future, if available, anything that supports KVM. So ARM is the question mark.  And the goal, of course, was adding this support with minimal, as far as possible,  minimal changes to the architecture inside the engine and to the UI to use  the existing infrastructures and so on. So what is the problems that we had to  deal with? First, Overt was designed and developed with a single platform in mind.  We only had x86 supported for KVM, so this is what we developed for, and this  is the only thing that we had in mind. What happens is that there is no  platform specifications. For example, VM devices like network and display and  disk, just the same as in the physical world, not all the configuration are  supported on all platforms. So for example, in Overt you can have disk  interface IDE, Overt, Overt, Oscasi, and we found that PPC64 doesn't support IDE,  so we had to do some filtering to block users from trying to use it on PPC  because we know it will fail. More problems that we had, so many assumptions  were made without taking a platform in mind. So for example, PCI addressing is  different between x86 and PPC64, so we had to deal with it in runtime. We had to  change the code that does the addressing, and I will show that later. Also, some  features are not supported in our platforms. For example, live migration is  still not supported in PPC64, so again, it's a feature we had to block according  to the architecture. So the solution that was suggested and eventually we used  was using the strategy design pattern. I have some diagram of it, basically the  strategy design pattern, what it says that you have the interface of what is  supported, what are the actions that are supported, and you can have different  implementations. So implementation one and two will be implementation for x86  and implementation for PPC64. What it allows us is a couple of important  things. First, selecting the behavior at runtime. We don't need all kind of  special ifs and cases in the code to select which code to run. It gathers  the specific code altogether. It encapsulates x86 code in the x86 strategy  and the PPC code in the PPC strategy, and it allows people that are entering the  code to find the specific code very easily because it all encapsulates it  together. And very important is that it allows us easily to add more  architectures in the future. Other stuff that we had to take in mind is we are  defining architecture in the cluster level. So we could have in one data center  different clusters platforms. So you could have as I showed before cluster for  PPC and cluster for x86. The CPU type is reported by the host. It allows us very  easily to decide if a host can run in the cluster or not. And also in Overt we  have two configuration packages that are... We are using it as infrastructure for  deciding if some feature is supported. So one thing we had to do is add the  architecture awareness to the configuration. So one is the global  configuration for features and another package that we have, we call it OS  Info. It allows us to manage capabilities in the guest OS level. So for  example Windows has a set of devices that it can use and Linux has a different set.  So we are saving it all in one configuration and what we had to  do is to add architecture to this configuration as well and you will show  an example later. Okay, so what was done so far? We can divide it to three main  phases. First was to identify and move the specific code to the strategy classes.  Then changing all the configuration and creating the new configuration for the  new architectures that we just added. And finally some specific coding for the  PPC64. So we had to, as I said, add the architecture field to the cluster and  also supported CPUs. We have a supported CPU list in Overt that we are  supporting. And once we implemented the strategy design pattern so we could move  all the specific code to the right place and basically create some  encapsulation for the x86 specific code.  Configuration. So I will show, I think it's the next slide, I will show you how  the OS Info configuration looks like and it gives us great flexibility because  the guys that contributed the code didn't have to invent pretty much anything.  They were using an existing infrastructure so they would basically just add  the new architecture and the new values for the guest OSes and configuration and  it was just walking out of the box. It gives us flexibility in the UI for  filtering and we'll show that as well. So this OS Info, how does it look like?  So this is a snippet of one OS and you can see that we added the PPC64 OS and  we added this CPU architecture class within and the value for this OS is  PPC64. So basically there is hierarchy so all we had to do is add x86 to the  base OS of the existing OS and just add this one and all new OSes that we are  going to add if it's real 6 and so on will inherit from this OS so basically  it will be really easy to add more supported OSes once we verify they are  working. Also you can see that here we define the devices per OS so for this  specific OS since it's PPC64 the display protocols that are supported are only  VNC because spice is not supported on PPC64 and this is how we use it in the  code so the OS Info just you ask for the package give me what display types are  supported for this OS in this compatibility version for the cluster  and it will understand from the OS what is the architecture and returns the  list. I will show in the UI how it looks like as well. So specific code that had  to be done so first is the specific addressing that I talked before because  the addressing in the PCI addressing in PPC64 is different than x86 and I will  show that. Also we added the specific PPC64 devices for Vlon and Viscasi the  spapper or how you pronounce it. A lot of frontend adjustments and I will show you  right after that to filter out only the relevant choices for PPC and we had as I  said before to block unsupported features if it's snapshotting and migration.  In VDSM the host agent that I mentioned before there was some changes in the  topology we added a processor name for the reported information and also how  do we information that had to be changed according to the new PPC. So how does it  look like in the code? You can see that one way this is the code before when we  were building VM drives so there is no ask about the platform here this is just  if it's virtioscazzi this is what you're gonna do there is no addressing code  here because on x86 we were relying on automatic addressing from  we were relying on automatic addressing from Librit and in PPC64 we had to be  aware of the addressing so is it clear I hope it's not too small. You could see  right under the case there is if that's a okay if there is no address so let's  create it and basically you can see here we are getting the strategy by the VM  and yeah we are getting the strategy by the VM architecture so this way the  code is not aware of what architecture it's running right now because we are  getting the right strategy and then running the code so basically running  the assign scasi address code so basically the the code doesn't is not  aware of the specific architecture because of the strategy. We also had a  visitor design pattern which has the specific implementation in the sub  project and it comes in handy the strategy gives you the correct code for  the architecture and the visitor is responsible for actually executing the  code that for the specific command if it's for addressing and so on. I will show  you an example so you can see here that we have assigned scasi address and it's  architecture command and we have implementation for run for x86 and  implementation for run for PPC and you can see that for x86 it's still empty  because we are still relying on the old libvirt logic and for PPC we have  different addressing if it's a virtioscasi or if it's a spupper vscasi so  the controller the addressing on the controller is different. So what we have  ready you can create cluster and mention the architecture VMs templates and  pools everything that Overt has importing and exporting keeps the  architecture information attaching disks according to the specific strategy  architecture sorry searching we can search VMs by the specific architecture  and managing VMs if it's starting stopping you know of course. So a little  bit how it looks like I hope you can see it okay so this is the new cluster  dialogue and you can see that below we added the new supported CPUs so it's all  a family of IBM power and basically once the user selects the specific CPUs  then the architecture is set from this CPU so every CPU has architecture so  it's automatic. This is the new virtual machine dialogue so you could see that  above the cluster is a PPC cluster and so the operation system is filtered out  and I can see only the supported so currently we only have other OS but once  we have verified more VM OS this list will for sure grow. This is still the new  virtual machine dialogue you can see as I mentioned before SPICE is not supported  on PPC so again this is filtered out in the UI and this is really nice because  it's pretty much magic it's all the infrastructure of the OS info does this  for us so it was really easy and nice to do. Adding new disk for VM dialogue so  again you can see that the disk interfaces are filtered out according to  the architecture so we know that we are adding a disk to VM which is a PPC VM so  we will filter out IDE because it doesn't work. What still need to be done so  there are still some issues booting from network on PPC VMs and this the guys  from El Dorado are checking this out but more important we have blocked  features on PPC because they are still not implemented or not exactly working so  live migration is the most important one also taking snapshots VM snapshots is  still not supported and hotplug for disks is not supported we do have hotplug  for NICs for network interfaces but disks still not. Okay so some in it up. Today  thanks to this work the Overt Engine is multi-platform ready today we have x86  and PPC64 already in in the 34 release but it's very important to say that we  now have the infrastructure to easily add more architecture really easily so  once we have KVM supported on more architecture it will be should be easy  work to edit. There is a lot more information so there is our website and  the wiki that the guys from El Dorado created for the engine and for the  VDSM which are the projects and all the information and implementation is there.  That's it. Yeah. So basically we have difference between CPU because the  virtualization features are different KVM is different on this on this versions  because you have different features that you could use and I don't know the IBM  features by heart but let's say that one CPU has some features that KVM can use  and the other doesn't so I have to specifically say what is the CPU type for  this cluster because I want migration to work. So basically you don't have to  fill this out if you leave it blank the first host that you will add to the  cluster will set this for you. Yeah we have automatic setting if you set it if  you leave it empty. Yeah.  Yeah.  I think there is some issue there with the storage. I don't know exactly what  was the problem with snapshot but on PPC so maybe I'm not updated. I hope it's  working as you say. Yeah. Did you integrate that all in O-word or did you  integrate it in lib-word as well? So they also did work on KVM was  announced regardless and I think they did some work in lib-word but mostly it  was VDSM and the engine so I think that lib-word does support it but there are  issues in in VDSM. So it works better on O-word than in lib-word  itself. Sorry. It works better than in lib-word when I just use plain lib-word  with the shell for that with the virtual. That's good news. I ask you if  that's the case. I don't know. It should work. We are using lib-word the  same as using vish so VDSM is using lib-word as well. Okay. So it's in lib-word.  Yeah. Okay. And then another question you said arm. Yeah. You know I'm quite  horny on the till and I can't wait till March because I'm dead set about the new  arm up to runs. Do you know of any work in that? I have no idea. I have no idea.  I'm sorry. I don't know if they if they work on KVM for arm. I don't think there is work on KVM for arm.  I don't think so but I didn't look for it. Okay. Yes.  Sorry again. Okay. So the question was actually at this point what you're  displaying or what I understood from your display is that you already have  Linux running on the machine and then you can build other Linuxes on top of that.  Yeah. That would mean that the L-par had to already be defined. Is there any plan?  What would be defined? The L-par the logical partition on the machine itself.  Okay. So is there any plan to interact with the HMC so you can do configuration  of the L-par or do dynamic L-par on it? Actually I don't know. I don't really  know about this. I'm sorry. On IBM power. So yeah I think it's below because we are using KVM and KVM is  is user space so I don't I don't think it's it has any interacting there. Okay.  We are off time. Thank you very much.
_FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_0_215.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_216_347.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_348_503.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_504_2039.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_2040_3443.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_3444_3659.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_3660_4103.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_4104_5627.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_5628_6275.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_6276_7199.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_7200_7451.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_7452_7811.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_7812_8027.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_8028_8459.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_8460_8507.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_8508_8615.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_8616_11447.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_11448_11747.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_11748_13559.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_13560_14291.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_14292_15875.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_15876_16631.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_16632_17651.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_17652_20231.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_20232_20435.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_20436_21275.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_21276_21983.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_21984_28571.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_28572_30767.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_30768_30911.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_30912_31211.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_31212_31811.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_31812_33047.png _FOSDEM_2014__Getting_cross-platform__bringing_virtualization_management_to_the_PPC_world_33048_42977.png
So hi everybody, sorry for the little delay, hope it's better now. So yeah, it's my talk, so I will just start. Okay, so who am I? My name is Omar Franco, I'm a software engineer and team lead in Red Hat, that's Red Hat, and I'm also an overt engine maintainer in the overt engine project. What I'm going to talk about today is how we made Overt to become a multi-platform management capable, starting with x86 and PPC64, and basically how we got Overt to be a multi-platform. I will go through a little background of what we did to make this happen, a little bit about the people that did this work, and a little bit about Overt for anyone who less familiar with it. I'll discuss the problems that we had to face, the solution that was accepted, what we did, I will show a little code and configuration, and then discuss a little what is still left to do. So, somewhere around. Our goal was bringing a multi-platform management capabilities to Overt, starting with x86 and PPC64, and basically having Overt to be a multi-platform capable. Why? Why now? So KVM on Power System was announced recently, and also there was another announcement of the Open Power Consortium by Google, IBM, NVIDIA, and some other big companies, so this becomes relevant now. Also it was a good opportunity to have infrastructure to have more platforms support in Overt, just in case more platforms will support KVM in the future. So, something very important. Everything I'm going to talk about today was contributed by developers from Eldorado, Brazil. Eldorado is a not-for-profit organization. They are located in Brazil and focused on technology development, and basically these are community members that contributed this support, and it was a really nice walk with them, and I want to talk about this just a little, because it was very interesting process with these guys. So, these guys wanted this integration. They sent a design to the Overt wiki. We, the maintainers, and other community did some review to this design, some enhancements, and once this design was accepted, the development and implementation phase started, and again we over IRC to make it a short cycle, because this guy's in Brazil, so it was a big time difference, and also over mails we solved all the issues. Our maintainers work really closely with these guys, helping them figure out all the issues that they had making sure all the code has been reviewed in a timely manner, because we really wanted, and we actually succeeded, to make it part of the current 3-4 release for Overt. So this is a really great success for us. Okay, so a little bit about Overt. Anyone here already knows Overt? Okay, good. So I'll go through it quickly, just to make sure everyone will know after that. Okay, so by definition Overt is loud-scale centralized management for server and desktop virtualization. What it means is that we have open-source alternative for applications like vSphere and vCenter, and it allows managing virtual data centers. The focus is on KVM for best integration and performance, so we are using KVM, and there is a big focus on ease of use and ease of deployment for the users. So Overt is really easy to deploy and use as administrators to create your virtualized data centers and for users as well. So it looks okay. So you could use Overt for small environments like this single data center single host, running a couple of VMs. This is basically good for demo and testing because here you don't have some really important virtualization features like live migration. Now you can grow with Overt to multiple multi data center and multi cluster environment. Basically you can see here, I hope you can see here, Overt manages multiple data center. Each data center has multiple cluster, and each cluster has multiple hosts. So cluster is some kind of a migration domain, and within cluster you can live migrate VMs from one host to another. I want to give you a really quick high-level architecture for Overt just because I'm going to talk about this components later. So I'm not going to go too deep to Overt. So we have the engine. This is a Java application, runs on Jbos. This is basically where all the logic relays and all the decisions are taken in our engine. If it's scheduling decisions and other decisions, and this is also the gateway. All user requests are sent to the engine and engine process it and do something with it. The engine talks with the hosts that actually runs the VMs. In the host we have agent, we call it VDSM. The agent has a couple of important responsibilities. So first it does all the host level configuration, if it's storage or network, and of course handles everything that related to the VMs on this specific host. We are using LibVirt for all VM operations, if it's a start, stop, and migrating. We also have another package called MAM that is responsible for scheduling and the SLA services. Finally, of course, on the host we have running a guest, so VMs, virtual machines. The guest agent within is the package that is responsible for sending information from within the guest outside. If it's IP or applications that are installed, there's information that we want to show up in the engine web admin. And also responsible for some commands on the guest inside, if it's for example single sign-on, that we really have to communicate with the host inside the guest. Okay, so what was the idea? If you remember before I showed you there are multiple data centers and each data center has cluster. What we wanted to achieve is that we could have a cluster which is x86 as today, and also have clusters from other platforms like PPC64 cluster, and in the future, if available, anything that supports KVM. So ARM is the question mark. And the goal, of course, was adding this support with minimal, as far as possible, minimal changes to the architecture inside the engine and to the UI to use the existing infrastructures and so on. So what is the problems that we had to deal with? First, Overt was designed and developed with a single platform in mind. We only had x86 supported for KVM, so this is what we developed for, and this is the only thing that we had in mind. What happens is that there is no platform specifications. For example, VM devices like network and display and disk, just the same as in the physical world, not all the configuration are supported on all platforms. So for example, in Overt you can have disk interface IDE, Overt, Overt, Oscasi, and we found that PPC64 doesn't support IDE, so we had to do some filtering to block users from trying to use it on PPC because we know it will fail. More problems that we had, so many assumptions were made without taking a platform in mind. So for example, PCI addressing is different between x86 and PPC64, so we had to deal with it in runtime. We had to change the code that does the addressing, and I will show that later. Also, some features are not supported in our platforms. For example, live migration is still not supported in PPC64, so again, it's a feature we had to block according to the architecture. So the solution that was suggested and eventually we used was using the strategy design pattern. I have some diagram of it, basically the strategy design pattern, what it says that you have the interface of what is supported, what are the actions that are supported, and you can have different implementations. So implementation one and two will be implementation for x86 and implementation for PPC64. What it allows us is a couple of important things. First, selecting the behavior at runtime. We don't need all kind of special ifs and cases in the code to select which code to run. It gathers the specific code altogether. It encapsulates x86 code in the x86 strategy and the PPC code in the PPC strategy, and it allows people that are entering the code to find the specific code very easily because it all encapsulates it together. And very important is that it allows us easily to add more architectures in the future. Other stuff that we had to take in mind is we are defining architecture in the cluster level. So we could have in one data center different clusters platforms. So you could have as I showed before cluster for PPC and cluster for x86. The CPU type is reported by the host. It allows us very easily to decide if a host can run in the cluster or not. And also in Overt we have two configuration packages that are... We are using it as infrastructure for deciding if some feature is supported. So one thing we had to do is add the architecture awareness to the configuration. So one is the global configuration for features and another package that we have, we call it OS Info. It allows us to manage capabilities in the guest OS level. So for example Windows has a set of devices that it can use and Linux has a different set. So we are saving it all in one configuration and what we had to do is to add architecture to this configuration as well and you will show an example later. Okay, so what was done so far? We can divide it to three main phases. First was to identify and move the specific code to the strategy classes. Then changing all the configuration and creating the new configuration for the new architectures that we just added. And finally some specific coding for the PPC64. So we had to, as I said, add the architecture field to the cluster and also supported CPUs. We have a supported CPU list in Overt that we are supporting. And once we implemented the strategy design pattern so we could move all the specific code to the right place and basically create some encapsulation for the x86 specific code. Configuration. So I will show, I think it's the next slide, I will show you how the OS Info configuration looks like and it gives us great flexibility because the guys that contributed the code didn't have to invent pretty much anything. They were using an existing infrastructure so they would basically just add the new architecture and the new values for the guest OSes and configuration and it was just walking out of the box. It gives us flexibility in the UI for filtering and we'll show that as well. So this OS Info, how does it look like? So this is a snippet of one OS and you can see that we added the PPC64 OS and we added this CPU architecture class within and the value for this OS is PPC64. So basically there is hierarchy so all we had to do is add x86 to the base OS of the existing OS and just add this one and all new OSes that we are going to add if it's real 6 and so on will inherit from this OS so basically it will be really easy to add more supported OSes once we verify they are working. Also you can see that here we define the devices per OS so for this specific OS since it's PPC64 the display protocols that are supported are only VNC because spice is not supported on PPC64 and this is how we use it in the code so the OS Info just you ask for the package give me what display types are supported for this OS in this compatibility version for the cluster and it will understand from the OS what is the architecture and returns the list. I will show in the UI how it looks like as well. So specific code that had to be done so first is the specific addressing that I talked before because the addressing in the PCI addressing in PPC64 is different than x86 and I will show that. Also we added the specific PPC64 devices for Vlon and Viscasi the spapper or how you pronounce it. A lot of frontend adjustments and I will show you right after that to filter out only the relevant choices for PPC and we had as I said before to block unsupported features if it's snapshotting and migration. In VDSM the host agent that I mentioned before there was some changes in the topology we added a processor name for the reported information and also how do we information that had to be changed according to the new PPC. So how does it look like in the code? You can see that one way this is the code before when we were building VM drives so there is no ask about the platform here this is just if it's virtioscazzi this is what you're gonna do there is no addressing code here because on x86 we were relying on automatic addressing from we were relying on automatic addressing from Librit and in PPC64 we had to be aware of the addressing so is it clear I hope it's not too small. You could see right under the case there is if that's a okay if there is no address so let's create it and basically you can see here we are getting the strategy by the VM and yeah we are getting the strategy by the VM architecture so this way the code is not aware of what architecture it's running right now because we are getting the right strategy and then running the code so basically running the assign scasi address code so basically the the code doesn't is not aware of the specific architecture because of the strategy. We also had a visitor design pattern which has the specific implementation in the sub project and it comes in handy the strategy gives you the correct code for the architecture and the visitor is responsible for actually executing the code that for the specific command if it's for addressing and so on. I will show you an example so you can see here that we have assigned scasi address and it's architecture command and we have implementation for run for x86 and implementation for run for PPC and you can see that for x86 it's still empty because we are still relying on the old libvirt logic and for PPC we have different addressing if it's a virtioscasi or if it's a spupper vscasi so the controller the addressing on the controller is different. So what we have ready you can create cluster and mention the architecture VMs templates and pools everything that Overt has importing and exporting keeps the architecture information attaching disks according to the specific strategy architecture sorry searching we can search VMs by the specific architecture and managing VMs if it's starting stopping you know of course. So a little bit how it looks like I hope you can see it okay so this is the new cluster dialogue and you can see that below we added the new supported CPUs so it's all a family of IBM power and basically once the user selects the specific CPUs then the architecture is set from this CPU so every CPU has architecture so it's automatic. This is the new virtual machine dialogue so you could see that above the cluster is a PPC cluster and so the operation system is filtered out and I can see only the supported so currently we only have other OS but once we have verified more VM OS this list will for sure grow. This is still the new virtual machine dialogue you can see as I mentioned before SPICE is not supported on PPC so again this is filtered out in the UI and this is really nice because it's pretty much magic it's all the infrastructure of the OS info does this for us so it was really easy and nice to do. Adding new disk for VM dialogue so again you can see that the disk interfaces are filtered out according to the architecture so we know that we are adding a disk to VM which is a PPC VM so we will filter out IDE because it doesn't work. What still need to be done so there are still some issues booting from network on PPC VMs and this the guys from El Dorado are checking this out but more important we have blocked features on PPC because they are still not implemented or not exactly working so live migration is the most important one also taking snapshots VM snapshots is still not supported and hotplug for disks is not supported we do have hotplug for NICs for network interfaces but disks still not. Okay so some in it up. Today thanks to this work the Overt Engine is multi-platform ready today we have x86 and PPC64 already in in the 34 release but it's very important to say that we now have the infrastructure to easily add more architecture really easily so once we have KVM supported on more architecture it will be should be easy work to edit. There is a lot more information so there is our website and the wiki that the guys from El Dorado created for the engine and for the VDSM which are the projects and all the information and implementation is there. That's it. Yeah. So basically we have difference between CPU because the virtualization features are different KVM is different on this on this versions because you have different features that you could use and I don't know the IBM features by heart but let's say that one CPU has some features that KVM can use and the other doesn't so I have to specifically say what is the CPU type for this cluster because I want migration to work. So basically you don't have to fill this out if you leave it blank the first host that you will add to the cluster will set this for you. Yeah we have automatic setting if you set it if you leave it empty. Yeah. Yeah. I think there is some issue there with the storage. I don't know exactly what was the problem with snapshot but on PPC so maybe I'm not updated. I hope it's working as you say. Yeah. Did you integrate that all in O-word or did you integrate it in lib-word as well? So they also did work on KVM was announced regardless and I think they did some work in lib-word but mostly it was VDSM and the engine so I think that lib-word does support it but there are issues in in VDSM. So it works better on O-word than in lib-word itself. Sorry. It works better than in lib-word when I just use plain lib-word with the shell for that with the virtual. That's good news. I ask you if that's the case. I don't know. It should work. We are using lib-word the same as using vish so VDSM is using lib-word as well. Okay. So it's in lib-word. Yeah. Okay. And then another question you said arm. Yeah. You know I'm quite horny on the till and I can't wait till March because I'm dead set about the new arm up to runs. Do you know of any work in that? I have no idea. I have no idea. I'm sorry. I don't know if they if they work on KVM for arm. I don't think there is work on KVM for arm. I don't think so but I didn't look for it. Okay. Yes. Sorry again. Okay. So the question was actually at this point what you're displaying or what I understood from your display is that you already have Linux running on the machine and then you can build other Linuxes on top of that. Yeah. That would mean that the L-par had to already be defined. Is there any plan? What would be defined? The L-par the logical partition on the machine itself. Okay. So is there any plan to interact with the HMC so you can do configuration of the L-par or do dynamic L-par on it? Actually I don't know. I don't really know about this. I'm sorry. On IBM power. So yeah I think it's below because we are using KVM and KVM is is user space so I don't I don't think it's it has any interacting there. Okay. We are off time. Thank you very much.
What I'm going to talk about today is how we made background of what we did to make this happen, a little bit about the people that did this work, configuration, and then discuss a little what is was bringing a multi-platform management I'm going to talk about today was contributed by contributed this support, and it was a really community did some review to this design, some and again we over IRC to make it a short cycle, virtualization features like live migration. Now you can grow with Overt to multiple multi data has multiple cluster, and each cluster has this components later. So I'm not going to go too deep to Overt. So we have the engine. This is a with it. The engine talks with the hosts that each data center has cluster. What we wanted to x86 as today, and also have clusters from other inside the engine and to the UI to use the specifications. For example, VM devices like the physical world, not all the configuration are that later. Also, some features are not supported in our platforms. For example, live migration is architecture. So the solution that was suggested and cases in the code to select which code to PPC code in the PPC strategy, and it allows this configuration as well and you will show an it's snapshotting and migration. In VDSM the host you the correct code for the architecture and the for run for PPC and you can see that for x86 it's architecture and managing VMs if it's starting some in it up. Today thanks to this work the engine and for the VDSM which are the projects