Basic Configuration 3.2
Therefore, the following sections cover each specific component of OpenNebula that can be tailored and/or configured to better adjust the OpenNebula installation to the particular needs of your infrastructure and the potential cloud users.
The most basic configuration you will have to do is related with the hypervisor technology installed in you hosts. By default OpenNebula comes with KVM drivers activated but you can also select other drivers and modify the driver configuration to tune some of its parameters. To know more about these components you can read the Virtualization Subsystem guide.
The next step is configuring the host monitoring. IM (Information Manager) driver should match the Virtualization driver we have configured as both will deal with the hypervisor. You can leave this as it is if you are going to use KVM or read the Host Subsystem guide to change or configure it.
Default OpenNebula configuration is prepared to use a shared filesystem between the frontend and hosts to store the images used by the running VMs. This driver is called
shared, if you want to change it you can use the Storage Subsystem guide as a reference.
OpenNebula is able to manage a simple networking model using bridges to communicate but this is not the only networking model. You can learn more about the various networking options and configurations in the Networking Subsystem guide.
OpenNebula features various authentication and authorization mechanisms. There are wide array of choices, from builtin methods, to out-of-the-box external components or even the possibility to develop new mechanisms. A good entry point to this information is the Auth susbsystem overview. The guides to manage users and their permissions are here:
This component is an easy to use web interface with the same functionality as the CLI. Comes with wizards that ease the creation of OpenNebula objects (VMs, networks, etc) and is a good entry point for the users of your resources. The guide to configure this component is at Sunstone GUI Server.
To gather information on the usage of the resources to do accounting and generate graphs for Sunstone there is another component that needs to be running. Read Acct & Stats guide to learn how to use this component.
The oZones component lets us manage various instances of OpenNebula and make shards from them. With it you'll be able to manage the resources on every zone and create more intricate deployments. The guide is at Introduction to oZones.
A Hybrid Cloud is an extension of a Private Cloud to combine local resources with resources from remote Cloud providers. OpenNebula offers the possibility of integration with a public cloud provider in order to satisfy peak demands, for which the local infrastructure is not enough. A good starting point is this nice introduction to the Hybrid Cloud possibilities using OpenNebula.
Aside from standard CLI and Sunstone we can ask for resources in an OpenNebula installation using public cloud interfaces. Two public interfaces are packed within the distribution: the EC2 Query interface and the Open Cloud Computing Interface (OCCI). The document that guides the installation of these servers is at Introduction to Public Cloud Computing