This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/wiki/do/viewPage/projects.occi-wg/wiki/InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula at Sun, 06 Nov 2022 12:20:29 GMT SourceForge : View Wiki Page: InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin

Web Site
Search Wiki Pages Project: occi-wg     Wiki > InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula > View Wiki Page
wiki2115: InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula

Use Case: Interoperability across Cloud Infrastructures using OpenNebula

  • Name: Interoperability across Cloud Infrastructures using OpenNebula
  • Contact: Tino Vázquez, OpenNebula and Reservoir , DSA-Research at UCM
  • Type of Organization: Academia
  • Description:OpenNebula is a Virtual Infrastructure Engine that allows the management of Virtual Machines on a pool of physical resources and/or cloud providers. It offers three main functionalities: backend of a public cloud, tool to manage a virtual infrastructure in the data-center or cluster (private cloud), and tool to achieve cloud interoperation (hybrid cloud), the latter being relevant in this use case. The aim of this use case is to state the requirements that an API for cloud providers should take into account in order to expose an interface that will enable the management of groups of Virtual Machines across them. These requirements are gathered from the experience using OpenNebula as a tool to manage Virtual Machines from different cloud providers. Currently, there are two set of plugins for OpenNebula to access Amazon EC2 and ElasticHosts cloud providers that leverage the use of both cloud providers in a transparent fashion for the end user.

Interoperability across Cloud Infrastructures using OpenNebula - little.png

  • URL: Presentation at OGF25
  • Functional Requirements
    • VM Description: Virtual Machines should be described consistently across cloud providers using a slim set of indispensable attributes, such as:
      • Memory: Amount of RAM needed by the Virtual Machine
      • CPU: Number of CPUs needed by the Virtual Machine (this needs to be normalized)
      • Disk: Disks that will conform the basic filesystem and possibly others for the Virtual Machine
      • Network: How many network interface this Virtual Machine should have, and where should be attached
    • VM Management: API should offer functionality to enforce operations upon Virtual Machines, such as:
      • DEPLOY: Launchs the Virtual Machine
      • SHUTDOWN: Shutdown the Virtual Machine
      • CANCEL: Cancels the Virtual Machine in case of failure, or destroys it if it is running
      • CHECKPOINT: Creates a snapshot of the Virtual Machine
      • SAVE: Creates a snapshot of the Virtual Machine AND suspends it
      • RESTORE: Resumes a Virtual Machine from a previous snapshot
      • POLL: Retrieves information about Virtual Machine state and consumption attributes (percentage of Memory, CPU used, bytes transferred, and so on)
    • Additionally, Virtual Machines should be in one of the following states:
      • PENDING: VM is waiting for a physical resource slot.
      • BOOTING: VM is being booted
      • RUNNING: VM is active, it should be able to start offering a service
      • SUSPENDED: VM is suspended, waiting for a resume.
      • SHUTDOWN: VM is being shutdown.
      • CANCEL: VM has been canceled by the user or by a scheduler.
      • FAILED: VM crashed or hasn't started properly.
    • Network Management: API should expose functionality to
      • Create Private Virtual Networks
      • Attach Public IP to Virtual Machine
    • Image Management: The ability to upload disk images is fundamental to virtual machine management to avoid the need to reinstall software for each cloud provider. The upload process should return an identifier to be used in the Virtual Machine Description.
  • Non-functional Requirements
    • Security: Security should be handled using X509 certificates for authentication. Also, authorization can be based on said certificates and ACL lists.
    • Quality of Service: When used in conjunction with Haizea, OpenNebula provides advanced reservation functionality. Cloud providers API should provide similar capabilities to ensure proper QoS.
Attachments:
Interoperability across Cloud Infrastructures using OpenNebula - little.png [InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula/Interoperability across Cloud Infrastructures using OpenNebula - little.png]
Interoperability across Cloud Infrastructures using OpenNebula.png [InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula/Interoperability across Cloud Infrastructures using OpenNebula.png]
 




The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/wiki/do/viewPage/projects.occi-wg/wiki/InteroperabilityAcrossCloudInfrastructuresUsingOpenNebula at Sun, 06 Nov 2022 12:20:52 GMT