opsawg J. Chu Internet-Draft ZTE Intended status: Standards Track B. Khasnabish Expires: January 12, 2012 ZTE USA, Inc. Q. Yu China Mobile Y. Meng ZTE July 11, 2011 Virtual Resource Management in Cloud draft-junsheng-opsawg-virtual-resource-management-00.txt Abstract In current Cloud and Data Center (DC) environment, the manageable virtualized resources aggregated by the Resource Management Platform (RMP) may be supplied by different types of hypervisor implementations. The RMP needs to support a variety of hypervisor APIs to allow access, management and integration of different types of resources. In order to decouple the RMP from any particular hypervisor implementation, a unified API needs to be developed. This draft presents the requirements and preliminary implementation considerations for such an API. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Chu, et al. Expires January 12, 2012 [Page 1] Internet-Draft Virtual Resource Management in Cloud July 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Chu, et al. Expires January 12, 2012 [Page 2] Internet-Draft Virtual Resource Management in Cloud July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overview of Resource Management Architecture . . . . . . . 6 3.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 3.3. Resource Management Standard Gaps . . . . . . . . . . . . 10 3.4. Interface Requirements . . . . . . . . . . . . . . . . . . 12 3.5. VRM system with a unified API . . . . . . . . . . . . . . 12 4. REST used in Cloud Resource Management . . . . . . . . . . . . 14 4.1. REST Design Best for Cloud Resource Management . . . . . . 14 4.2. REST in practice . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. IBM WebSphere CloudBurst API . . . . . . . . . . . . . 15 4.2.2. Sun Cloud API . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Oracle Cloud Resource Model API . . . . . . . . . . . 17 4.2.4. Rackspace Cloud Server API . . . . . . . . . . . . . . 18 4.2.5. VMware API . . . . . . . . . . . . . . . . . . . . . . 19 4.2.6. OGF/OCCI . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.7. SNIA/CDMI . . . . . . . . . . . . . . . . . . . . . . 21 5. REST-based VRM API . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Hierarchical Cloud Resources . . . . . . . . . . . . . . . 23 5.2. Transport Protocol . . . . . . . . . . . . . . . . . . . . 24 5.3. URI Space . . . . . . . . . . . . . . . . . . . . . . . . 24 5.4. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 24 5.4.1. Request Headers . . . . . . . . . . . . . . . . . . . 24 5.4.2. Response Headers . . . . . . . . . . . . . . . . . . . 25 5.4.3. HTTP Status Codes . . . . . . . . . . . . . . . . . . 26 5.4.4. Media Type . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Resource Representations . . . . . . . . . . . . . . . . . 29 5.5.1. Cloud . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5.2. Template . . . . . . . . . . . . . . . . . . . . . . . 30 5.5.3. VDC . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.5.4. Resource Pool . . . . . . . . . . . . . . . . . . . . 36 5.5.5. Virtual Machine . . . . . . . . . . . . . . . . . . . 38 5.5.6. Volume . . . . . . . . . . . . . . . . . . . . . . . . 40 5.5.7. Virtual Network . . . . . . . . . . . . . . . . . . . 42 5.5.8. Host . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.5.9. Snapshot . . . . . . . . . . . . . . . . . . . . . . . 47 5.5.10. Archive . . . . . . . . . . . . . . . . . . . . . . . 48 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 10. Normative references . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Chu, et al. Expires January 12, 2012 [Page 3] Internet-Draft Virtual Resource Management in Cloud July 2011 1. Introduction Based on the principle to simplify resource management, a unified, simple and lightweight Virtual Resource Management (VRM) API is required. This VRM API is RESTful (Representational State Transfer) style based, supporting basic resource management functions, such as resource (de)registration, resource request, resource scheduling, resource access, resource configuration, resource binding, etc. This API can be used in the interfaces of Resource Client (RC), Resource Manager (RM), and Resource Provider (RP) by using pairwise affiliation. Chu, et al. Expires January 12, 2012 [Page 4] Internet-Draft Virtual Resource Management in Cloud July 2011 2. Terminology Resource Pool: A resource pool is a set of resources available for assignment to services or applications. Resources in the resource pool can be assigned exclusively or shared by other resource consumer(s). Archive: An archive is a file-based representation of the state of a virtual machine at a given time. The archive includes configuration and disk data. Archives are useful for storing states that an administrator might want to return the VM to the same state of that point repeatedly. Snapshot: A snapshot is a collection of historical records (such as backup, clone or archive of virtual machine stored in Volume), as well as the place they are located. Snapshots contain primary source documents that have accumulated over the course of the lifetime of a resource or resource pool. Chu, et al. Expires January 12, 2012 [Page 5] Internet-Draft Virtual Resource Management in Cloud July 2011 3. Requirements 3.1. Overview of Resource Management Architecture Resource management provides an efficient and effective way to access, control, manage, deploy, schedule and bind resources when they are provided by resource providers and requested by resource clients. The architecture of resource management system includes the functional entities as listed in Figure 1. _________ _________ _________ / \ / \ / \ / Resource \ / Virtual \ / Cloud \ / PooL \_ _(4)_ _ _/ Resource \____(5)____/ System \ \ (RPL) / Resource \ Manager / System \ Management / \ / Inquiry \ (VRM) /Configuration\ (CSM) / \_________/ \_________/ \_________/ / \ / (2)Resource (1)Resource (5)System Request (De)Register Configuration _________/ \_________/ / \ / \ / Virtual \ / Virtual \ / Resource \____(3)____/ Resource \ \ Client / Resource \ Provider / \ (VRC) / Utilization \ (VRP) / \_________/ \_________/ Figure 1: Overview of Resource Management Architecture The following five types of function entities exist in the architecture. o Virtual Resource Manager (VRM). * VRM provides registry of virtual resources to cloud service providers and allocation of virtual resources to resource clients (consumers). This arises from the need to overcommitment resources, that is, when demand exceeds the capacity that single host/cluster can provide. * VRM has its focus on providing flexibility, transparency and reliability. Chu, et al. Expires January 12, 2012 [Page 6] Internet-Draft Virtual Resource Management in Cloud July 2011 o Virtual Resource Provider (VRP) * VRP is the entity which provides virtualized resources to the cloud environment. In the architecture above, it mainly refers to the hypervisors (virtualized case) and hosts (traditional non-virtualized case). o Virtual Resource Client (VRC) * VRC refers to the entity which consumes cloud resources to perform any task, such as instantiation of services or applications. o Cloud System Management (CSM) * CSM provides monitoring and administration of the RMP with the objective to keep the cloud system operating normally. o Resource Pool (RPL) * RPL is a collection of virtualized resources abstracted from physical resources, and it can be used to hierarchically partition the available virtualized resources. RPL can be further divided into child RPLs. * Resources in the RPL can be used exclusively by one VRC or can be shared among several VRCs. * A set of allocated resources from (child) RPL with its setting data can be used to constitute virtual DC, virtual LAN or virtual Cluster, etc. The interfaces between the pairwise function entities is as follows. 1. Resource Register/Deregister Interface. * The interface is between VRP and VRM. * When powered on, VRP registers to VRM immediately to deliver resources. * When powered off, VRP deregisters to VRM to cancel the availability of resources. 2. Resource Request Interface. * The interface is between VRC and VRM. Chu, et al. Expires January 12, 2012 [Page 7] Internet-Draft Virtual Resource Management in Cloud July 2011 * When VRC needs resources to perform services, it requests VRM to provide the requisite resources. If the request is successful, the VRC will get eligible virtual resources. * When VRC needs to get status related information of some resources, it requests VRM to provide the resources information. If the request is successful, VRC will update the presentations of the resources in the client. 3. Resource Utilization Interface. * The interface is between VRC and VRP. * When requested resources are allocated, VRC interacts with VRP to bind and utilize the allocated resources for allocated time. 4. Resource Inquiry Interface. * The interface is between VRM and RPL. * When VRM receives resource request/inquiry from VRC, it inquire RPL to check the required resources from the delivered resources. 5. System Configuration Interface. * The interface is between CSM and VRM, or CSM and VRP. * The interface is used by CSM to monitor, configure and manage the RMP. 3.2. Problem Statement There are various reasons and deployment scenarios where multiple types of hypervisors (such as VMware ESX/ESXi, Citrix Xen Server, Oracle VM, Microsoft Hyper-V, ZEN/KVM, etc.) need to coexist in one virualized environment (such as Cloud or DC). o Applications/Services running on a hypervisor may gain better support or performance by running on the other different one. o The existing hypervisor can't satisfy the required features or functions, such as disaster recovery, service continuity, security, reporting, etc. o New system requirements or virtual machine demands can be served more efficiently or cost-effectively on a different hypervisor. Chu, et al. Expires January 12, 2012 [Page 8] Internet-Draft Virtual Resource Management in Cloud July 2011 o Elimination of hypervisor vendor lock-in and avoidance of service unavailability when system upgrade or patching fails. o Multiple choices can be offered to customers so that they can select their preferred platforms. With multiple hypervisors providing different types of resources to the virtualized environment (such as Cloud or DC), it is difficult for RMP to efficiently manage and coordinate the resources. o Different hypervisors provide different VRM APIs and use different transport protocols. o Different virtualization platforms provide different views of hierarchical resources. o Different hypervisors have different ways to describe resource attributes. When the RMP consists of resources provided by multiple types of hypervisors, it needs to support different kinds of APIs. Moreover, when a new hypervisor appears or existing hypervisor upgrades, the RMP needs to change accordingly. It'll complicate the implementation of the RMP. Figure 2 shows the current RMP system supporting multiple hypervisor's APIs. Chu, et al. Expires January 12, 2012 [Page 9] Internet-Draft Virtual Resource Management in Cloud July 2011 +---------------+ |Resource Client| +---------------+ | V +----------------+ +-----------------+ |Resource Manager|<----|System Management| +----------------+ +-----------------+ | | | | | +-----------------+ | | | +------------------+ | +-------+ | +---------+ | | | | | | API1 API2 API3 API4 API5 | | | | | +------+------------+----------+------------+-----------+------+ | | | Resource | Provider | | | | V V V V V | | +---------+ +---------+ +---------+ +----------+ +---------+ | | | HV1 | | HV2 | | HV3 | | HV4 | | HV5 | | | | (XEN) | | (KVM) | |(Hyper-V)| |(ESX/ESXi)| | (etc.) | | | +---------+ +---------+ +---------+ +----------+ +---------+ | | | +--------------------------------------------------------------+ Figure 2: Current RMP system with multiple hypervisor's APIs 3.3. Resource Management Standard Gaps System Virtualization, Partitioning and Clustering (SVPC) work group, chartered by DMTF, has released a series of standard profiles for managing system virtualization environments, including management of virtual computer systems and their associated virtual resources and host computer system virtualization including resource pools and resources allocation from those pools. These profiles, all based on DMTF's Common Information Model (CIM), are now publicly available and are ready for implementation to reduce virtual system management complexity and cost. Objectives of the SVPC include: o Create profiles for the management of: * computer systems which are clustered for high availability or high-performance computing; Chu, et al. Expires January 12, 2012 [Page 10] Internet-Draft Virtual Resource Management in Cloud July 2011 * virtualization of computer systems and the associated resources; * partitioning of computer systems and the associated resources; * image formats for the provisioning and management of single and groups of virtual systems. o optionally providing an application or service. o Create specifications for virtual machine image formats. o Create specifications for interoperability of virtualization management. o White papers in support of the above objectives. o Work with DMTF Interoperability committee, Virtualization Management Forum and System Management Forum to support an interoperability initiative for virtualization management. The work doing in SVPC WG and the problems identified from cloud and DC environments are all focus on virtual system management, but each concerns different aspects. For SVPC WG, it concerns the virtualization layer and the full lifecycle of the hosted virtual computer systems, that is, standardize the internal realization of hypervisor platforms. The work in cloud and DC environemnts concerns unified resource management platform to aggregate different types of resources provided by different types of hypervisors and to provide a set of virutal resources to satisfy the service deployment requirements and the customers resource requst/interaction requirements. The Profiles provided by SVPC WG can't be directly used for unified resource management platform in Cloud and DC enviroments to satisfy applications/services deployment requirements. o The resource pool provided by SVPC aggregates only the homogeneous type of resources. In Cloud and DC environment, resource pool means the aggregation of all types of virtual resources in the RMP domain. o The interfaces provided by SVPC use XML-based CIM over HTTP. In Cloud and DC environment, it may be more effective to use RESTful- based APIs. o The profiles provided by SVPC specify service for the manipulation of virtual computer systems and their resources, but they do not Chu, et al. Expires January 12, 2012 [Page 11] Internet-Draft Virtual Resource Management in Cloud July 2011 provide mechanism on how to provide a set of resources to constitute a virtual DC or virtual LAN environment. Some work that are being done in SVPC WG can be use for the unified resource management in Cloud and DC enviroment. o The modeling of virtual computer system, resource virtualization, resource allocation, and virtual system configuration helps to simplify the system management and to make the relationship between the host computer system and the virtual computer system clearly. o The methods and properities defined for virtual systems, virtual devices, resource pools, and allocation capabilities help RMP to manage the resources in the hypervisor platform. o The setting data, association, and state transfer help to configure the relationship between virutal resources and manage the lifecycle of the virtual system. 3.4. Interface Requirements To solve the resource management problems faced by Cloud and DC environments and to simplify operations on the virtual resource management, the following three requirements must be met. o The API strives to be hypervisor-agnostic. It can be used by RMP to form a unified resource pool. o The API needs to be simple and lightweight. It can be implemented with the popular technologies, such as HTTP, URI, XML, JSON, etc. o Resource pools or its child resource pools with the setting data can be provided to satisfy the services/applications deployment requirements, such as constituting Virtual DCs, virtual LANs or virual Clusters. 3.5. VRM system with a unified API Following is a RMP system architecture that satisfies the described requirements above. The unified VRM API can effectively reduce the complexity of the resource management. Figure 3 shows a RMP system supporting a unified interface to different types of hypervisors. Chu, et al. Expires January 12, 2012 [Page 12] Internet-Draft Virtual Resource Management in Cloud July 2011 +---------------+ |Resource Client| +---------------+ | VRM API | V +----------------+ +-----------------+ |Resource Manager|<-----|System Management| +----------------+ +-----------------+ | VRM API | +-------------+-------------+-------------+-------------+ | | | | | +------+-------------+-------------+-------------+-------------+------+ | | | Resource | Provider | | | | V V V V V | | +-------+ +-------+ +-------+ +-------+ +-------+ | | |Adaptor| |Adaptor| |Adaptor| |Adaptor| |Adaptor| | |+---API1----+ +---API2----+ +---API3----+ +---API4----+ +---API5----+| || HV1 | | HV2 | | HV3 | | HV4 | | HV5 || || (XEN) | | (KVM) | | (Hyper-V) | |(ESX/ESXi) | | (etc.) || |+-----------+ +-----------+ +-----------+ +-----------+ +-----------+| +---------------------------------------------------------------------+ Figure 3: A unified VRM API to multiple hypervisors in RMP With the unified VRM API, RMP can manage all kinds of resources provided by multiple hypervisors easily. What the hypervisors need to do is to convert the VRM API into the hypervisor's own API through the Adaptor. Chu, et al. Expires January 12, 2012 [Page 13] Internet-Draft Virtual Resource Management in Cloud July 2011 4. REST used in Cloud Resource Management 4.1. REST Design Best for Cloud Resource Management REST stands for Representational State Transfer, which was introduced in 2000 in the doctoral dissertation of Roy Fielding (one of the principal authors of the HTTP specification). It is a software architecture style for distributed systems, and typically implemented in a servlet (hosting the REST service) that responds to HTTP requests. The REST service will accept HTTP requests and parse them in order to determine what action to perform. Depending on the request sent, different data is sent to and returned from the servlet. The REST API documents the patterns that are available for REST calls, and the actions that are available to be performed by the REST service. The API also documents the data that must be sent with a REST request, and the data that is returned in a response from the REST service. REST style principles. o Resources are addressable in REST. Every "thing" on your network should have an ID. With REST over HTTP, every object will have its own specific URI. o Resources can be organized hierarchically with their URI identifications. o A Uniform, Constrained Interface in REST. When applying REST over HTTP, the methods provided by the protocol (GET, POST, PUT, and DELETE) can be used to operate resources. o Representation oriented in REST. Interactions with services can use different representations to describe the attributes of resource. The representations may be XML, JSON, XHTML, etc. o Communicate statelessly in REST. Stateless applications are easier to scale. Compared with REST style principles, it is found that REST style design is best for virtual resource management. o In cloud environment, physical equipments are virtualized and grouped into different kinds of virtual resources, such as virtual machines, virtual storages, virtual networks. Virtual networks can be further divided into V-Routers, V-Switches, V-Firewalls, VPNs, V-Interfaces, V-Links which are abstracted from the physical Chu, et al. Expires January 12, 2012 [Page 14] Internet-Draft Virtual Resource Management in Cloud July 2011 Router/Switch/NIC equipments. All these resources can be addressed by assigning a specific URI. o Resources in cloud can be organized hierarchically, such as, partitioning cloud into many virtual DCs, partitioning a virtual DC into many RPLs, and partitioning a RPL into many child RPLs. o In virtualization environment, operations on the resources mainly focus on resource (de)registry, resource request, resource binding and resource delete, so the HTTP verbs can satisfy the operation requirements. o Attributes of resources in the resource interactions can be described with XML, JSON, XHTML, etc. o In virtualization environment, operations on resources have no change to their identifiers, so resource operations can be designed as session irrelevant. 4.2. REST in practice 4.2.1. IBM WebSphere CloudBurst API WebSphere CloudBurst Appliance is a hardware appliance that provides access to WebSphere virtual images and patterns for easily, quickly and repeatedly creating application environments that can be securely deployed and managed in a private cloud. WebSphere CloudBurst has several mechanisms administrators can use to communicate with it. o Administrative console. It provides a Web browser-based UI that can be accessed to modify WebSphere CloudBurst settings, manage users, cloud resources and patterns, and deploy and monitor virtual systems. o Command-line interface. It allows users to manage their WebSphere CloudBurst appliance settings and cloud resources in a robust command-line tool. o REST API. It is an HTTP-based service that accepts HTTP requests and performs WebSphere CloudBurst actions depending on the type of request that is sent. The REST API provides a mechanism for users to work with CloudBurst without having the need for a Java runtime environment. The IBM WebSphere CloudBurst administrative console and the command line interface provide a full set of WebSphere CloudBurst Chu, et al. Expires January 12, 2012 [Page 15] Internet-Draft Virtual Resource Management in Cloud July 2011 functionality, while the REST API can only provide a subset of all of the WebSphere CloudBurst features available. The REST API is enabled by default and there are no extra configuration settings needed to enable it. There is no way to disable the REST interface. The IBM WebSphere CloudBurst REST API is available to be called by way of HTTPS on port 443. The REST API supports self-signed certificate for SSL sessions used by WebSphere CloudBurst appliance. Actions the REST API can perform to the WebSphere CloudBurst appliance include: o Certificates, o Cloud groups, o Diagnostics/Trace log files, o Patterns, o Hypervisors, o Networks, o Storage, o Virtual Machines, o Virtual Systems, o IP groups, o IP addresses, 4.2.2. Sun Cloud API Sun Cloud API is a RESTful based Open API for creating and managing cloud resources, including compute, storage, and networking components. Sun Cloud API use of REST mechanisms. o Uses basic verbs of HTTP, such as GET (Read), POST (Create), PUT (Update), DELETE (Delete). o URIs are discovered from server at run-time and they are opaque to users. Chu, et al. Expires January 12, 2012 [Page 16] Internet-Draft Virtual Resource Management in Cloud July 2011 o Allow each service provider to define their own URI space, and HTTP protocol using JSON. o Allows usage of any programming language. Sun Cloud API supports the following types of resources. o Cloud. A top-level construct which groups all the Virtual Data Centers to which an API user has access. o Virtual Data Center. An isolated container which is populated with Clusters, Private Virtual Networks, Public Addresses, Storage Volumes, Volume Snapshots. o Cluster. An administrative grouping of Virtual Machines, useful for access control, copying or cloning, geographic isolation, and scripting automation. o Virtual Machine. A server. o Private Virtual Network. A subnet, not connected to the Internet, which may be used to connect Virtual Machines within a VDC. o Public Addresses. A connection to the Internet. o Storage Volumes. A storage resource which may be accessed via WebDAV and other storage protocols. o Volume Snapshots. A snapshot of the state of a Storage Volume. 4.2.3. Oracle Cloud Resource Model API Oracle Cloud Resource Model API is based on the former Sun Cloud specification. The API follows the REST architecture style and uses HTTP methods to interact with the resources to achieve provisioning, associating, modifying, and retiring of entities. Resources in Oracle Cloud Resource Model. o Cloud. o Service Template. o VDC. o Zone. Chu, et al. Expires January 12, 2012 [Page 17] Internet-Draft Virtual Resource Management in Cloud July 2011 o VM. o Volume. o VNet. o NetworkInterface. o Archive. o Snapshot. o AssemblyInstance. o ScalabilityGroup. 4.2.4. Rackspace Cloud Server API Rackspace Cloud Servers is a compute service that provides server capacity in the cloud. Cloud Servers come in different flavors (configurations) of memory, disk space, and CPU, and can be provisioned in minutes. Rackspace is also a founder and member of the OpenStack. With the code contributions from Rackspace and the NASA Nebula cloud platform, OpenStack is now becoming a collaborative software project among several big players in the cloud computing space, creating freely available code, badly-needed standards, and common ground for the benefit of both cloud providers and cloud customers. Operations provided by Cloud Server API include. o Servers(Virtual Machines), o Server Addresses, o Server Actions, o Flavor, o Image, o Backup schedules, o Shared IP Groups, Chu, et al. Expires January 12, 2012 [Page 18] Internet-Draft Virtual Resource Management in Cloud July 2011 4.2.5. VMware API 4.2.5.1. VMware vSphere/Infrastructure API The VMware vSphere/Infrastructure APIs provide a way of interfacing with the Virtual Infrastructure. They are exposed as language- neutral web services, hosted on vCenter Server and ESX Server, and are WS-I Basic Profile 1.0 compliant. The APIs provides all the operations necessary, including life-cycle operations, to monitor and manage virtual infrastructure components like compute resources, virtual machines, networks, storage, and the like. The vSphere Web Services SDK facilitates the development of the client applications that target the VMware vSphere API. It allows building SOAP-based applications to control ESX Servers / vCenter Servers and virtual machines running on them. The SDK comprises of WSDL files, sample code in Java and C#, various libraries, and all necessary components that are required to work with the vSphere APIs. Resource types in vSphere APIs include: o Virtual Data Center, o Cluster, o Template, o Virtual Machine, o Resource Pool, o Datastore, o Network, 4.2.5.2. VMware vCloud API The VMware vCloud API provides support for developers who are building interactive clients of VMware Cloud Director using a RESTful application development style. vCloud API clients and servers communicate over HTTP, exchanging representations of vCloud objects. These representations take the form of XML elements. A vCloud API client can use HTTP GET requests to browse containers such as organizations, catalogs, and vDCs. Responses to these requests include metadata about the container itself and references to the objects it contains. These references are provided in Link elements, which have href attributes whose values the client can use Chu, et al. Expires January 12, 2012 [Page 19] Internet-Draft Virtual Resource Management in Cloud July 2011 in requests to get more information about the objects themselves. This hierarchical structure of containers lends itself to graphical representation as a folder hierarchy or tree view of vCloud objects. Resources the VMware vCloud API supports include: o API Versions. o Log in. o Log out. o Organizations. o Network. o Catalog. o vDC. o Media Image. o vAppTemplate. 4.2.6. OGF/OCCI The Open Cloud Computing Interface (OCCI) is a RESTful-based network Protocol and API for managing cloud computing infrastructure currently being created by the Open Grid Forum. OCCI allows for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It has since evolved into an extensible API with a strong focus on interoperability while still offering a high degree of extensibility. The current release of the OCCI is suitable to serve many other models in addition to IaaS, including e.g. PaaS and SaaS. OCCI are described from three aspects. o OCCI Core Mode. * Core Mode defines a representation of resource types which is an abstraction of real-world resources, including the means to identify, classify, associate and extend those resources. * Any resource exposed through OCCI is a Resource or a sub-type thereof. The Resource type contains a number of common attributes that Resource sub-types inherit. The Resource type is complemented by the Link type which associates one Resource Chu, et al. Expires January 12, 2012 [Page 20] Internet-Draft Virtual Resource Management in Cloud July 2011 instance with another. The Link type contains a number of common attributes that Link sub-types inherit. * OCCI Core Model types include Category, Kind, Mixin, Action, Entity, Resource and Link. o OCCI Rendering. * OCCI Rendering types include HTTP Header, XHTML5, etc. * OCCI Rendering is a lightweight yet all-encompassing means to describe infrastructure. * It provides the capability to send a native (e.g. OVF, VMX) representation for clients that can digest such a native rendering. o OCCI Infrastructure Model * OCCI Infrastructure Model describes a particular OCCI Infrastructure extension for the IaaS domain. * The main infrastructure types defined within OCCI Infrastructure are: + Compute. Information processing resources. + Network. Interconnection resource and represents a L2 networking resource. + Storage. Information recording resources. * Link sub-types for the Resource types are the following: + NetworkInterface connects a Compute instance to a Network instance. + StorageLink connects a Compute instance to a Storage instance. 4.2.7. SNIA/CDMI The CDMI API provides the means to access cloud storage and to manage the data stored. Metadata is a convenient mechanism in managing large amounts of data with differing requirements through expressing those requirements in such a way that underlying data services differentiate their Chu, et al. Expires January 12, 2012 [Page 21] Internet-Draft Virtual Resource Management in Cloud July 2011 treatment of the data to meet those requirements. Resource types which are accessed through RESTful interface include: o Container. o Accounting. o DataObject. * Files. * Block Devices. * Object Stores. * Database Tables. o Capability. Chu, et al. Expires January 12, 2012 [Page 22] Internet-Draft Virtual Resource Management in Cloud July 2011 5. REST-based VRM API This section specifies the representations of the resources the VRM API operates on. The representations are made up of attributes, each with a name and value, encoded using JSON. 5.1. Hierarchical Cloud Resources The following figure illustrates the view of the hierarchical resource models defined in this document. +-----------+ +-----------+ | Cloud1 |<----->| Cloud2 | +-----------+ +-----------+ | | +---------+ | | | V V +----------+ +-----------+ | Template | | VDC | +----------+ +-----------+ | | | | | +----------------------+ | | | +---------------------------+ | +-----------+ | +-----------+ | | | | | | | | | V | | | | +-----------+ | | | | | Res. Pool | | | | | +-----------+ | | | | | | | | | | | +----------+-------------+--------+ | | | +------------+ | | | | +-----------+----------+ | | | | | | | | | +----------+ | | | | | | | | | | | | V V V V V V V V V +--------+ +--------+ +----------+ +-----------+ +--------+ | VM |--->| Volume | | vNetwork | | Res. Pool | | Host | +--------+ +--------+ +----------+ +-----------+ +--------+ | | | | | +-----------+-----------+ | | | | | V V V V +---------+ +----------+ +--------------+ | Archive | | Snapshot | | vNetElements | +---------+ +----------+ +--------------+ Figure 4: Hierarchical Resources in cloud environment Chu, et al. Expires January 12, 2012 [Page 23] Internet-Draft Virtual Resource Management in Cloud July 2011 The representations of resources typically nest. For example, the representation of Cloud will include Templates and VDCs. VDC will include representations of VMs, Volumes, Networks, Resource Pools and Hosts. Resource Pool will further include its child resource pools. All these resource are organized hierarchically just as shown in the figure above. 5.2. Transport Protocol The REST based VRM API is based on the Hypertext Transfer Protocol, version 1.1 (RFC 2616). Each request will be authenticated using HTTP Basic Authentication (RFC 2617) unless otherwise noted. Requests sent from clients on the public Internet (and not on a secure channel such as a VPN) MUST use the https protocol on port 443. TLS 1.1 (RFC 4346) shall be implemented by the provider and TLS 1.2 (RFC 5246) is strongly encouraged. 5.3. URI Space Resources in the cloud system are identified by URI Spaces which is controlled by the server. VDCs, VMs, Templates, Volumes, Networks and RPLs are all identified by URIs. To begin operations, a client must know the URI for a Space. Then, Server will yield a representation of the canonical URI space containing links to the VDCs, VMs, Templates, Volumes, Networks and RPLs of that space in response message body. 5.4. HTTP Header When using the REST based VRM API, it is necessary to be aware of certain HTTP headers that are required in every request. A listing of those headers and a brief explanation of their uses are provided in Table 1. 5.4.1. Request Headers In requests made to implement Cloud VRM API, several specific HTTP headers are used as described in the following table: Table 1. Required HTTP request headers Chu, et al. Expires January 12, 2012 [Page 24] Internet-Draft Virtual Resource Management in Cloud July 2011 +------------------------+------------------------------------------+ | Header Name | Description | +------------------------+------------------------------------------+ | Accept | Indicates to the server what media | | | type(s) this client is prepared to | | | accept. Clients should set | | | application/json as the Accept value for | | | all requests. Server generally sends | | | back JSON (Java Script Object Notation) | | | encoded data in all responses. | | | | | Authorization | Identifies the user making this request. | | | VRM API supports basic authentication. | | | "Basic" plus username and password when | | | sending requests to the Server. | | | | | Content-Length | Describes the size of the request | | | message body. | | | | | Content-Type | Media type describing the representation | | | and syntax of the request message body. | | | | | Host | Identifies the host receiving the | | | message. | | | | | X-CloudOPS-API-Version | Declares the specification version of | | | the CloudOPS REST VRM API being used. | | | As of the date of publication, the only | | | valid value is 1.0. | +------------------------+------------------------------------------+ 5.4.2. Response Headers In responses returned from server, several specific HTTP headers are used as described in the following table: Table 2. Required HTTP response headers Chu, et al. Expires January 12, 2012 [Page 25] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+-------------------------------------------------+ | Header Name | Description | +-----------------+-------------------------------------------------+ | Accept-Language | This parameter indicates the language or locale | | | to be used when generating responses. | | | | | Content-Length | Describes the size of the response message | | | body. | | | | | Content-Type | Describes the representation and syntax of the | | | response message body. | | | | | Location | Returns a new URI that can be used to request a | | | representation of the newly created resource. | | | | | Cache-Control | Describes how the representation of the | | | resource should be cached, and its freshness. | +-----------------+-------------------------------------------------+ 5.4.3. HTTP Status Codes VRM API uses the HTTP protocol for sending and retrieving data. Client utilizing the REST API makes an HTTP request to the Server and process the HTTP response accordingly. The status codes in HTTP response (RFC2616) gives the client some indication as to the success of the HTTP request, or the information on how the client should handle the included response data in failure case. Following table lists some common used HTTP response codes with their conditions. Chu, et al. Expires January 12, 2012 [Page 26] Internet-Draft Virtual Resource Management in Cloud July 2011 +--------------+----------------------------------------------------+ | Status | Description | +--------------+----------------------------------------------------+ | 100 Continue | The client SHOULD continue with its request. This | | | interim response is used to inform the client that | | | the request has been received and has not yet been | | | rejected by the platform. The client SHOULD | | | continue by sending the remainder of the request | | | or, if the request has already been completed, | | | ignore this response. | | | | | 200 OK | The request was successfully completed. If this | | | request created a new resource that is addressable | | | with a URI, and a response body is returned | | | containing a representation of the new resource, a | | | 200 status and a Location header containing the | | | canonical URI for the newly created resource. | | | | | 201 Created | A request that created a new resource was | | | completed, and no response body containing a | | | representation of the new resource is being | | | returned. A Location header containing the | | | canonical URI for the newly created resource will | | | be returned. | | | | | 202 Accepted | The request has been accepted for processing, but | | | the processing has not been completed. Per the | | | HTTP/1.1 specification, the returned entity (if | | | any) SHOULD include an indication of the request's | | | current status. A Location header containing the | | | canonical URI for the not-yet completed resource | | | would be returned along with the Status attribute | | | indicating its progress. | | | | | 204 No | The request has been processed and no content was | | Content | returned. | | | | | 304 Not | The resource was not modified. Returned for | | Modified | conditional GET when resource is not modified. | | | | | 400 Bad | The request could not be processed because it | | Request | contains missing or invalid information (such as | | | validation error on an input field, a missing | | | required value, and so on). | | | | | 401 | The authentication credentials included with this | | Unauthorized | request are missing or invalid | | | | Chu, et al. Expires January 12, 2012 [Page 27] Internet-Draft Virtual Resource Management in Cloud July 2011 | 403 | The server recognized your credentials, but you do | | Forbidden | not possess authorization to perform this request. | | | | | 404 Not | The request specified a URI of a resource that | | Found | does not exist. | | | | | 405 Method | The HTTP verb specified in the request (DELETE, | | Not Allowed | GET, HEAD, POST, PUT) is not supported for this | | | request URI. | | | | | 406 Not | The resource identified by this request is not | | Acceptable | capable of generating a representation | | | corresponding to one of the media types in the | | | Accept header of the request. | | | | | 409 Conflict | A creation or update request could not be | | | completed, because it would cause a conflict in | | | the current state of the resources supported by | | | the platform (for example, an attempt to create a | | | new resource with a unique identifier already | | | assigned to some existing resource or an attempt | | | to modify a resource attribute which is not yet | | | completed). | | | | | 410 Gone | The requested resource is no longer available at | | | the server and no forwarding address is known. | | | Clients with link editing capabilities SHOULD | | | delete references to the Request-URI after user | | | approval. If the server does not know, or has no | | | facility to determine, whether or not the | | | condition is permanent, the status code 404 (Not | | | Found) SHOULD be used instead. | | | | | 412 | The precondition given in one or more of the | | Precondition | request-header fields evaluated to false when it | | Failed | was tested on the server. This response code | | | allows the client to place preconditions on the | | | current resource meta-information (header field | | | data) and thus prevent the requested method from | | | being applied to a resource other than the one | | | intended. | | | | | 500 Internal | The server encountered an unexpected condition | | Server Error | which prevented it from fulfilling the request. | | | | | 501 Not | The server does not (currently) support the | | Implemented | functionality required to fulfill the request. | | | | Chu, et al. Expires January 12, 2012 [Page 28] Internet-Draft Virtual Resource Management in Cloud July 2011 | 503 Service | The server is currently unable to handle the | | Unavailable | request due to temporary overloading or | | | maintenance of the server. | +--------------+----------------------------------------------------+ 5.4.4. Media Type Resource representations of request and response bodies are normally encoded in JSON, as specified in RFC4627 Each type of resource has its own media-type, which matches the pattern "application/vnd.ietf.cloud.Xxxxx+json", where "Xxxxx" represents the portion of the identifier unique to a particular representation format for each resource. The identifier MUST be globally unique in the space of vnd.com.ietf.cloud, and the meida type should be registered in accordance to RFC4288. 5.5. Resource Representations This section specifies the representations of the resources this API operates on. The representations are made up of attributes, each with a name and value, encoded using a JSON dictionary. Each type of cloud resource has its own Internet Media Type. The media type SHALL conform to the pattern "application/ vnd.ietf.cloud.Xxxxxx+json". 5.5.1. Cloud Cloud represents all accessible resources and deployed entities in cloud environment. HTTP Methods: GET Media Type: application/vnd.ietf.cloud.Cloud+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 29] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of the cloud. | | | | | | id | Integer | Values assigned to the cloud by the | | | | vendor. | | | | | | templates | Set | The list of templates that are | | | | accessible to the user, such as | | | | VMTemplate, VolumeTemplate, | | | | VNetTemplate and RPLTemplate. | | | | | | vdcs | String | The list of Virtual data centers | | | | accessible to this user. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the Cloud was created. | | | | | | resource_status | Enum | Current state of the resource (e.g. | | | | INITIATED, CREATING, CREATED, | | | | DESTROYING, DESTROYED, READY). Only | | | | cloud with "READY" state can be used | | | | by user to deploy resource. | +-----------------+---------+---------------------------------------+ Editor note: Need we consider the location for cloud deployment? 5.5.2. Template A Template represents the definition of the deployable resource or a group of resources (i.e. resource pool). Users can create cloud resources by specifying the Template URI as a field in a deployment request. The cloud SHALL instantiate the resources, their configurations and connection relations as specified in the definition of the Template. Template is a kind of resource which include subclass resource, such as VMTemplate, VolumeTeplate, vNetTemplate and RPLTemplate. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.Template+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 30] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+----------+--------------------------------------+ | Attribute | Type | Description | +-----------------+----------+--------------------------------------+ | uri | URI | The accessible address of the | | | | template to this user. | | | | | | id | Integer | Values assigned to the template by | | | | the vendor. | | | | | | type | String | The enumerated String that describes | | | | the media type of the resource | | | | template that the service provide | | | | can support. | | | | | | conf_info | String | Configuration information of the | | | | template that contains all the | | | | metadata necessary for the cloud to | | | | deploy the service. The conf_info | | | | can be represented in some format, | | | | such as XML. | | | | | | snapshot | Snapshot | The snapshot of the resource of | | | | which this Template is based on. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the Template was created. | | | | | | resource_status | Enum | Only a template with "READY" state | | | | can be used by user to deploy | | | | resource. | +-----------------+----------+--------------------------------------+ Following specifies subclass types of template. o VMTemplate: a single OS-stack system on a virtualization platform. When deployed, a Server resource would be realized. o VolumeTemplate: the storage relationships and rules that specify the storage behaviors. It can be based on the CDMI metadata to specify the characteristics of a volume. When deployed, a Volume resource would be realized. o NetworkTemplate: the routing relationships and rules that specify the network behaviors. When deployed, a VNet resource would be realized. o RPLTemplate: a system topology that include multiple entities and their interconnections with deployment constraints. When Chu, et al. Expires January 12, 2012 [Page 31] Internet-Draft Virtual Resource Management in Cloud July 2011 deployed, a resource pool resource would be realized. 5.5.2.1. VMTemplate VMTemplate is a preconfigured deployable entity that realizes a VM resource. Media Type: application/vnd.ietf.cloud.VMTemplate+json Main attributes: +-----------------+------------+------------------------------------+ | Attribute | Type | Description | +-----------------+------------+------------------------------------+ | uri | URI | The accessible address of the | | | | virtual machine to this user. | | | | | | id | Integer | Values assigned to the VMTemplate | | | | by the vendor. | | | | | | os | String | Operating System running on the | | | | VM. | | | | | | cpu | [Number, | Count of CPU cores and CPU core | | | Number] | speed in MHz of the VM when | | | | provisioned. | | | | | | memory | Integer | Main memory size in MB of the VM | | | | when provisioned. | | | | | | disks | {String, | List of local disks and their | | | Integer}[] | sizes in GB of the VM when | | | | provisioned. | | | | | | conf_para | String | The list of system defined | | | | configuration parameters for this | | | | VM Template | | | | | | snapshot | Snapshot | The snapshot of the resource of | | | | which this VM Template is based | | | | on. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the VMTemplate was created. | | | | | Chu, et al. Expires January 12, 2012 [Page 32] Internet-Draft Virtual Resource Management in Cloud July 2011 | resource_status | Enum | Only a VM template with "READY" | | | | state can be used by user to | | | | deploy resource. | +-----------------+------------+------------------------------------+ 5.5.2.2. VolumeTemplate VolumeTemplate is a preconfigured deployable entity that realizes a virtual Volume resource. Media Type: application/vnd.ietf.cloud.VolumeTemplate+json Main attributes: +-----------------+----------+--------------------------------------+ | Attribute | Type | Description | +-----------------+----------+--------------------------------------+ | uri | URI | The accessible address of the volume | | | | template to this user. | | | | | | id | Integer | Values assigned to the | | | | VolumeTemplate by the vendor. | | | | | | conf_para | String | The list of system defined | | | | configuration parameters for this VM | | | | Template | | | | | | snapshot | Snapshot | The snapshot of the volume of which | | | | this VolumeTemplate is based on. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the VolumeTemplate was created. | | | | | | resource_status | Enum | Only a volume template with "READY" | | | | state can be used by user to deploy | | | | resource. | +-----------------+----------+--------------------------------------+ 5.5.2.3. NetworkTemplate NetworkTemplate is a preconfigured deployable entity that realizes a virtual Network resource. Media Type: application/vnd.ietf.cloud.VNetTemplate+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 33] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+----------+--------------------------------------+ | Attribute | Type | Description | +-----------------+----------+--------------------------------------+ | uri | URI | The accessible address of the | | | | virtual network resource template to | | | | this user. | | | | | | id | Integer | Values assigned to the | | | | NetworkTemplate by the vendor. | | | | | | conf_para | String | The list of system defined | | | | configuration parameters for this | | | | Network Template | | | | | | snapshot | Snapshot | The snapshot of the network of which | | | | this NetworkTemplate is based on. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the NetworkTemplate was | | | | created. | | | | | | resource_status | Enum | Only a network template with "READY" | | | | state can be used by user to deploy | | | | resource. | +-----------------+----------+--------------------------------------+ 5.5.2.4. RPLTemplate RPLTemplate is a deployable entity to realize resource pool that may contain multiple resources with their interconnection relationship. Media Type: application/vnd.ietf.cloud.RPLTemplate+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 34] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+----------+--------------------------------------+ | Attribute | Type | Description | +-----------------+----------+--------------------------------------+ | uri | URI | The accessible address of the | | | | resource pool template to this user. | | | | | | id | Integer | Values assigned to the RPLTemplate | | | | by the vendor. | | | | | | conf_para | String | The list of system defined | | | | configuration parameters for this | | | | RPLTemplate | | | | | | snapshot | Snapshot | The snapshot of the resource pool of | | | | which this RPLTemplate is based on. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the RPLTemplate was created. | | | | | | resource_status | Enum | Only a resource pool template with | | | | "READY" state can be used by user to | | | | deploy resource. | +-----------------+----------+--------------------------------------+ 5.5.3. VDC A VDC represents the grouping of resources that make up a data center. Resources among VDCs are isolated, cloud resource providers can enforce underlying resource limitations on a VDC. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.VDC+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 35] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of VDC to this | | | | user. | | | | | | id | Integer | Values assigned to the vdc by the | | | | vendor. | | | | | | rpls | Set | A list of resource pools that are | | | | included in the VDC. | | | | | | vms | Set | A list of virtual machines that are | | | | included in the VDC. | | | | | | volumes | Set | A list of volumes that are included | | | | in the VDC. | | | | | | vnets | Set | A list of virtual network resources | | | | that are included in the VDC. | | | | | | hosts | Set | A list of unvirtualized physical | | | | servers that are included in the VDC. | | | | | | conf_para | Set | Configuration parameters for this | | | | VDC. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the VDC was created. | | | | | | resource_status | Enum | Only a VDC with "READY" state can be | | | | used by user to deploy service. | +-----------------+---------+---------------------------------------+ 5.5.4. Resource Pool Resource pool is a logical grouping of resources with their interconnection relationships. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.RPL+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 36] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of resource | | | | pool to this user. | | | | | | id | Integer | Values assigned to the resource pool | | | | by the vendor. | | | | | | rpls | Set | A list of child resource pools that | | | | are included in the resource pool. | | | | | | vms | Set | A list of virtual machines that are | | | | included in the resource pool. | | | | | | volumes | Set | A list of volumes that are included | | | | in the resource pool. | | | | | | Vnets | Set | A list of virtual network resources | | | | that are included in the resource | | | | pool. | | | | | | hosts | Set | A list of unvirtualized physical | | | | servers that are included in the | | | | resource pool. | | | | | | nodes | Set | A list of virtualized physical hosts | | | | that are included in the resource | | | | pool. | | | | | | max_capacity | Set | The maximum number of resources this | | | | resource pool can hold, such as | | | | nodes, VMs, Volumes, and vNetworks, | | | | etc. If not provided, the client | | | | should assume it is unlimited. | | | | | | min_capacity | Set | The minimal number of resources this | | | | resource pool should hold to be | | | | considered a functional scalability | | | | group. If not specified, the client | | | | should assume it is 1. | | | | | | superior | URIs{} | List of the superior entities URIs of | | | | this resource pool contained in, such | | | | as VDC URI. | | | | | Chu, et al. Expires January 12, 2012 [Page 37] Internet-Draft Virtual Resource Management in Cloud July 2011 | parent | URI | Parent (immediate superior) URI of | | | | this resource pool contained in, such | | | | as VDC URI or RPL URI. | | | | | | boot_order | Set | Boot order of VMs when perform | | | | start/stop operations on the resource | | | | pool. When a resource pool is | | | | started, VMs with the same boot_order | | | | value will be started in an undefined | | | | sequence, but the service will ensure | | | | that all VMs with a particular | | | | boot_order value will have been | | | | started before starting VMs with a | | | | higher boot_order value. The | | | | sequence is reversed for a stop | | | | resource pool operation. VMs with no | | | | boot_order value will be assumed to | | | | have a boot_order of the maximum | | | | integer value, so they will be | | | | started last and stopped first. | | | | | | conf_para | Set | Configuration parameters for this | | | | resource pool. | | | | | | template | URI | URI of the RPLTemplate of which this | | | | resource pool is based on. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the VDC was created. | | | | | | resource_status | Enum | Only a Resource Pool with "READY" | | | | state can be used by user to deploy | | | | service. | +-----------------+---------+---------------------------------------+ 5.5.5. Virtual Machine VM is a computing container providing a complete OS stack that services/applications can be deployed on. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.VM+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 38] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+-------------------+-----------------------------+ | Attribute | Type | Description | +-----------------+-------------------+-----------------------------+ | uri | URI | The accessible address of | | | | virtual machine to this | | | | user. | | | | | | id | Integer | Values assigned to the | | | | virtual machine by the | | | | vendor. | | | | | | os | String | Operating System running on | | | | the VM. | | | | | | cpu | [Number, Number] | Count of CPU cores and CPU | | | | core speed in MHz of the VM | | | | when provisioned. | | | | | | memory | Integer | Main memory size in MB of | | | | the VM when provisioned. | | | | | | disks | {String,Number}[] | The name and size in GB of | | | | local disks. | | | | | | volumes | Set | List of Volumes that are | | | | attached to the VM. | | | | | | vnets | Set | List of virtual network | | | | resources attached to the | | | | VM. | | | | | | hostname | String | Name of the virtualized | | | | physical host that this VM | | | | is contained in. | | | | | | superior | URIs{} | List of the superior | | | | entities URIs of this VM | | | | contained in, such as VDC | | | | URI, RPL URI. | | | | | | parent | URI | Parent (immediate superior) | | | | URI of this resource pool | | | | contained in, such as VDC | | | | URI or RPL URI. | | | | | | template | URI | The URI of the template on | | | | which this VM is based on. | | | | | Chu, et al. Expires January 12, 2012 [Page 39] Internet-Draft Virtual Resource Management in Cloud July 2011 | archives | Set | List of archives that have | | | | been taken of this VM. | | | | | | clone | URI | If the VM was instantiated | | | | from an archive, this field | | | | would indicate the uri of | | | | the original snapshot. | | | | | | restore | URI | If the VM was restored from | | | | an existing archive in its | | | | archive list, this field | | | | will contain the uri of the | | | | archive entity. | | | | | | service_status | String | Current status of the | | | | Service running on the VM. | | | | Service provider can | | | | implement at least the | | | | following valid values, | | | | such as STOPPED, STOPPING, | | | | STARTING, STARTED, | | | | SUSPENDED, SUSPENDING, | | | | RESUMING, RESTARTING. | | | | | | conf_para | Set | Configuration parameters | | | | for this VM. | | | | | | snapshots | Set | A list of snapshots that | | | | have been taken of this VM. | | | | | | created_time | Time | Date and time, in ISO 8601 | | | | format, when the RPL was | | | | created. | | | | | | resource_status | Enum | Only a Resource Pool with | | | | "READY" state can be used | | | | by user to deploy service. | +-----------------+-------------------+-----------------------------+ 5.5.6. Volume Volume is the storage medium that is associated with a logical disk spanning on one or more hard disk drives. It can be used for inter- operably configure storage by the computing cloud. CDMI Storage standard is RESTful style based, so when Volume management is coupled with the CDMI Cloud Storage standard, this API can be used to inter-operably configure storage for use by the Chu, et al. Expires January 12, 2012 [Page 40] Internet-Draft Virtual Resource Management in Cloud July 2011 computing cloud. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.Volume+json Main attributes: +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of volume to | | | | this user. | | | | | | id | Integer | Values assigned to the volume by the | | | | vendor. | | | | | | size | Integer | The size of the volume in GBytes. | | | | | | archive | Set | A list of archive that have been | | | | taken on this volume. | | | | | | clone | URI | If the Volume was instantiated from | | | | an archive, this field would indicate | | | | the uri of the original snapshot. | | | | | | restore | URI | If the Volume was restored from a | | | | snapshot, this field will contain the | | | | uri of the snapshot. | | | | | | superior | URIs{} | List of the superior entities URIs of | | | | this Volume contained in, such as VDC | | | | URI, RPL URI. | | | | | | parent | URI | Parent (immediate superior) URI of | | | | this Volume contained in, such as VDC | | | | URI or RPL URI. | | | | | | template | Set | The URI of the template on which this | | | | Volume is based on. | | | | | | conf_para | Set | Configuration parameters for this | | | | Volume. | | | | | | snapshots | Set | A list of snapshots that have been | | | | taken of this Volume. | | | | | Chu, et al. Expires January 12, 2012 [Page 41] Internet-Draft Virtual Resource Management in Cloud July 2011 | created_time | Time | Date and time, in ISO 8601 format, | | | | when the Volume was created. | | | | | | resource_status | Enum | Only a Volume with "READY" state can | | | | be used by user to deploy service. | +-----------------+---------+---------------------------------------+ 5.5.7. Virtual Network Virtual Network is a service that is capable of providing virtualized network interface, virtualized router, virualized switch, virtualized firewall, VPN, etc. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.VNet+json Main attributes: +-------------------+---------+-------------------------------------+ | Attribute | Type | Description | +-------------------+---------+-------------------------------------+ | uri | URI | The accessible address of virtual | | | | network to this user. | | | | | | id | Integer | Values assigned to the virtual | | | | network by the vendor. | | | | | | network_resources | Set | List of virtualized network | | | | resources that are parts of vNet. | | | | | | superior | URIs{} | List of the superior entities URIs | | | | of this vNet contained in, such as | | | | VDC URI, RPL URI. | | | | | | parent | URI | Parent (immediate superior) URI of | | | | this vNet contained in, such as VDC | | | | URI or RPL URI. | | | | | | template | Set | The URI of the template on which | | | | this vNet is based on. | | | | | | conf_para | Set | Configuration parameters for this | | | | vNet, such as default network mask | | | | for interfaces connected to this | | | | VNet. | | | | | Chu, et al. Expires January 12, 2012 [Page 42] Internet-Draft Virtual Resource Management in Cloud July 2011 | created_time | Time | Date and time, in ISO 8601 format, | | | | when the VNetwork was created. | | | | | | resource_status | Enum | Only a virtual network with "READY" | | | | state can be used by user to deploy | | | | service. | +-------------------+---------+-------------------------------------+ Following specifies subclass types of network resource. Network Interface: A network interface is the point of interconnection between a computer and a private or public network. A network interface is generally a network interface card (NIC). But in virtualized environment, it represents a virtual interface of a virtual network device. An example of such an interface is a virtual NIC of a virtual machine on a server virtualization platform. Network Link: A network link is a connection between the two connected network interface. It represents an generic Ethernet cable in actual network environment. But in virtualized environemt, it represents a virtual network link used to connect two virtual network interfaces. An example of such a link is a connection between a virtual machine and a virtual switch created on a server virtualization platform. Router: A router is a device or a piece of software in a computer that forwards and routes data packets across computer networks. It performs the data "traffic directing" functions on the Internet. But in virtualized environemt, it represents a virtual router used to forwards data packets across vlans. Network Switch: A network switch is a small device that joins multiple computers together within one local area network (LAN). Network switches are capable of inspecting data packets as they are received, determining the source and destination device of each packet, and forwarding them appropriately. But in virtualized environemt, a virtual network switch is a virtual version of a physical network switch. a virtual network can be configured to provide access to local or external network resources for one or more virtual machines. Network Firewall: A network firewall is a device or set of devices designed to permit or deny network transmissions based upon a set of rules Chu, et al. Expires January 12, 2012 [Page 43] Internet-Draft Virtual Resource Management in Cloud July 2011 and is frequently used to protect networks from unauthorized access while permitting legitimate communications to pass. But in virtualized environemt, it is a virtualized network firewall (VNF) service or appliance which provides the usual packet filtering and monitoring function via a physical network firewall. The VNF can be realized on a virtual machine, or on a purpose-built virtual security appliance, or on a virtual switch with additional security capabilities, or on a managed kernel process running within the host hypervisor. VPN Connection: A VPN connection is a secure network connection that is layered on top of a public network, such as the Internet, to the private network. Via VPN connections, remote computers acts as though they were on the same secure, local network. 5.5.7.1. Network Interface An instance of the network interface is identified by a network end point and consists of a complete address that can be interpreted by the underlying network infrastructure. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.NetworkInterface+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 44] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of network | | | | interface to this user. | | | | | | id | Integer | Values assigned to the network | | | | interface by the vendor. | | | | | | vnet | URI | The associated VNet this network | | | | interface belongs to. | | | | | | networklink | Set | The associated network link this | | | | network interface attachs to. | | | | | | public_address | URI | URI of the public address this | | | | network interface attached to. | | | | | | mac_address | Address | IP address of this network interface. | | | | | | ip_address | String | IP address of this network interface. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the network interface was | | | | created. | | | | | | resource_status | Enum | Only a network interface with "READY" | | | | state can be used by user to deploy | | | | service. | +-----------------+---------+---------------------------------------+ 5.5.7.2. Router TBD. 5.5.7.3. Switch TBD. 5.5.7.4. Firewall TBD. 5.5.7.5. VPN TBD. Chu, et al. Expires January 12, 2012 [Page 45] Internet-Draft Virtual Resource Management in Cloud July 2011 5.5.8. Host Host is a unvirtualized physical service that directly provides resources to the cloud. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.Host+json Main attributes: +-----------------+-------------------+-----------------------------+ | Attribute | Type | Description | +-----------------+-------------------+-----------------------------+ | uri | URI | The accessible address of | | | | host to this user. | | | | | | id | Integer | Values assigned to the host | | | | by the vendor. | | | | | | os | String | Operating System running on | | | | the Host. | | | | | | cpu | [Number, Number] | Count of CPU cores and CPU | | | | core speed in MHz of the | | | | Host when provisioned. | | | | | | memory | Integer | Main memory size in MB of | | | | the Host when provisioned. | | | | | | disks | {String,Number}[] | The name and size in GB of | | | | local disks. | | | | | | volumes | [Number, Number] | List of Volumes and their | | | | sizes in GB of the Host | | | | when provisioned. | | | | | | networks | Set | Network resources | | | | associated with this host. | | | | | | superior | URIs{} | List of the superior | | | | entities URIs of this host | | | | contained in, such as VDC | | | | URI, RPL URI. | | | | | Chu, et al. Expires January 12, 2012 [Page 46] Internet-Draft Virtual Resource Management in Cloud July 2011 | parent | URI | Parent (immediate superior) | | | | URI of this host contained | | | | in, such as VDC URI or RPL | | | | URI. | | | | | | archives | Set | List of archives that have | | | | been taken of this host. | | | | | | clone | URI | If the host was | | | | instantiated from an | | | | archive, this field would | | | | indicate the uri of the | | | | original snapshot. | | | | | | restore | URI | If the host was restored | | | | from an existing archive in | | | | its archive list, this | | | | field will contain the uri | | | | of the archive entity. | | | | | | service_status | String | Current status of the | | | | Service running on the | | | | host. Service provider can | | | | implement at least the | | | | following valid values, | | | | such as STOPPED, STOPPING, | | | | STARTING, STARTED, | | | | SUSPENDED, SUSPENDING, | | | | RESUMING, RESTARTING. | | | | | | conf_para | Set | Configuration parameters | | | | for this vNet. | | | | | | created_time | Time | Date and time, in ISO 8601 | | | | format, when the Host was | | | | created. | | | | | | resource_status | Enum | Only a Host with "READY" | | | | state can be used by user | | | | to deploy service. | +-----------------+-------------------+-----------------------------+ 5.5.9. Snapshot A snapshot represents a point-in-time representation of a Virtual Machine. HTTP Methods: GET/PUT/POST/DELETE. Chu, et al. Expires January 12, 2012 [Page 47] Internet-Draft Virtual Resource Management in Cloud July 2011 Media Type: application/vnd.ietf.cloud.Snapshot+json Main attributes: +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of snapshot to | | | | this user. | | | | | | id | Integer | Values assigned to the snapshot by | | | | the vendor. | | | | | | vmuri | URI | The uri of the VM from which this | | | | snapshot was taken. | | | | | | conf_para | Set | Configuration parameters for this | | | | snapshot. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the snapshot was created. | | | | | | resource_status | Enum | Only when a snapshot is in "READY" | | | | state, the validity of the snapshot | | | | can be assured by user. | +-----------------+---------+---------------------------------------+ 5.5.10. Archive An archive represents a point-in-time representation of a Volume. HTTP Methods: GET/PUT/POST/DELETE. Media Type: application/vnd.ietf.cloud.Archive+json Main attributes: Chu, et al. Expires January 12, 2012 [Page 48] Internet-Draft Virtual Resource Management in Cloud July 2011 +-----------------+---------+---------------------------------------+ | Attribute | Type | Description | +-----------------+---------+---------------------------------------+ | uri | URI | The accessible address of archive to | | | | this user. | | | | | | id | Integer | Values assigned to the archive by the | | | | vendor. | | | | | | volume | URI | The uri of the volume from which this | | | | archive was taken. | | | | | | conf_para | Set | Configuration parameters for this | | | | archive. | | | | | | created_time | Time | Date and time, in ISO 8601 format, | | | | when the archive was created. | | | | | | resource_status | Enum | Only when an archive is in "READY" | | | | state, the validity of the archive | | | | can be assured by user. | +-----------------+---------+---------------------------------------+ Chu, et al. Expires January 12, 2012 [Page 49] Internet-Draft Virtual Resource Management in Cloud July 2011 6. Conclusion The REST-based VRM API is a unified interface to integrate different kinds of resources provided by multiple vendor hypervisors. The API is hypervisor agnostic, which can shield the influence of different vendor hypervisors to VRM and fit well the hierarchal virtual resource management. Chu, et al. Expires January 12, 2012 [Page 50] Internet-Draft Virtual Resource Management in Cloud July 2011 7. Security Considerations The RESTful-based VRM API as defined in this document provides access to the resources of the data center network. This information could be used to aid an attack on the network. Chu, et al. Expires January 12, 2012 [Page 51] Internet-Draft Virtual Resource Management in Cloud July 2011 8. Acknowledgement --[Editor's note] Will be added in future. Chu, et al. Expires January 12, 2012 [Page 52] Internet-Draft Virtual Resource Management in Cloud July 2011 9. IANA Considerations --[Editor's note] Will be added in future. Chu, et al. Expires January 12, 2012 [Page 53] Internet-Draft Virtual Resource Management in Cloud July 2011 10. Normative references [Cloud Framework] Khasnabish, B., "cloud-reference-framework-01", December 2011. [DSP0004] DMTF, "Common Information Model (CIM) Infrastructure", May 2009. [DSP1041] DMTF, "Resource Allocation Profile", June 2009. [DSP1042] DMTF, "System Virtualization Profile", April 2010. [DSP1043] DMTF, "Allocation Capabilities Profile", June 2009. [DSP1057] DMTF, "Virtual System Profile", October 2009. [DSP1059] DMTF, "Generic Device Resource Virtualization Profile", July 2009. [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC4741] IETF, "NETCONF Configuration Protocol", December 2006. [UML] OMG, "Unified Modeling Language", September 2002. Chu, et al. Expires January 12, 2012 [Page 54] Internet-Draft Virtual Resource Management in Cloud July 2011 Authors' Addresses JunSheng Chu ZTE No.50 Ruanjian Dadao Road, Yuhuatai District Nanjing China Phone: +86-25-8801-4631 Email: chu.junsheng@zte.com.cn Bhumip Khasnabish ZTE USA, Inc. 55 Madison Avenue, Suite 160 Morristown, NJ 07960 USA Phone: +001-781-752-8003 Email: vumip1@gmail.com Yu Qing China Mobile Beijing China Phone: Email: yuqing@chinamobile.com Yu Meng ZTE No.50 Ruanjian Dadao Road, Yuhuatai District Nanjing China Phone: +86-25-8801-4631 Email: meng.yu@zte.com.cn Chu, et al. Expires January 12, 2012 [Page 55]