REST API Guide
Using the Red Hat Virtualization REST Application Programming Interface
Abstract
ovirt-engine-api-model
code, and is currently partially complete. Updated versions of this documentation will be published as new content becomes available.
Chapter 1. Introduction
The Red Hat Virtualization Manager provides a Representational State Transfer (REST) API. The API provides software developers and system administrators with control over their Red Hat Virtualization environment outside of the standard web interface. The API is useful for developers and administrators to integrate the functionality of a Red Hat Virtualization environment with custom scripts or external applications that access the API via the standard Hypertext Transfer Protocol (HTTP).
The benefits of the API are:
- Broad client support - Any programming language, framework, or system with support for HTTP protocol can use the API.
- Self descriptive - Client applications require minimal knowledge of the virtualization infrastructure, as many details are discovered at runtime.
- Resource-based model - The resource-based REST model provides a natural way to manage a virtualization platform.
This provides developers and administrators with the ability to:
- Integrate with enterprise IT systems.
- Integrate with third-party virtualization software.
- Perform automated maintenance or error-checking tasks.
- Automate repetitive tasks in a Red Hat Virtualization environment with scripts.
This documentation acts as a reference for the Red Hat Virtualization API. It aims to provide developers and administrators with instructions and examples to help harness the functionality of their Red Hat Virtualization environment through the API, either directly or using the provided SDKs.
1.1. Representational State Transfer
Representational State Transfer (REST) is a design architecture that focuses on resources for a specific service and their representations. A resource representation is a key abstraction of information that corresponds to one specific managed element on a server. A client sends a request to a server element located at a Uniform Resource Identifier (URI) and performs operations with standard HTTP methods, such as GET
, POST
, PUT
, and DELETE
. This provides a stateless communication between the client and server where each request acts independently of any other request, and contains all the information necessary to complete the request.
1.2. API Prerequisites
Prerequisites for using the Red Hat Virtualization API:
- A networked installation of Red Hat Virtualization Manager, which includes the API.
A client or programming library that initiates and receives HTTP requests from the API server. For example:
- The oVirt Python SDK.
- The oVirt Ruby SDK.
- The oVirt Java SDK.
- The cURL command line tool.
- RESTClient, a debugger for RESTful web services.
- Knowledge of Hypertext Transfer Protocol (HTTP), the protocol used for REST API interactions. The Internet Engineering Task Force provides a Request for Comments (RFC) explaining the Hypertext Transfer Protocol at http://www.ietf.org/rfc/rfc2616.txt.
- Knowledge of Extensible Markup Language (XML) or JavaScript Object Notation (JSON), which the API uses to construct resource representations. The W3C provides a full specification on XML at http://www.w3.org/TR/xml. ECMA International provide a free publication on JSON at http://www.ecma-international.org.
Chapter 2. Authentication and Security
2.1. TLS/SSL Certification
The Red Hat Virtualization API requires Hypertext Transfer Protocol Secure (HTTPS) [1] for secure interaction with client software, such as the SDK and CLI components. This involves obtaining the CA certificate used by the server, and importing it into the certificate store of your client.
2.1.1. Obtaining the CA Certificate
You can obtain the CA certificate from the Red Hat Virtualization Manager and transfer it to the client machine using one of these methods:
- Method 1
The preferred method for obtaining the CA certificate is to use the
openssl s_client
command line tool to perform a real TLS handshake with the server, and then extract the certificates that it presents. Run a command like this:$ openssl s_client \ -connect myengine.example.com:443 \ -showcerts \ < /dev/null
This command will connect to the server and display output similar to the following:
CONNECTED(00000003) depth=1 C = US, O = Example Inc., CN = myengine.example.com.23416 verify error:num=19:self signed certificate in certificate chain --- Certificate chain 0 s:/C=US/O=Example Inc./CN=myengine.example.com i:/C=US/O=Example Inc./CN=myengine.example.com.23416 -----BEGIN CERTIFICATE----- MIIEaTCCA1GgAwIBAgICEAQwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDEV4YW1wbGUgSW5jLjEjMCEGA1UEAxMaZW5naW5lNDEuZXhhbXBs SVlJe7e5FTEtHJGTAeWWM6dGbsFhip5VXM0gfqg= -----END CERTIFICATE----- 1 s:/C=US/O=Example Inc./CN=myengine.example.com.23416 i:/C=US/O=Example Inc./CN=myengine.example.com.23416 -----BEGIN CERTIFICATE----- MIIDxjCCAq6gAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDEV4YW1wbGUgSW5jLjEjMCEGA1UEAxMaZW5naW5lNDEuZXhhbXBs Pkyg1rQHR6ebGQ== -----END CERTIFICATE-----
The text between the
-----BEGIN CERTIFICATE-----
and-----END CERTIFICATE-----
marks shows the certificates presented by the server. The first one is the certificate of the server itself, and the last one is the certificate of the CA. Copy the CA certificate, including the marks, to theca.crt
file. The result should look like this:-----BEGIN CERTIFICATE----- MIIDxjCCAq6gAwIBAgICEAAwDQYJKoZIhvcNAQEFBQAwSTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDEV4YW1wbGUgSW5jLjEjMCEGA1UEAxMaZW5naW5lNDEuZXhhbXBs Pkyg1rQHR6ebGQ== -----END CERTIFICATE-----
ImportantThis is the most reliable method to obtain the CA certificate used by the server. The rest of the methods described here will work in most cases, but they will not obtain the correct CA certificate if it has been manually replaced by the administrator of the server.
- Method 2
If you cannot use the
openssl s_client
method described above, you can instead use a command line tool to download the CA certificate from the Red Hat Virtualization Manager.Examples of command line tools include
curl
andwget
, both of which are available on multiple platforms.If using
curl
:$ curl \ --output ca.crt \ 'http://myengine.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA'
If using
wget
:$ wget \ --output-document ca.crt \ 'http://myengine.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA'
- Method 3
Use a web browser to navigate to the certificate located at:
https://myengine.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA
Depending on the chosen browser, the certificate either downloads or imports into the browser’s keystore.
-
If the browser downloads the certificate: save the file as
ca.crt
. -
If the browser imports the certificate: export it from the browser’s certification options and save it as
ca.crt
.
-
If the browser downloads the certificate: save the file as
- Method 4
Log in to the Red Hat Virtualization Manager, export the certificate from the truststore, and copy it to your client machine.
-
Log in to the Red Hat Virtualization Manager machine as
root
. Export the certificate from the truststore using the Java
keytool
management utility:# keytool \ -keystore /etc/pki/ovirt-engine/.truststore \ -storepass mypass \ -exportcert \ -alias cacert \ -rfc \ -file ca.crt
This creates a certificate file called
ca.crt
.Copy the certificate to the client machine using the
scp
command:$ scp ca.crt myuser@myclient.example.com:/home/myuser/.
-
Log in to the Red Hat Virtualization Manager machine as
Each of these methods results in a certificate file named ca.crt
on your client machine. You must then import this file into the certificate store of the client.
2.1.2. Importing a Certificate to a Client
Importing a certificate to a client relies on how the client stores and interprets certificates. See your client documentation for more information on importing a certificate.
2.2. Authentication
Any user with a Red Hat Virtualization Manager account has access to the API. All requests must be authenticated using either OAuth or basic authentication, as described below.
2.2.1. OAuth Authentication
Since version 4.0 of Red Hat Virtualization the preferred authentication mechanism is OAuth 2.0, as described in RFC 6749.
OAuth is a sophisticated protocol, with several mechanisms for obtaining authorization and access tokens. For use with the Red Hat Virtualization API, the only supported one is the Resource Owner Password Credentials Grant, as described in section 4.3 of RFC 6749.
You must first obtain a token, sending the user name and password to the Red Hat Virtualization Manager single sign-on service:
POST /ovirt-engine/sso/oauth/token HTTP/1.1 Host: myengine.example.com Content-Type: application/x-www-form-urlencoded Accept: application/json
The request body must contain the grant_type
, scope
, username
, and password
parameters:
Table 2.1. OAuth token request parameters
Name | Value |
---|---|
|
|
|
|
|
|
|
|
These parameters must be URL-encoded. For example, the @
character in the user name needs to be encoded as %40
. The resulting request body will be something like this:
grant_type=password&scope=ovirt-app-api&username=admin%40internal&password=mypassword
The scope
parameter is described as optional in the OAuth RFC, but when using it with the Red Hat Virtualization API it is mandatory, and its value must be ovirt-app-api
.
If the user name and password are valid, the Red Hat Virtualization Manager single sign-on service will respond with a JSON document similar to this one:
{ "access_token": "fqbR1ftzh8wBCviLxJcYuV5oSDI=", "token_type": "bearer", "scope": "...", ... }
For API authentication purposes, the only relevant name/value pair is the access_token
. Do not manipulate this in any way; use it exactly as provided by the SSO service.
Once the token has been obtained, it can be used to perform requests to the API by including it in the HTTP Authorization
header, and using the Bearer
scheme. For example, to get the list of virtual machines, send a request like this:
GET /ovirt-engine/api/vms HTTP/1.1 Host: myengine.example.com Accept: application/xml Authorization: Bearer fqbR1ftzh8wBCviLxJcYuV5oSDI=
The token can be used multiple times, for multiple requests, but it will eventually expire. When it expires, the server will reject the request with the 401 HTTP response code:
HTTP/1.1 401 Unauthorized
When this happens, a new token is needed, as the Red Hat Virtualization Manager single sign-on service does not currently support refreshing tokens. A new token can be requested using the same method described above.
2.2.2. Basic Authentication
Basic authentication is supported only for backwards compatibility; it is deprecated since version 4.0 of Red Hat Virtualization, and will be removed in the future.
Each request uses HTTP Basic Authentication [2] to encode the credentials. If a request does not include an appropriate Authorization
header, the server sends a 401 Authorization Required
response:
HEAD /ovirt-engine/api HTTP/1.1 Host: myengine.example.com HTTP/1.1 401 Authorization Required
Request are issued with an Authorization
header for the specified realm. Encode an appropriate Red Hat Virtualization Manager domain and user in the supplied credentials with the username@domain:password
convention.
The following table shows the process for encoding credentials in Base64.
Table 2.2. Encoding credentials for API access
Item | Value |
---|---|
User name |
|
Domain |
|
Password |
|
Unencoded credentials |
|
Base64 encoded credentials |
|
Provide the Base64-encoded credentials as shown:
HEAD /ovirt-engine/api HTTP/1.1 Host: myengine.example.com Authorization: Basic YWRtaW5AaW50ZXJuYWw6bXlwYXNzd29yZA== HTTP/1.1 200 OK
Basic authentication involves potentially sensitive information, such as passwords, sent as plain text. The API requires Hypertext Transfer Protocol Secure (HTTPS) for transport-level encryption of plain-text requests.
Some Base64 libraries break the result into multiple lines and terminate each line with a newline character. This breaks the header and causes a faulty request. The Authorization
header requires the encoded credentials on a single line within the header.
2.2.3. Authentication Sessions
The API also provides authentication session support. Send an initial request with authentication details, then send all subsequent requests using a session cookie to authenticate.
2.2.3.1. Requesting an Authenticated Session
Send a request with the
Authorization
andPrefer: persistent-auth
headers:HEAD /ovirt-engine/api HTTP/1.1 Host: myengine.example.com Authorization: Basic YWRtaW5AaW50ZXJuYWw6bXlwYXNzd29yZA== Prefer: persistent-auth HTTP/1.1 200 OK ...
This returns a response with the following header:
Set-Cookie: JSESSIONID=5dQja5ubr4yvI2MM2z+LZxrK; Path=/ovirt-engine/api; Secure
Take note of the
JSESSIONID=
value. In this example the value is5dQja5ubr4yvI2MM2z+LZxrK
.Send all subsequent requests with the
Prefer: persistent-auth
andCookie
headers with theJSESSIONID=
value. TheAuthorization
header is no longer needed when using an authenticated session.HEAD /ovirt-engine/api HTTP/1.1 Host: myengine.example.com Prefer: persistent-auth Cookie: JSESSIONID=5dQja5ubr4yvI2MM2z+LZxrK HTTP/1.1 200 OK ...
When the session is no longer required, perform a request to the sever without the
Prefer: persistent-auth
header.HEAD /ovirt-engine/api HTTP/1.1 Host: myengine.example.com Authorization: Basic YWRtaW5AaW50ZXJuYWw6bXlwYXNzd29yZA== HTTP/1.1 200 OK ...
Chapter 3. Common concepts
3.1. Types
The API uses the type concept to describe the different kinds of objects accepted and returned.
There are three relevant kinds of types:
3.2. Identified types
Many of the types used by the API represent identified objects, objects that have an unique identifier and exist independently of other objects. The types used to describe those objects extend the Identified type, which contains the following set of common attributes:
Attribute | Type | Description |
---|---|---|
|
Each object in the virtualization infrastructure contains an | |
| The canonical location of the object as an absolute path. | |
|
A user-supplied human readable name for the object. The | |
| A free-form user-supplied human readable description of the object. |
Currently for most types of objects the id
attribute is actually a randomly generated UUID, but this is an implementation detail, and users should not rely on that, as it may change in the future. Instead users should assume that these identifiers are just strings.
3.3. Objects
Objects are the individual instances of the types supported by the API. For example, the virtual machine with identifier 123
is an object of the Vm type.
3.4. Collections
A collection is a set of objects of the same type.
3.5. Representations
The state of objects needs to be represented when it is transferred beetween the client and the server. The API supports XML and JSON as the representation of the state of objects, both for input and output.
3.5.1. XML representation
The XML representation of an object consists of an XML element corresponding to the type of the object, XML attributes for the id
and href
attributes, and nested XML elements for the rest of the attributes. For example, the XML representation for a virtual machine appears as follows:
<vm id="123" href="/ovirt-engine/api/vms/123"> <name>myvm</name> <description>My VM</description> <memory>1073741824</memory> ... </vm>
The XML representation of a collection of objects consists of an XML element, named after the type of the objects, in plural. This contains the representations of the objects of the collection. For example, the XML respresentation for a collection of virtual machines appears as follows:
<vms> <vm id="123" href="/ovirt-engine/api/vms/123"> <name>yourvm</name> <description>Your VM</description> <memory>1073741824</memory> ... </vm> <vm id="456" href="/ovirt-engine/api/vms/456"> <name>myname</name> <description>My description</description> <memory>2147483648</memory> ... </vm> ... </vms>
In the XML representation of objects the id
and href
attributes are the only ones that are represented as XML attributes, the rest are represented as nested XML elements.
3.5.2. JSON representation
The JSON representation of an object consists of a JSON document containing a name/value pair for each attribute (including id
and href
). For example, the JSON representation of a virtual machine appears as follows:
{ "id": "123", "href": "/ovirt-engine/api/vms/123", "name": "myvm", "description": "My VM", "memory": 1073741824, ... }
The JSON representation of a collection of objects consists of a JSON document containg a name/value pair (named ater the type of the objects, in singular) which in turn contains an array with the representations of the objects of the collection. For example, the JSON respresentation for a collection of virtual machines appears as follows:
{ "vm": [ { "id": "123", "href": "/ovirt-engine/api/vms/123", "name": "myvm", "description": "My VM", "memory": 1073741824, ... }, { "id": "456", "href": "/ovirt-engine/api/vms/456", "name": "yourvm", "description": "Your VM", "memory": 2147483648, ... }, ] }
3.6. Services
Services are the parts of the server responsible for retrieving, adding updating, removing and executing actions on the objects supported by the API.
There are two relevant kinds of services:
- Services that manage a collection of objects
- These services are reponsible for listing existing objects and adding new objects. For example, the Vms service is responsible for managing the collection of virtual machines available in the system.
- Services that manage a specific object
- These services are responsible for retrieving, updating, deleting and executing actions in specific objects. For example, the Vm service is responsible for managing a specific virtual machine.
Each service is accessible via a particular path within the server. For example, the service that manages the collection of virtual machines available in the system is available in the via the path /vms
, and the service that manages the virtual machine 123
is available via the path /vms/123
.
All kinds of services have a set of methods that represent the operations that they can perform. The services that manage collections of objects usually have the list
and add
methods. The services that manage specific objects usually have the get
, update
and remove
methods. In addition, services may also have action methods, that represent less common operations. For example, the Vm service has a start method that is used to start a virtual machine.
For the more usual methods there is a direct mapping between the name of the method and the name of the HTTP method:
Method name | HTTP method |
---|---|
| POST |
| GET |
| GET |
| PUT |
| DELETE |
The path used in the HTTP request is the path of the service, with the /ovirt-engine/api
prefix.
For example, the request to list
the virtual machines should be like this, using the HTTP GET
method and the path /vms
:
GET /ovirt-engine/api/vms
For action methods the HTTP method is always POST
, and the name of the method is added as a suffix to the path. For example, the request to start virtual machine 123
should look like this, using the HTTP POST
method and the path /vms/123/start
:
POST /ovirt-engine/api/vms/123/start
Each method has a set of parameters.
Parameters are classified into two categories:
- Main parameter
-
The main parameter corresponds the object or collection that is retrieved, added or updated. This only applies to the
add
,get
,list
andupdate
methods, and there will be exactly one such main parameter per method. - Secondary parameters
- The rest of the parameters.
For example, the operation that adds a virtual machine (see here) has three parameters: vm
, clone
and clone_permissions
. The main parameter is vm
, as it describes the object that is added. The clone
and clone_permissions
parameters are secondary parameters.
The main parameter, when used for input, must be included in the body of the HTTP request. For example, when adding a virtual machine, the vm
parameter, of type Vm, must be included in the request body. So the complete request to add a virtual machine, including all the HTTP details, must look like this:
POST /ovirt-engine/api/vms HTTP/1.1 Host: myengine.example.com Authorization: Bearer fqbR1ftzh8wBCviLxJcYuV5oSDI= Content-Type: application/xml Accept: application/xml <vm> <name>myvm</name> <description>My VM</description> <cluster> <name>Default</name> </cluster> <template> <name>Blank</name> </template> </vm>
When used for output, the main parameters are included in the response body. For example, when adding a virtual machine, the vm
parameter will be included in the response body. So the complete response body will look like this:
HTTP/1.1 201 Created Content-Type: application/xml <vm href="/ovirt-engine/api/vms/123" id="123"> <name>myvm</name> <description>My VM</description> ... </vm>
Secondary parameters are only allowed for input (except for action methods, which are described later), and they must be included as query parameters. For example, when adding a virtual machine with the clone
parameter set to true
, the complete request must look like this:
POST /ovirt-engine/api/vms?clone=true HTTP/1.1 Host: myengine.example.com Authorization: Bearer fqbR1ftzh8wBCviLxJcYuV5oSDI= Content-Type: application/xml Accept: application/xml <vm> <name>myvm</name> <description>My VM</description> <cluster> <name>Default</name> </cluster> <template> <name>Blank</name> </template> </vm>
Action methods only have secondary parameters. They can be used for input and output, and they should be included in the request body, wrapped with an action
element. For example, the action method used to start a virtual machine (see here) has a vm
parameter to describe how the virtual machine should be started, and a use_cloud_init
parameter to specify if cloud-init should be used to configure the guest operating system. So the complete request to start virtual machine 123
using cloud-init will look like this when using XML:
POST /ovirt-engine/api/vms/123/start HTTP/1.1 Host: myengine.example.com Authorization: Bearer fqbR1ftzh8wBCviLxJcYuV5oSDI= Content-Type: application/xml Accept: application/xml <action> <use_cloud_init>true</use_cloud_init> <vm> <initialization> <nic_configurations> <nic_configuration> <name>eth0</name> <on_boot>true</on_boot> <boot_protocol>static</boot_protocol> <ip> <address>192.168.0.100</address> <netmask>255.255.255.0</netmask> <gateway>192.168.0.1</netmask> </ip> </nic_configuration> </nic_configurations> <dns_servers>192.168.0.1</dns_servers> </initialization> </vm> </action>
3.7. Searching
The list
method of some services has a search
parameter that can be used to specify search criteria. When used, the server will only return objects within the collection that satisfy those criteria. For example, the following request will return only the virtual machine named myvm
:
GET /ovirt-engine/api/vms?search=name%3Dmyvm
3.7.1. Maximum results parameter
Use the max
parameter to limit the number of objects returned. For example, the following request will only return one virtual machine, regardless of how many are available in the system:
GET /ovirt-engine/api/vms?max=1
A search request without the max
parameter will return all the objects. Specifying the max
parameter is recommended to reduce the impact of requests in the overall performance of the system.
3.7.2. Case sensitivity
By default queries are not case sensitive. For example, the following request will return the virtual machines named myvm
, MyVM
and MYVM
:
GET /ovirt-engine/api/vms?search=name%3Dmyvm
The optional case_sensitive
boolean parameter can be used to change this behaviour. For example, to get exactly the virtual machine named myhost
, and not MyHost
or MYHOST
, send a request like this:
GET /ovirt-engine/api/vms?search=name%3D=myvm&case_sensitive=true
3.7.3. Search syntax
The search
parameters use the same syntax as the Red Hat Virtualization query language:
(criteria) [sortby (element) asc|desc]
The sortby
clause is optional and only needed when ordering results.
Example search queries:
Collection | Criteria | Result |
---|---|---|
|
|
Returns a list of all hosts running virtual machines that are |
|
| Returns a list of all virtual machines running on the specified domain. |
|
|
Returns a list of all virtual machines belonging to users with the user name |
|
|
Returns a list of all events with severity higher than |
|
|
Returns a list of all events with severity higher than |
The value of the search
parameter must be URL-encoded to translate reserved characters, such as operators and spaces. For example, the equal sign should be encoded as %3D
:
GET /ovirt-engine/api/vms?search=name%3Dmyvm
3.7.4. Wildcards
The asterisk can be used as part of a value, to indicate that any string matches, including the emtpy string. For example, the following request will return all the virtual machines with names beginning with myvm
, such as myvm
, myvm2
, myvma
or myvm-webserver
:
GET /ovirt-engine/api/vms?search=name%3Dmyvm*
3.7.5. Pagination
Some Red Hat Virtualization environments contain large collections of objects. Retrieving all of them with one request isn’t practical, and hurts performace. To allow retrieving them page by page the search
parameter supports an optional page
clause. This, combined with the max
parameter, is the basis for paging. For example, to get the first page of virtual machines, with a page size of 10 virtual machines, send request like this:
GET /ovirt-engine/api/vms?search=page%201&max=10
The search parameter is URL-encoded, the actual value of the search
parameter, before encoding, is page 1
, so this is actually requesting the first page.
Increase the page
value to retrieve the next page:
GET /ovirt-engine/api/vms?search=page%202&max=10
The page
clause can be used in conjunction with other clauses inside the search
parameter. For example, the following request will return the second page of virtual machines, but sorting by name:
GET /ovirt-engine/api/vms?search=sortby%20name%20page%202&max=10
The API is stateless; it is not possible to retain a state between different requests since all requests are independent from each other. As a result, if a status change occurs between your requests, then the page results may be inconsistent.
For example, if you request a specific page from a list of virtual machines, and virtual machines are created or removed before you request the next page, then your results may be missing some of them, or contain duplicates.
3.8. Following links
The API returns references to related objects as links. For example, when a virtual machine is retrieved it contains links to its disk attachments and network interface cards:
<vm id="123" href="/ovirt-engine/api/vms/123"> ... <link rel="diskattachments" href="/ovirt-engine/api/vms/123/diskattachments"/> <link rel="nics" href="/ovirt-engine/api/vms/123/nics"/> ... </vm>
The complete description of those linked objects can be retrieved by sending separate requests:
GET /ovirt-engine/api/vms/123/diskattachments GET /ovirt-engine/api/vms/123/nics
However, in some situations it is more convenient for the application using the API to retrieve the linked information in the same request. This is useful, for example, when the additional network round trips introduce an unacceptable overhead, or when the multiple requests complicate the code of the application in an unacceptable way. For those use cases the API provides a follow
parameter that allows the application to retrieve the linked information using only one request.
The value of the follow
parameter is a list of strings, separated by commas. Each of those strings is the path of the linked object. For example, to retrieve the disk attachments and the NICs in the example above the request should be like this:
GET /ovirt-engine/api/vms/123?follow=disk_attachments,nics
That will return an response like this:
<vm id="123" href="/ovirt-engine/api/vms/123"> ... <disk_attachments> <disk_attachment id="456" href="/ovirt-engine/api/vms/123/diskattachments/456"> <active>true</active> <bootable>true</bootable> <interface>virtio_scsi</interface> <pass_discard>false</pass_discard> <read_only>false</read_only> <uses_scsi_reservation>false</uses_scsi_reservation> <disk id="789" href="/ovirt-engine/api/disks/789"/> </disk_attachment> ... </disk_attacments> <nics> <nic id="234" href="/ovirt-engine/api/vms/123/nics/234"> <name>eth0</name> <interface>virtio</interface> <linked>true</linked> <mac> <address>00:1a:4a:16:01:00</address> </mac> <plugged>true</plugged> </nic> ... </nics> ... </vm>
The path to the linked object can be a single word, as in the previous example, or it can be a sequence of words, separated by dots, to request nested data. For example, the previous example used disk_attachments
in order to retrieve the complete description of the disk attachments, but each disk attachment contains a link to the disk, which wasn’t followed. In order to also follow the links to the disks, the following request can be used:
POST /ovirt-engine/api/vms/123?follow=disk_attachments.disk
That will result in the following response:
<vm id="123" href="/ovirt-engine/api/vms/123"> <disk_attachments> <disk_attachment id="456" href="/ovirt-engine/api/vms/123/diskattachments/456"> <active>true</active> <bootable>true</bootable> <interface>virtio_scsi</interface> <pass_discard>false</pass_discard> <read_only>false</read_only> <uses_scsi_reservation>false</uses_scsi_reservation> <disk id="789" href="/ovirt-engine/api/disks/789"> <name>mydisk</name> <description>My disk</description> <actual_size>0</actual_size> <format>raw</format> <sparse>true</sparse> <status>ok</status> <storage_type>image</storage_type> <total_size>0</total_size> ... </disk> </disk_attachment> ... </disk_attachments> ... </vm>
The path can be made as deep as needed. For example, to also get the statistics of the disks:
POST /ovirt-engine/api/vms/123?follow=disk_attachments.disk.statistics
Multiple path elements and multiple paths can be combined. For example, to get the disk attachments and the network interface cards, both with their statistics:
POST /ovirt-engine/api/vms/123?follow=disk_attachments.disk.statistics,nics.statistics
Almost all the operations that retrieve objects support the follow
parameter, but make sure to explicitly check the reference documentation, as some operations may not support it, or may provide advice on how to use it to get the best performance.
Using the follow
parameter moves the overhead from the client side to the server side. When you request additional data, the server must fetch and merge it with the basic data. That consumes CPU and memory in the server side, and will in most cases require additional database queries. That may adversely affect the performance of the server, especially in large scale environments. Make sure to test your application in a realistic environment, and use the follow
parameter only when justified.
3.9. Permissions
Many of the services that manage a single object provide a reference to a permissions
service that manages the permissions assigned to that object. Each permission contains links to the user or group, the role and the object. For example, the permissions assigned to a specific virtual machine can be retrieved sending a request like this:
GET /ovirt-engine/api/vms/123/permissions
The response body will look like this:
<permissions> <permission id="456" href="/ovirt-engien/api/vms/123/permissions/456"> <user id="789" href="/ovirt-engine/api/users/789"/> <role id="abc" href="/ovirt-engine/api/roles/abc"/> <vm id="123" href="/ovirt-engine/api/vms/123"/> </permission> ... </permissions>
A permission is added to an object sending a POST
request with a permission representation to this service. Each new permission requires a role and a user.
3.10. Handling errors
Some errors require further explanation beyond a standard HTTP status code. For example, the API reports an unsuccessful object state update or action with a fault
in the response body. The fault contains the reason
and detail
attributes. For example, when the server receives a request to create a virtual machine without the mandatory name
attribute it will respond with the following HTTP response line:
HTTP/1.1 400 Bad Request
And the following response body:
<fault> <reason>Incomplete parameters</reason> <detail>Vm [name] required for add</detail> </fault>
Chapter 4. Quick Start Examples
The examples in this section show you how to use the REST API to set up a basic Red Hat Virtualization environment and to create a virtual machine. In addition to the standard prerequisites, these examples require the following:
- A networked and configured Red Hat Virtualization installation.
- An ISO file containing the virtual machine operating system you want to install. This chapter uses CentOS 7 for the installation ISO example.
The API examples use curl
to demonstrate API requests with a client application. You can use any application that sends HTTP requests.
The HTTP request headers in this example omit the Host
and Authorization
headers. However, these fields are mandatory and require data specific to your installation of Red Hat Virtualization.
The curl
examples use admin@internal
for the user name, mypassword
for the password, /etc/pki/ovirt-engine/ca.pem
for the certificate location, and myengine.example.com
for the host name. You must replace them with the correct values for your environment.
Red Hat Virtualization generates a unique identifier for the id
attribute for each resource. Identifier codes in this example will differ from the identifier codes in your Red Hat Virtualization environment.
In many examples, some attributes of the results returned by the API have been omitted, for brevity. See, for example, the Cluster reference for a complete list of attributes.
4.1. Access API entry point
The following request retrieves a representation of the main entry point for version 4 of the API:
GET /ovirt-engine/api HTTP/1.1 Version: 4 Accept: application/xml
The same request, but using the /v4
URL prefix instead of the Version
header:
GET /ovirt-engine/api/v4 HTTP/1.1 Accept: application/xml
The same request, using the curl
command:
curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --request GET \ --header 'Version: 4' \ --header 'Accept: application/xml' \ --user 'admin@internal:mypassword' \ https://myengine.example.com/ovirt-engine/api
The result is an object of type Api:
<api> <link href="/ovirt-engine/api/clusters" rel="clusters"/> <link href="/ovirt-engine/api/datacenters" rel="datacenters"/> ... <product_info> <name>oVirt Engine</name> <vendor>ovirt.org</vendor> <version> <build>0</build> <full_version>4.0.0-0.0.el7</full_version> <major>4</major> <minor>0</minor> <revision>0</revision> </version> </product_info> <special_objects> <blank_template href="..." id="..."/> <root_tag href="..." id="..."/> </special_objects> <summary> <hosts> <active>23</active> <total>30</total> </hosts> <storage_domains> <active>5</active> <total>6</total> </storage_domains> <users> <active>12</active> <total>102</total> </users> <vms> <active>253</active> <total>545</total> </vms> </summary> <time>2016-10-06T15:38:18.548+02:00</time> </api>
When neither the header nor the URL prefix are used, the server will automatically select a version. The default is version 4
. You can change the default version using the ENGINE_API_DEFAULT_VERSION
configuration parameter:
# echo "ENGINE_API_DEFAULT_VERSION=3" > \ /etc/ovirt-engine/engine.conf.d/99-set-default-version.conf # systemctl restart ovirt-engine
Changing this parameter affects all users of the API that don’t specify the version explicitly.
The entry point provides a user with links to the collections in a virtualization environment. The rel
attribute of each collection link provides a reference point for each link. The next step in this example examines the data center collection, which is available through the datacenters
link.
The entry point also contains other data such as product_info, special_objects and summary. This data is covered in chapters outside this example.
4.2. List data centers
Red Hat Virtualization creates a Default
data center on installation. This example uses the Default
data center as the basis for the virtual environment.
The following request retrieves a representation of the data centers:
GET /ovirt-engine/api/datacenters HTTP/1.1 Accept: application/xml
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --request GET \ --header 'Version: 4' \ --header 'Accept: application/xml' \ --user 'admin@internal:mypassword' \ https://myengine.example.com/ovirt-engine/api/datacenters
The result will be a list of objects of type DataCenter:
<data_centers> <data_center href="/ovirt-engine/api/datacenters/001" id="001"> <name>Default</name> <description>The default Data Center</description> <link href="/ovirt-engine/api/datacenters/001/clusters" rel="clusters"/> <link href="/ovirt-engine/api/datacenters/001/storagedomains" rel="storagedomains"/> ... <local>false</local> <quota_mode>disabled</quota_mode> <status>up</status> <supported_versions> <version> <major>4</major> <minor>0</minor> </version> </supported_versions> <version> <major>4</major> <minor>0</minor> </version> </data_center> ... </data_centers>
Note the id
of your Default
data center. It identifies this data center in relation to other resources of your virtual environment.
The data center also contains a link to the service that manages the storage domains attached to the data center:
<link href="/ovirt-engine/api/datacenters/001/storagedomains" rel="storagedomains"/>
That service is used to attach storage domains from the main storagedomains
collection, which this example covers later.
4.3. List host clusters
Red Hat Virtualization creates a Default
hosts cluster on installation. This example uses the Default
cluster to group resources in your Red Hat Virtualization environment.
The following request retrieves a representation of the cluster collection:
GET /ovirt-engine/api/clusters HTTP/1.1 Accept: application/xml
The same request, using the curl
command:
curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --request GET \ --header 'Version: 4' \ --header 'Accept: application/xml' \ --user 'admin@internal:mypassword' \ https://myengine.example.com/ovirt-engine/api/clusters
The result will be a list of objects of type Cluster:
<clusters> <cluster href="/ovirt-engine/api/clusters/002" id="002"> <name>Default</name> <description>The default server cluster</description> <link href="/ovirt-engine/api/clusters/002/networks" rel="networks"/> <link href="/ovirt-engine/api/clusters/002" rel="permissions"/> ... <cpu> <architecture>x86_64</architecture> <type>Intel Conroe Family</type> </cpu> <version> <major>4</major> <minor>0</minor> </version> <data_center href="/ovirt-engine/api/datacenters/001" id="001"/> </cluster> ... </clusters>
Note the id
of your Default
host cluster. It identifies this host cluster in relation to other resources of your virtual environment.
The Default
cluster is associated with the Default
data center through a relationship using the id
and href
attributes of the data_center
link:
<data_center href="/ovirt-engine/api/datacenters/001" id="001"/>
The networks
link is a reference to the service that manages the networks associated to this cluster. The next section examines the networks collection in more detail.
4.4. List logical networks
Red Hat Virtualization creates a default ovirtmgmt
network on installation. This network acts as the management network for Red Hat Virtualization Manager to access hosts.
This network is associated with the Default
cluster and is a member of the Default
data center. This example uses the ovirtmgmt
network to connect the virtual machines.
The following request retrieves the list of logical networks:
GET /ovirt-engine/api/networks HTTP/1.1 Accept: application/xml
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --request GET \ --header 'Version: 4' \ --header 'Accept: application/xml' \ --user 'admin@internal:mypassword' \ https://myengine.example.com/ovirt-engine/api/networks
The result will be a list of objects of type Network:
<networks> <network href="/ovirt-engine/api/networks/003" id="003"> <name>ovirtmgmt</name> <description>Management Network</description> <link href="/ovirt-engine/api/networks/003/permissions" rel="permissions"/> <link href="/ovirt-engine/api/networks/003/vnicprofiles" rel="vnicprofiles"/> <link href="/ovirt-engine/api/networks/003/networklabels" rel="networklabels"/> <mtu>0</mtu> <stp>false</stp> <usages> <usage>vm</usage> </usages> <data_center href="/ovirt-engine/api/datacenters/001" id="001"/> </network> ... </networks>
The ovirtmgmt
network is attached to the Default
data center through a relationship using the data center’s id
.
The ovirtmgmt
network is also attached to the Default
cluster through a relationship in the cluster’s network sub-collection.
4.5. List hosts
This example retrieves the list of hosts and shows a host named myhost
registered with the virtualization environment:
GET /ovirt-engine/api/hosts HTTP/1.1 Accept: application/xml
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --request GET \ --header 'Version: 4' \ --header 'Accept: application/xml' \ --user 'admin@internal:mypassword' \ https://myengine.example.com/ovirt-engine/api/hosts
The result will be a list of objects of type Host:
<hosts> <host href="/ovirt-engine/api/hosts/004" id="004"> <name>myhost</name> <link href="/ovirt-engine/api/hosts/004/nics" rel="nics"/> ... <address>node40.example.com</address> <cpu> <name>Intel Core Processor (Haswell, no TSX)</name> <speed>3600</speed> <topology> <cores>1</cores> <sockets>2</sockets> <threads>1</threads> </topology> </cpu> <memory>8371830784</memory> <os> <type>RHEL</type> <version> <full_version>7 - 2.1511.el7.centos.2.10</full_version> <major>7</major> </version> </os> <port>54321</port> <status>up</status> <cluster href="/ovirt-engine/api/clusters/002" id="002"/> </host> ... </hosts>
Note the id
of your host. It identifies this host in relation to other resources of your virtual environment.
This host is a member of the Default
cluster and accessing the nics
sub-collection shows this host has a connection to the ovirtmgmt
network.
4.6. Create NFS data storage
An NFS data storage domain is an exported NFS share attached to a data center and provides storage for virtualized guest images. Creation of a new storage domain requires a POST
request, with the storage domain representation included, sent to the URL of the storage domain collection.
You can enable the wipe after delete option by default on the storage domain. To configure this specify wipe_after_delete
in the POST request. This option can be edited after the domain is created, but doing so will not change the wipe after delete property of disks that already exist.
The request should be like this:
POST /ovirt-engine/api/storagedomains HTTP/1.1 Accept: application/xml Content-type: application/xml
And the request body should be like this:
<storage_domain> <name>mydata</name> <type>data</type> <description>My data</description> <storage> <type>nfs</type> <address>mynfs.example.com</address> <path>/exports/mydata</path> </storage> <host> <name>myhost</name> </host> </storage_domain>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <storage_domain> <name>mydata</name> <description>My data</description> <type>data</type> <storage> <type>nfs</type> <address>mynfs.example.com</address> <path>/exports/mydata</path> </storage> <host> <name>myhost</name> </host> </storage_domain> ' \ https://myengine.example.com/ovirt-engine/api/storagedomains
The server uses host myhost
to create a NFS data storage domain called mydata
with an export path of mynfs.example.com:/exports/mydata
. The API also returns the following representation of the newly created storage domain resource (of type StorageDomain):
<storage_domain href="/ovirt-engine/api/storagedomains/005" id="005"> <name>mydata</name> <description>My data</description> <available>42949672960</available> <committed>0</committed> <master>false</master> <status>unattached</status> <storage> <address>mynfs.example.com</address> <path>/exports/mydata</path> <type>nfs</type> </storage> <storage_format>v3</storage_format> <type>data</type> <used>9663676416</used> </storage_domain>
4.7. Create NFS ISO storage
An NFS ISO storage domain is a mounted NFS share attached to a data center and provides storage for DVD/CD-ROM ISO and virtual floppy disk (VFD) image files. Creation of a new storage domain requires a POST
request, with the storage domain representation included, sent to the URL of the storage domain collection:
The request should be like this:
POST /ovirt-engine/api/storagedomains HTTP/1.1 Accept: application/xml Content-type: application/xml
And the request body should be like this:
<storage_domain> <name>myisos</name> <description>My ISOs</description> <type>iso</type> <storage> <type>nfs</type> <address>mynfs.example.com</address> <path>/exports/myisos</path> </storage> <host> <name>myhost</name> </host> </storage_domain>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <storage_domain> <name>myisos</name> <description>My ISOs</description> <type>iso</type> <storage> <type>nfs</type> <address>mynfs.example.com</address> <path>/exports/myisos</path> </storage> <host> <name>myhost</name> </host> </storage_domain> ' \ https://myengine.example.com/ovirt-engine/api/storagedomains
The server uses host myhost
to create a NFS ISO storage domain called myisos
with an export path of mynfs.example.com:/exports/myisos
. The API also returns the following representation of the newly created storage domain resource (of type StorageDomain):
<storage_domain href="/ovirt-engine/api/storagedomains/006" id="006"> <name>myiso</name> <description>My ISOs</description> <available>42949672960</available> <committed>0</committed> <master>false</master> <status>unattached</status> <storage> <address>mynfs.example.com</address> <path>/exports/myisos</path> <type>nfs</type> </storage> <storage_format>v1</storage_format> <type>iso</type> <used>9663676416</used> </storage_domain>
4.8. Attach storage domains to data center
The following example attaches the mydata
and myisos
storage domains to the Default
data center.
To attach the mydata
storage domain, send a request like this:
POST /ovirt-engine/api/datacenters/001/storagedomains HTTP/1.1 Accept: application/xml Content-type: application/xml
With a request body like this:
<storage_domain> <name>mydata</name> </storage_domain>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <storage_domain> <name>mydata</name> </storage_domain> ' \ https://myengine.example.com/ovirt-engine/api/datacenters/001/storagedomains
To attach the myisos
storage domain, send a request like this:
POST /ovirt-engine/api/datacenters/001/storagedomains HTTP/1.1 Accept: application/xml Content-type: application/xml
With a request body like this:
<storage_domain> <name>myisos</name> </storage_domain>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <storage_domain> <name>myisos</name> </storage_domain> ' \ https://myengine.example.com/ovirt-engine/api/datacenters/001/storagedomains
4.9. Create virtual machine
The following example creates a virtual machine called myvm
on the Default
cluster using the virtualization environment’s Blank
template as a basis. The request also defines the virtual machine’s memory as 512 MiB and sets the boot device to a virtual hard disk.
The request should be contain an object of type Vm describing the virtual machine to create:
POST /ovirt-engine/api/vms HTTP/1.1 Accept: application/xml Content-type: application/xml
And the request body should be like this:
<vm> <name>myvm</name> <description>My VM</description> <cluster> <name>Default</name> </cluster> <template> <name>Blank</name> </template> <memory>536870912</memory> <os> <boot> <devices> <device>hd</device> </devices> </boot> </os> </vm>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <vm> <name>myvm</name> <description>My VM</description> <cluster> <name>Default</name> </cluster> <template> <name>Blank</name> </template> <memory>536870912</memory> <os> <boot> <devices> <device>hd</device> </devices> </boot> </os> </vm> ' \ https://myengine.example.com/ovirt-engine/api/vms
The response body will be an object of the Vm type:
<vm href="/ovirt-engine/api/vms/007" id="007"> <name>myvm</name> <link href="/ovirt-engine/api/vms/007/diskattachments" rel="diskattachments"/> <link href="/ovirt-engine/api/vms/007/nics" rel="nics"/> ... <cpu> <architecture>x86_64</architecture> <topology> <cores>1</cores> <sockets>1</sockets> <threads>1</threads> </topology> </cpu> <memory>1073741824</memory> <os> <boot> <devices> <device>hd</device> </devices> </boot> <type>other</type> </os> <type>desktop</type> <cluster href="/ovirt-engine/api/clusters/002" id="002"/> <status>down</status> <original_template href="/ovirt-engine/api/templates/000" id="00"/> <template href="/ovirt-engine/api/templates/000" id="000"/> </vm>
4.10. Create a virtual machine NIC
The following example creates a virtual network interface to connect the example virtual machine to the ovirtmgmt
network.
The request should be like this:
POST /ovirt-engine/api/vms/007/nics HTTP/1.1 Content-Type: application/xml Accept: application/xml
The request body should contain an object of type Nic describing the NIC to be created:
<nic> <name>mynic</name> <description>My network interface card</description> </nic>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <nic> <name>mynic</name> <description>My network interface card</description> </nic> ' \ https://myengine.example.com/ovirt-engine/api/vms/007/nics
4.11. Create virtual machine disk
The following example creates an 8 GiB copy-on-write disk for the example virtual machine.
The request should be like this:
POST /ovirt-engine/api/vms/007/diskattachments HTTP/1.1 Content-Type: application/xml Accept: application/xml
The request body should be an object of type DiskAttachment describing the disk and how it will be attached to the virtual machine:
<disk_attachment> <bootable>false</bootable> <interface>virtio</interface> <active>true</active> <disk> <description>My disk</description> <format>cow</format> <name>mydisk</name> <provisioned_size>8589934592</provisioned_size> <storage_domains> <storage_domain> <name>mydata</name> </storage_domain> </storage_domains> </disk> </disk_attachment>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <disk_attachment> <bootable>false</bootable> <interface>virtio</interface> <active>true</active> <disk> <description>My disk</description> <format>cow</format> <name>mydisk</name> <provisioned_size>8589934592</provisioned_size> <storage_domains> <storage_domain> <name>mydata</name> </storage_domain> </storage_domains> </disk> </disk_attachment> ' \ https://myengine.example.com/ovirt-engine/api/vms/007/diskattachments
The storage_domains
attribute tells the API to store the disk on the mydata
storage domain.
4.12. Attach ISO image to virtual machine
The boot media for the following virtual machine example requires a CD-ROM or DVD ISO image for an operating system installation. This example uses a CentOS 7 image.
ISO images must be available in the myisos
ISO domain for the virtual machines to use. You can use Section 6.114, “ImageTransfers” to create an image transfer and Section 6.113, “ImageTransfer” to upload the ISO image.
Once the ISO image is uploaded, an API can be used to request the list of files from the ISO storage domain:
GET /ovirt-engine/api/storagedomains/006/files HTTP/1.1 Accept: application/xml
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request GET \ --header 'Version: 4' \ --header 'Accept: application/xml' \ https://myengine.example.com/ovirt-engine/api/storagedomains/006/files
The server returns the following list of objects of type File, one for each available ISO (or floppy) image:
<files> <file href="..." id="CentOS-7-x86_64-Minimal.iso"> <name>CentOS-7-x86_64-Minimal.iso</name> </file> ... </files>
An API user attaches the CentOS-7-x86_64-Minimal.iso
to the example virtual machine. Attaching an ISO image is equivalent to using the Change CD button in the administration or user portal applications.
The request should be like this:
PUT /ovirt-engine/api/vms/007/cdroms/00000000-0000-0000-0000-000000000000 HTTP/1.1 Accept: application/xml Content-type: application/xml
The request body should be an object of type Cdrom containing an inner file
attribute to indicate the identifier of the ISO (or floppy) image:
<cdrom> <file id="CentOS-7-x86_64-Minimal.iso"/> </cdrom>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request PUT \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <cdrom> <file id="CentOS-7-x86_64-Minimal.iso"/> </cdrom> ' \ https://myengine.example.com/ovirt-engine/api/vms/007/cdroms/00000000-0000-0000-0000-000000000000
For more details see the documentation of the service that manages virtual machine CD-ROMS.
4.13. Start the virtual machine
The virtual environment is complete and the virtual machine contains all necessary components to function. This example starts the virtual machine using the start method.
The request should be like this:
POST /ovirt-engine/api/vms/007/start HTTP/1.1 Accept: application/xml Content-type: application/xml
The request body should be like this:
<action> <vm> <os> <boot> <devices> <device>cdrom</device> </devices> </boot> </os> </vm> </action>
The same request, using the curl
command:
# curl \ --cacert '/etc/pki/ovirt-engine/ca.pem' \ --user 'admin@internal:mypassword' \ --request POST \ --header 'Version: 4' \ --header 'Content-Type: application/xml' \ --header 'Accept: application/xml' \ --data ' <action> <vm> <os> <boot> <devices> <device>cdrom</device> </devices> </boot> </os> </vm> </action> ' \ https://myengine.example.com/ovirt-engine/api/vms/007/start
The additional request body sets the virtual machine’s boot device to CD-ROM for this boot only. This enables the virtual machine to install the operating system from the attached ISO image. The boot device reverts back to disk for all future boots.
Chapter 5. Requests
This section enumerates all the requests that are available in the API.
- POST /affinitylabels
- GET /affinitylabels
- GET /affinitylabels/{label:id}
- PUT /affinitylabels/{label:id}
- DELETE /affinitylabels/{label:id}
- POST /affinitylabels/{label:id}/hosts
- GET /affinitylabels/{label:id}/hosts
- DELETE /affinitylabels/{label:id}/hosts/{host:id}
- GET /affinitylabels/{label:id}/hosts/{host:id}
- POST /affinitylabels/{label:id}/vms
- GET /affinitylabels/{label:id}/vms
- DELETE /affinitylabels/{label:id}/vms/{vm:id}
- GET /affinitylabels/{label:id}/vms/{vm:id}
- POST /bookmarks
- GET /bookmarks
- GET /bookmarks/{bookmark:id}
- PUT /bookmarks/{bookmark:id}
- DELETE /bookmarks/{bookmark:id}
- GET /clusterlevels
- GET /clusterlevels/{level:id}
- GET /clusterlevels/{level:id}/clusterfeatures
- GET /clusterlevels/{level:id}/clusterfeatures/{feature:id}
- POST /clusters
- GET /clusters
- GET /clusters/{cluster:id}
- PUT /clusters/{cluster:id}
- DELETE /clusters/{cluster:id}
- POST /clusters/{cluster:id}/affinitygroups
- GET /clusters/{cluster:id}/affinitygroups
- GET /clusters/{cluster:id}/affinitygroups/{group:id}
- PUT /clusters/{cluster:id}/affinitygroups/{group:id}
- DELETE /clusters/{cluster:id}/affinitygroups/{group:id}
- POST /clusters/{cluster:id}/affinitygroups/{group:id}/vms
- GET /clusters/{cluster:id}/affinitygroups/{group:id}/vms
- DELETE /clusters/{cluster:id}/affinitygroups/{group:id}/vms/{vm:id}
- POST /clusters/{cluster:id}/cpuprofiles
- GET /clusters/{cluster:id}/cpuprofiles
- GET /clusters/{cluster:id}/cpuprofiles/{profile:id}
- DELETE /clusters/{cluster:id}/cpuprofiles/{profile:id}
- GET /clusters/{cluster:id}/enabledfeatures
- POST /clusters/{cluster:id}/enabledfeatures
- GET /clusters/{cluster:id}/enabledfeatures/{feature:id}
- DELETE /clusters/{cluster:id}/enabledfeatures/{feature:id}
- GET /clusters/{cluster:id}/externalnetworkproviders
- GET /clusters/{cluster:id}/glusterhooks
- GET /clusters/{cluster:id}/glusterhooks/{hook:id}
- DELETE /clusters/{cluster:id}/glusterhooks/{hook:id}
- POST /clusters/{cluster:id}/glusterhooks/{hook:id}/disable
- POST /clusters/{cluster:id}/glusterhooks/{hook:id}/enable
- POST /clusters/{cluster:id}/glusterhooks/{hook:id}/resolve
- POST /clusters/{cluster:id}/glustervolumes
- GET /clusters/{cluster:id}/glustervolumes
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}
- DELETE /clusters/{cluster:id}/glustervolumes/{volume:id}
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/getprofilestatistics
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks
- DELETE /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/activate
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/migrate
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/stopmigrate
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}
- DELETE /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}/replace
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}/statistics
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}/statistics/{statistic:id}
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/rebalance
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/resetalloptions
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/resetoption
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/setoption
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/start
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/startprofile
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}/statistics
- GET /clusters/{cluster:id}/glustervolumes/{volume:id}/statistics/{statistic:id}
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/stop
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/stopprofile
- POST /clusters/{cluster:id}/glustervolumes/{volume:id}/stoprebalance
- GET /clusters/{cluster:id}/networkfilters
- GET /clusters/{cluster:id}/networkfilters/{networkfilter:id}
- POST /clusters/{cluster:id}/networks
- GET /clusters/{cluster:id}/networks
- GET /clusters/{cluster:id}/networks/{network:id}
- DELETE /clusters/{cluster:id}/networks/{network:id}
- PUT /clusters/{cluster:id}/networks/{network:id}
- POST /clusters/{cluster:id}/permissions
- GET /clusters/{cluster:id}/permissions
- GET /clusters/{cluster:id}/permissions/{permission:id}
- DELETE /clusters/{cluster:id}/permissions/{permission:id}
- POST /clusters/{cluster:id}/resetemulatedmachine
- POST /clusters/{cluster:id}/syncallnetworks
- POST /cpuprofiles
- GET /cpuprofiles
- GET /cpuprofiles/{profile:id}
- PUT /cpuprofiles/{profile:id}
- DELETE /cpuprofiles/{profile:id}
- POST /cpuprofiles/{profile:id}/permissions
- GET /cpuprofiles/{profile:id}/permissions
- GET /cpuprofiles/{profile:id}/permissions/{permission:id}
- DELETE /cpuprofiles/{profile:id}/permissions/{permission:id}
- POST /datacenters
- GET /datacenters
- GET /datacenters/{datacenter:id}
- PUT /datacenters/{datacenter:id}
- DELETE /datacenters/{datacenter:id}
- POST /datacenters/{datacenter:id}/clusters
- GET /datacenters/{datacenter:id}/clusters
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}
- PUT /datacenters/{datacenter:id}/clusters/{cluster:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups/{group:id}
- PUT /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups/{group:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups/{group:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups/{group:id}/vms
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups/{group:id}/vms
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/affinitygroups/{group:id}/vms/{vm:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/cpuprofiles
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/cpuprofiles
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/cpuprofiles/{profile:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/cpuprofiles/{profile:id}
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/enabledfeatures
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/enabledfeatures
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/enabledfeatures/{feature:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/enabledfeatures/{feature:id}
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/externalnetworkproviders
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glusterhooks
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glusterhooks/{hook:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/glusterhooks/{hook:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glusterhooks/{hook:id}/disable
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glusterhooks/{hook:id}/enable
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glusterhooks/{hook:id}/resolve
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/getprofilestatistics
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/activate
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/migrate
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/stopmigrate
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}/replace
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}/statistics
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/glusterbricks/{brick:id}/statistics/{statistic:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/rebalance
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/resetalloptions
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/resetoption
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/setoption
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/start
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/startprofile
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/statistics
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/statistics/{statistic:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/stop
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/stopprofile
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/glustervolumes/{volume:id}/stoprebalance
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/networkfilters
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/networkfilters/{networkfilter:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/networks
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/networks
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/networks/{network:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/networks/{network:id}
- PUT /datacenters/{datacenter:id}/clusters/{cluster:id}/networks/{network:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/permissions
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/permissions
- GET /datacenters/{datacenter:id}/clusters/{cluster:id}/permissions/{permission:id}
- DELETE /datacenters/{datacenter:id}/clusters/{cluster:id}/permissions/{permission:id}
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/resetemulatedmachine
- POST /datacenters/{datacenter:id}/clusters/{cluster:id}/syncallnetworks
- POST /datacenters/{datacenter:id}/iscsibonds
- GET /datacenters/{datacenter:id}/iscsibonds
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}
- PUT /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}
- POST /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}
- PUT /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}
- POST /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/networklabels
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/networklabels
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/networklabels/{label:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/networklabels/{label:id}
- POST /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/permissions
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/permissions
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/permissions/{permission:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/permissions/{permission:id}
- POST /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles/{profile:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles/{profile:id}
- POST /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions/{permission:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions/{permission:id}
- POST /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/storageserverconnections
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/storageserverconnections
- GET /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/storageserverconnections/{storageconnection:id}
- PUT /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/storageserverconnections/{storageconnection:id}
- DELETE /datacenters/{datacenter:id}/iscsibonds/{iscsibond:id}/storageserverconnections/{storageconnection:id}
- POST /datacenters/{datacenter:id}/networks
- GET /datacenters/{datacenter:id}/networks
- GET /datacenters/{datacenter:id}/networks/{network:id}
- DELETE /datacenters/{datacenter:id}/networks/{network:id}
- PUT /datacenters/{datacenter:id}/networks/{network:id}
- POST /datacenters/{datacenter:id}/permissions
- GET /datacenters/{datacenter:id}/permissions
- GET /datacenters/{datacenter:id}/permissions/{permission:id}
- DELETE /datacenters/{datacenter:id}/permissions/{permission:id}
- POST /datacenters/{datacenter:id}/qoss
- GET /datacenters/{datacenter:id}/qoss
- GET /datacenters/{datacenter:id}/qoss/{qos:id}
- PUT /datacenters/{datacenter:id}/qoss/{qos:id}
- DELETE /datacenters/{datacenter:id}/qoss/{qos:id}
- POST /datacenters/{datacenter:id}/quotas
- GET /datacenters/{datacenter:id}/quotas
- GET /datacenters/{datacenter:id}/quotas/{quota:id}
- PUT /datacenters/{datacenter:id}/quotas/{quota:id}
- DELETE /datacenters/{datacenter:id}/quotas/{quota:id}
- POST /datacenters/{datacenter:id}/quotas/{quota:id}/permissions
- GET /datacenters/{datacenter:id}/quotas/{quota:id}/permissions
- GET /datacenters/{datacenter:id}/quotas/{quota:id}/permissions/{permission:id}
- DELETE /datacenters/{datacenter:id}/quotas/{quota:id}/permissions/{permission:id}
- POST /datacenters/{datacenter:id}/quotas/{quota:id}/quotaclusterlimits
- GET /datacenters/{datacenter:id}/quotas/{quota:id}/quotaclusterlimits
- GET /datacenters/{datacenter:id}/quotas/{quota:id}/quotaclusterlimits/{limit:id}
- DELETE /datacenters/{datacenter:id}/quotas/{quota:id}/quotaclusterlimits/{limit:id}
- POST /datacenters/{datacenter:id}/quotas/{quota:id}/quotastoragelimits
- GET /datacenters/{datacenter:id}/quotas/{quota:id}/quotastoragelimits
- GET /datacenters/{datacenter:id}/quotas/{quota:id}/quotastoragelimits/{limit:id}
- DELETE /datacenters/{datacenter:id}/quotas/{quota:id}/quotastoragelimits/{limit:id}
- POST /datacenters/{datacenter:id}/storagedomains
- GET /datacenters/{datacenter:id}/storagedomains
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}
- DELETE /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/activate
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/deactivate
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks
- PUT /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}
- DELETE /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/copy
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/export
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/move
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/permissions
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/permissions
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/permissions/{permission:id}
- DELETE /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/permissions/{permission:id}
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/register
- POST /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/sparsify
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/statistics
- GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/statistics/{statistic:id}
- POST /diskprofiles
- GET /diskprofiles
- GET /diskprofiles/{diskprofile:id}
- PUT /diskprofiles/{diskprofile:id}
- DELETE /diskprofiles/{diskprofile:id}
- POST /diskprofiles/{diskprofile:id}/permissions
- GET /diskprofiles/{diskprofile:id}/permissions
- GET /diskprofiles/{diskprofile:id}/permissions/{permission:id}
- DELETE /diskprofiles/{diskprofile:id}/permissions/{permission:id}
- POST /disks
- GET /disks
- PUT /disks/{disk:id}
- GET /disks/{disk:id}
- DELETE /disks/{disk:id}
- POST /disks/{disk:id}/copy
- POST /disks/{disk:id}/export
- POST /disks/{disk:id}/move
- POST /disks/{disk:id}/permissions
- GET /disks/{disk:id}/permissions
- GET /disks/{disk:id}/permissions/{permission:id}
- DELETE /disks/{disk:id}/permissions/{permission:id}
- POST /disks/{disk:id}/reduce
- POST /disks/{disk:id}/refreshlun
- POST /disks/{disk:id}/sparsify
- GET /disks/{disk:id}/statistics
- GET /disks/{disk:id}/statistics/{statistic:id}
- GET /domains
- GET /domains/{domain:id}
- GET /domains/{domain:id}/groups
- GET /domains/{domain:id}/groups/{group:id}
- GET /domains/{domain:id}/users
- GET /domains/{domain:id}/users/{user:id}
- POST /events
- GET /events
- POST /events/undelete
- GET /events/{event:id}
- DELETE /events/{event:id}
- POST /externalhostproviders
- GET /externalhostproviders
- GET /externalhostproviders/{provider:id}
- PUT /externalhostproviders/{provider:id}
- DELETE /externalhostproviders/{provider:id}
- GET /externalhostproviders/{provider:id}/certificates
- GET /externalhostproviders/{provider:id}/certificates/{certificate:id}
- GET /externalhostproviders/{provider:id}/computeresources
- GET /externalhostproviders/{provider:id}/computeresources/{resource:id}
- GET /externalhostproviders/{provider:id}/discoveredhosts
- GET /externalhostproviders/{provider:id}/discoveredhosts/{host:id}
- GET /externalhostproviders/{provider:id}/hostgroups
- GET /externalhostproviders/{provider:id}/hostgroups/{group:id}
- GET /externalhostproviders/{provider:id}/hosts
- GET /externalhostproviders/{provider:id}/hosts/{host:id}
- POST /externalhostproviders/{provider:id}/importcertificates
- POST /externalhostproviders/{provider:id}/testconnectivity
- POST /externalvmimports
- POST /groups
- GET /groups
- GET /groups/{group:id}
- DELETE /groups/{group:id}
- POST /groups/{group:id}/permissions
- GET /groups/{group:id}/permissions
- GET /groups/{group:id}/permissions/{permission:id}
- DELETE /groups/{group:id}/permissions/{permission:id}
- GET /groups/{group:id}/roles
- GET /groups/{group:id}/roles/{role:id}
- DELETE /groups/{group:id}/roles/{role:id}
- PUT /groups/{group:id}/roles/{role:id}
- POST /groups/{group:id}/roles/{role:id}/permits
- GET /groups/{group:id}/roles/{role:id}/permits
- GET /groups/{group:id}/roles/{role:id}/permits/{permit:id}
- DELETE /groups/{group:id}/roles/{role:id}/permits/{permit:id}
- POST /groups/{group:id}/tags
- GET /groups/{group:id}/tags
- GET /groups/{group:id}/tags/{tag:id}
- DELETE /groups/{group:id}/tags/{tag:id}
- POST /hosts
- GET /hosts
- GET /hosts/{host:id}
- PUT /hosts/{host:id}
- DELETE /hosts/{host:id}
- POST /hosts/{host:id}/activate
- POST /hosts/{host:id}/affinitylabels
- GET /hosts/{host:id}/affinitylabels
- GET /hosts/{host:id}/affinitylabels/{label:id}
- DELETE /hosts/{host:id}/affinitylabels/{label:id}
- POST /hosts/{host:id}/approve
- POST /hosts/{host:id}/commitnetconfig
- POST /hosts/{host:id}/deactivate
- GET /hosts/{host:id}/devices
- GET /hosts/{host:id}/devices/{device:id}
- POST /hosts/{host:id}/enrollcertificate
- GET /hosts/{host:id}/externalnetworkproviderconfigurations
- GET /hosts/{host:id}/externalnetworkproviderconfigurations/{configuration:id}
- POST /hosts/{host:id}/fence
- POST /hosts/{host:id}/fenceagents
- GET /hosts/{host:id}/fenceagents
- GET /hosts/{host:id}/fenceagents/{agent:id}
- PUT /hosts/{host:id}/fenceagents/{agent:id}
- DELETE /hosts/{host:id}/fenceagents/{agent:id}
- POST /hosts/{host:id}/forceselectspm
- GET /hosts/{host:id}/hooks
- GET /hosts/{host:id}/hooks/{hook:id}
- POST /hosts/{host:id}/install
- POST /hosts/{host:id}/iscsidiscover
- POST /hosts/{host:id}/iscsilogin
- GET /hosts/{host:id}/katelloerrata
- GET /hosts/{host:id}/katelloerrata/{katelloerratum:id}
- POST /hosts/{host:id}/networkattachments
- GET /hosts/{host:id}/networkattachments
- GET /hosts/{host:id}/networkattachments/{attachment:id}
- PUT /hosts/{host:id}/networkattachments/{attachment:id}
- DELETE /hosts/{host:id}/networkattachments/{attachment:id}
- GET /hosts/{host:id}/nics
- GET /hosts/{host:id}/nics/{nic:id}
- GET /hosts/{host:id}/nics/{nic:id}/linklayerdiscoveryprotocolelements
- POST /hosts/{host:id}/nics/{nic:id}/networkattachments
- GET /hosts/{host:id}/nics/{nic:id}/networkattachments
- GET /hosts/{host:id}/nics/{nic:id}/networkattachments/{attachment:id}
- PUT /hosts/{host:id}/nics/{nic:id}/networkattachments/{attachment:id}
- DELETE /hosts/{host:id}/nics/{nic:id}/networkattachments/{attachment:id}
- POST /hosts/{host:id}/nics/{nic:id}/networklabels
- GET /hosts/{host:id}/nics/{nic:id}/networklabels
- GET /hosts/{host:id}/nics/{nic:id}/networklabels/{label:id}
- DELETE /hosts/{host:id}/nics/{nic:id}/networklabels/{label:id}
- GET /hosts/{host:id}/nics/{nic:id}/statistics
- GET /hosts/{host:id}/nics/{nic:id}/statistics/{statistic:id}
- POST /hosts/{host:id}/nics/{nic:id}/updatevirtualfunctionsconfiguration
- POST /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowedlabels
- GET /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowedlabels
- GET /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowedlabels/{label:id}
- DELETE /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowedlabels/{label:id}
- POST /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowednetworks
- GET /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowednetworks
- GET /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowednetworks/{network:id}
- DELETE /hosts/{host:id}/nics/{nic:id}/virtualfunctionallowednetworks/{network:id}
- GET /hosts/{host:id}/numanodes
- GET /hosts/{host:id}/numanodes/{node:id}
- GET /hosts/{host:id}/numanodes/{node:id}/statistics
- GET /hosts/{host:id}/numanodes/{node:id}/statistics/{statistic:id}
- POST /hosts/{host:id}/permissions
- GET /hosts/{host:id}/permissions
- GET /hosts/{host:id}/permissions/{permission:id}
- DELETE /hosts/{host:id}/permissions/{permission:id}
- POST /hosts/{host:id}/refresh
- POST /hosts/{host:id}/setupnetworks
- GET /hosts/{host:id}/statistics
- GET /hosts/{host:id}/statistics/{statistic:id}
- GET /hosts/{host:id}/storage
- GET /hosts/{host:id}/storage/{storage:id}
- POST /hosts/{host:id}/storageconnectionextensions
- GET /hosts/{host:id}/storageconnectionextensions
- GET /hosts/{host:id}/storageconnectionextensions/{storageconnectionextension:id}
- PUT /hosts/{host:id}/storageconnectionextensions/{storageconnectionextension:id}
- DELETE /hosts/{host:id}/storageconnectionextensions/{storageconnectionextension:id}
- POST /hosts/{host:id}/syncallnetworks
- POST /hosts/{host:id}/tags
- GET /hosts/{host:id}/tags
- GET /hosts/{host:id}/tags/{tag:id}
- DELETE /hosts/{host:id}/tags/{tag:id}
- GET /hosts/{host:id}/unmanagednetworks
- GET /hosts/{host:id}/unmanagednetworks/{unmanagednetwork:id}
- DELETE /hosts/{host:id}/unmanagednetworks/{unmanagednetwork:id}
- POST /hosts/{host:id}/unregisteredstoragedomainsdiscover
- POST /hosts/{host:id}/upgrade
- POST /hosts/{host:id}/upgradecheck
- GET /icons
- GET /icons/{icon:id}
- POST /imagetransfers
- GET /imagetransfers
- GET /imagetransfers/{imagetransfer:id}
- POST /imagetransfers/{imagetransfer:id}/cancel
- POST /imagetransfers/{imagetransfer:id}/extend
- POST /imagetransfers/{imagetransfer:id}/finalize
- POST /imagetransfers/{imagetransfer:id}/pause
- POST /imagetransfers/{imagetransfer:id}/resume
- POST /instancetypes
- GET /instancetypes
- GET /instancetypes/{instancetype:id}
- PUT /instancetypes/{instancetype:id}
- DELETE /instancetypes/{instancetype:id}
- POST /instancetypes/{instancetype:id}/graphicsconsoles
- GET /instancetypes/{instancetype:id}/graphicsconsoles
- GET /instancetypes/{instancetype:id}/graphicsconsoles/{console:id}
- DELETE /instancetypes/{instancetype:id}/graphicsconsoles/{console:id}
- POST /instancetypes/{instancetype:id}/nics
- GET /instancetypes/{instancetype:id}/nics
- GET /instancetypes/{instancetype:id}/nics/{nic:id}
- PUT /instancetypes/{instancetype:id}/nics/{nic:id}
- DELETE /instancetypes/{instancetype:id}/nics/{nic:id}
- POST /instancetypes/{instancetype:id}/watchdogs
- GET /instancetypes/{instancetype:id}/watchdogs
- GET /instancetypes/{instancetype:id}/watchdogs/{watchdog:id}
- PUT /instancetypes/{instancetype:id}/watchdogs/{watchdog:id}
- DELETE /instancetypes/{instancetype:id}/watchdogs/{watchdog:id}
- POST /jobs
- GET /jobs
- GET /jobs/{job:id}
- POST /jobs/{job:id}/clear
- POST /jobs/{job:id}/end
- POST /jobs/{job:id}/steps
- GET /jobs/{job:id}/steps
- GET /jobs/{job:id}/steps/{step:id}
- POST /jobs/{job:id}/steps/{step:id}/end
- GET /jobs/{job:id}/steps/{step:id}/statistics
- GET /jobs/{job:id}/steps/{step:id}/statistics/{statistic:id}
- GET /katelloerrata
- GET /katelloerrata/{katelloerratum:id}
- POST /macpools
- GET /macpools
- GET /macpools/{macpool:id}
- PUT /macpools/{macpool:id}
- DELETE /macpools/{macpool:id}
- GET /networkfilters
- GET /networkfilters/{networkfilter:id}
- POST /networks
- GET /networks
- GET /networks/{network:id}
- PUT /networks/{network:id}
- DELETE /networks/{network:id}
- POST /networks/{network:id}/networklabels
- GET /networks/{network:id}/networklabels
- GET /networks/{network:id}/networklabels/{label:id}
- DELETE /networks/{network:id}/networklabels/{label:id}
- POST /networks/{network:id}/permissions
- GET /networks/{network:id}/permissions
- GET /networks/{network:id}/permissions/{permission:id}
- DELETE /networks/{network:id}/permissions/{permission:id}
- POST /networks/{network:id}/vnicprofiles
- GET /networks/{network:id}/vnicprofiles
- GET /networks/{network:id}/vnicprofiles/{profile:id}
- DELETE /networks/{network:id}/vnicprofiles/{profile:id}
- POST /networks/{network:id}/vnicprofiles/{profile:id}/permissions
- GET /networks/{network:id}/vnicprofiles/{profile:id}/permissions
- GET /networks/{network:id}/vnicprofiles/{profile:id}/permissions/{permission:id}
- DELETE /networks/{network:id}/vnicprofiles/{profile:id}/permissions/{permission:id}
- POST /openstackimageproviders
- GET /openstackimageproviders
- GET /openstackimageproviders/{provider:id}
- PUT /openstackimageproviders/{provider:id}
- DELETE /openstackimageproviders/{provider:id}
- GET /openstackimageproviders/{provider:id}/certificates
- GET /openstackimageproviders/{provider:id}/certificates/{certificate:id}
- GET /openstackimageproviders/{provider:id}/images
- GET /openstackimageproviders/{provider:id}/images/{image:id}
- POST /openstackimageproviders/{provider:id}/images/{image:id}/import
- POST /openstackimageproviders/{provider:id}/importcertificates
- POST /openstackimageproviders/{provider:id}/testconnectivity
- POST /openstacknetworkproviders
- GET /openstacknetworkproviders
- GET /openstacknetworkproviders/{provider:id}
- PUT /openstacknetworkproviders/{provider:id}
- DELETE /openstacknetworkproviders/{provider:id}
- GET /openstacknetworkproviders/{provider:id}/certificates
- GET /openstacknetworkproviders/{provider:id}/certificates/{certificate:id}
- POST /openstacknetworkproviders/{provider:id}/importcertificates
- GET /openstacknetworkproviders/{provider:id}/networks
- GET /openstacknetworkproviders/{provider:id}/networks/{network:id}
- POST /openstacknetworkproviders/{provider:id}/networks/{network:id}/import
- POST /openstacknetworkproviders/{provider:id}/networks/{network:id}/subnets
- GET /openstacknetworkproviders/{provider:id}/networks/{network:id}/subnets
- GET /openstacknetworkproviders/{provider:id}/networks/{network:id}/subnets/{subnet:id}
- DELETE /openstacknetworkproviders/{provider:id}/networks/{network:id}/subnets/{subnet:id}
- POST /openstacknetworkproviders/{provider:id}/testconnectivity
- POST /openstackvolumeproviders
- GET /openstackvolumeproviders
- GET /openstackvolumeproviders/{provider:id}
- PUT /openstackvolumeproviders/{provider:id}
- DELETE /openstackvolumeproviders/{provider:id}
- POST /openstackvolumeproviders/{provider:id}/authenticationkeys
- GET /openstackvolumeproviders/{provider:id}/authenticationkeys
- GET /openstackvolumeproviders/{provider:id}/authenticationkeys/{key:id}
- PUT /openstackvolumeproviders/{provider:id}/authenticationkeys/{key:id}
- DELETE /openstackvolumeproviders/{provider:id}/authenticationkeys/{key:id}
- GET /openstackvolumeproviders/{provider:id}/certificates
- GET /openstackvolumeproviders/{provider:id}/certificates/{certificate:id}
- POST /openstackvolumeproviders/{provider:id}/importcertificates
- POST /openstackvolumeproviders/{provider:id}/testconnectivity
- GET /openstackvolumeproviders/{provider:id}/volumetypes
- GET /openstackvolumeproviders/{provider:id}/volumetypes/{type:id}
- GET /operatingsystems
- GET /operatingsystems/{operatingsystem:id}
- GET /options/{option:id}
- POST /permissions
- GET /permissions
- GET /permissions/{permission:id}
- DELETE /permissions/{permission:id}
- POST /roles
- GET /roles
- GET /roles/{role:id}
- DELETE /roles/{role:id}
- PUT /roles/{role:id}
- POST /roles/{role:id}/permits
- GET /roles/{role:id}/permits
- GET /roles/{role:id}/permits/{permit:id}
- DELETE /roles/{role:id}/permits/{permit:id}
- POST /schedulingpolicies
- GET /schedulingpolicies
- GET /schedulingpolicies/{policy:id}
- PUT /schedulingpolicies/{policy:id}
- DELETE /schedulingpolicies/{policy:id}
- POST /schedulingpolicies/{policy:id}/balances
- GET /schedulingpolicies/{policy:id}/balances
- GET /schedulingpolicies/{policy:id}/balances/{balance:id}
- DELETE /schedulingpolicies/{policy:id}/balances/{balance:id}
- POST /schedulingpolicies/{policy:id}/filters
- GET /schedulingpolicies/{policy:id}/filters
- GET /schedulingpolicies/{policy:id}/filters/{filter:id}
- DELETE /schedulingpolicies/{policy:id}/filters/{filter:id}
- POST /schedulingpolicies/{policy:id}/weights
- GET /schedulingpolicies/{policy:id}/weights
- GET /schedulingpolicies/{policy:id}/weights/{weight:id}
- DELETE /schedulingpolicies/{policy:id}/weights/{weight:id}
- GET /schedulingpolicyunits
- GET /schedulingpolicyunits/{unit:id}
- DELETE /schedulingpolicyunits/{unit:id}
- POST /storageconnections
- GET /storageconnections
- GET /storageconnections/{storageconnection:id}
- PUT /storageconnections/{storageconnection:id}
- DELETE /storageconnections/{storageconnection:id}
- POST /storagedomains
- GET /storagedomains
- GET /storagedomains/{storagedomain:id}
- PUT /storagedomains/{storagedomain:id}
- DELETE /storagedomains/{storagedomain:id}
- POST /storagedomains/{storagedomain:id}/diskprofiles
- GET /storagedomains/{storagedomain:id}/diskprofiles
- GET /storagedomains/{storagedomain:id}/diskprofiles/{profile:id}
- DELETE /storagedomains/{storagedomain:id}/diskprofiles/{profile:id}
- POST /storagedomains/{storagedomain:id}/disks
- GET /storagedomains/{storagedomain:id}/disks
- PUT /storagedomains/{storagedomain:id}/disks/{disk:id}
- GET /storagedomains/{storagedomain:id}/disks/{disk:id}
- DELETE /storagedomains/{storagedomain:id}/disks/{disk:id}
- POST /storagedomains/{storagedomain:id}/disks/{disk:id}/copy
- POST /storagedomains/{storagedomain:id}/disks/{disk:id}/export
- POST /storagedomains/{storagedomain:id}/disks/{disk:id}/move
- POST /storagedomains/{storagedomain:id}/disks/{disk:id}/permissions
- GET /storagedomains/{storagedomain:id}/disks/{disk:id}/permissions
- GET /storagedomains/{storagedomain:id}/disks/{disk:id}/permissions/{permission:id}
- DELETE /storagedomains/{storagedomain:id}/disks/{disk:id}/permissions/{permission:id}
- POST /storagedomains/{storagedomain:id}/disks/{disk:id}/reduce
- POST /storagedomains/{storagedomain:id}/disks/{disk:id}/sparsify
- GET /storagedomains/{storagedomain:id}/disks/{disk:id}/statistics
- GET /storagedomains/{storagedomain:id}/disks/{disk:id}/statistics/{statistic:id}
- GET /storagedomains/{storagedomain:id}/disksnapshots
- GET /storagedomains/{storagedomain:id}/disksnapshots/{snapshot:id}
- DELETE /storagedomains/{storagedomain:id}/disksnapshots/{snapshot:id}
- GET /storagedomains/{storagedomain:id}/files
- GET /storagedomains/{storagedomain:id}/files/{file:id}
- GET /storagedomains/{storagedomain:id}/images
- GET /storagedomains/{storagedomain:id}/images/{image:id}
- POST /storagedomains/{storagedomain:id}/images/{image:id}/import
- POST /storagedomains/{storagedomain:id}/isattached
- POST /storagedomains/{storagedomain:id}/permissions
- GET /storagedomains/{storagedomain:id}/permissions
- GET /storagedomains/{storagedomain:id}/permissions/{permission:id}
- DELETE /storagedomains/{storagedomain:id}/permissions/{permission:id}
- POST /storagedomains/{storagedomain:id}/reduceluns
- POST /storagedomains/{storagedomain:id}/refreshluns
- POST /storagedomains/{storagedomain:id}/storageconnections
- GET /storagedomains/{storagedomain:id}/storageconnections
- GET /storagedomains/{storagedomain:id}/storageconnections/{connection:id}
- DELETE /storagedomains/{storagedomain:id}/storageconnections/{connection:id}
- GET /storagedomains/{storagedomain:id}/templates
- GET /storagedomains/{storagedomain:id}/templates/{template:id}
- DELETE /storagedomains/{storagedomain:id}/templates/{template:id}
- GET /storagedomains/{storagedomain:id}/templates/{template:id}/disks
- GET /storagedomains/{storagedomain:id}/templates/{template:id}/disks/{disk:id}
- POST /storagedomains/{storagedomain:id}/templates/{template:id}/import
- POST /storagedomains/{storagedomain:id}/templates/{template:id}/register
- POST /storagedomains/{storagedomain:id}/updateovfstore
- GET /storagedomains/{storagedomain:id}/vms
- GET /storagedomains/{storagedomain:id}/vms/{vm:id}
- DELETE /storagedomains/{storagedomain:id}/vms/{vm:id}
- GET /storagedomains/{storagedomain:id}/vms/{vm:id}/diskattachments
- GET /storagedomains/{storagedomain:id}/vms/{vm:id}/diskattachments/{attachment:id}
- GET /storagedomains/{storagedomain:id}/vms/{vm:id}/disks
- GET /storagedomains/{storagedomain:id}/vms/{vm:id}/disks/{disk:id}
- POST /storagedomains/{storagedomain:id}/vms/{vm:id}/import
- POST /storagedomains/{storagedomain:id}/vms/{vm:id}/register
- POST /tags
- GET /tags
- GET /tags/{tag:id}
- PUT /tags/{tag:id}
- DELETE /tags/{tag:id}
- POST /templates
- GET /templates
- GET /templates/{template:id}
- PUT /templates/{template:id}
- DELETE /templates/{template:id}
- GET /templates/{template:id}/cdroms
- GET /templates/{template:id}/cdroms/{cdrom:id}
- GET /templates/{template:id}/diskattachments
- GET /templates/{template:id}/diskattachments/{attachment:id}
- DELETE /templates/{template:id}/diskattachments/{attachment:id}
- POST /templates/{template:id}/export
- POST /templates/{template:id}/graphicsconsoles
- GET /templates/{template:id}/graphicsconsoles
- GET /templates/{template:id}/graphicsconsoles/{console:id}
- DELETE /templates/{template:id}/graphicsconsoles/{console:id}
- POST /templates/{template:id}/nics
- GET /templates/{template:id}/nics
- GET /templates/{template:id}/nics/{nic:id}
- PUT /templates/{template:id}/nics/{nic:id}
- DELETE /templates/{template:id}/nics/{nic:id}
- POST /templates/{template:id}/permissions
- GET /templates/{template:id}/permissions
- GET /templates/{template:id}/permissions/{permission:id}
- DELETE /templates/{template:id}/permissions/{permission:id}
- POST /templates/{template:id}/tags
- GET /templates/{template:id}/tags
- GET /templates/{template:id}/tags/{tag:id}
- DELETE /templates/{template:id}/tags/{tag:id}
- POST /templates/{template:id}/watchdogs
- GET /templates/{template:id}/watchdogs
- GET /templates/{template:id}/watchdogs/{watchdog:id}
- PUT /templates/{template:id}/watchdogs/{watchdog:id}
- DELETE /templates/{template:id}/watchdogs/{watchdog:id}
- POST /users
- GET /users
- GET /users/{user:id}
- DELETE /users/{user:id}
- GET /users/{user:id}/groups
- POST /users/{user:id}/permissions
- GET /users/{user:id}/permissions
- GET /users/{user:id}/permissions/{permission:id}
- DELETE /users/{user:id}/permissions/{permission:id}
- GET /users/{user:id}/roles
- GET /users/{user:id}/roles/{role:id}
- DELETE /users/{user:id}/roles/{role:id}
- PUT /users/{user:id}/roles/{role:id}
- POST /users/{user:id}/roles/{role:id}/permits
- GET /users/{user:id}/roles/{role:id}/permits
- GET /users/{user:id}/roles/{role:id}/permits/{permit:id}
- DELETE /users/{user:id}/roles/{role:id}/permits/{permit:id}
- POST /users/{user:id}/sshpublickeys
- GET /users/{user:id}/sshpublickeys
- GET /users/{user:id}/sshpublickeys/{key:id}
- PUT /users/{user:id}/sshpublickeys/{key:id}
- DELETE /users/{user:id}/sshpublickeys/{key:id}
- POST /users/{user:id}/tags
- GET /users/{user:id}/tags
- GET /users/{user:id}/tags/{tag:id}
- DELETE /users/{user:id}/tags/{tag:id}
- POST /vmpools
- GET /vmpools
- GET /vmpools/{pool:id}
- PUT /vmpools/{pool:id}
- DELETE /vmpools/{pool:id}
- POST /vmpools/{pool:id}/allocatevm
- POST /vmpools/{pool:id}/permissions
- GET /vmpools/{pool:id}/permissions
- GET /vmpools/{pool:id}/permissions/{permission:id}
- DELETE /vmpools/{pool:id}/permissions/{permission:id}
- POST /vms
- GET /vms
- GET /vms/{vm:id}
- PUT /vms/{vm:id}
- DELETE /vms/{vm:id}
- POST /vms/{vm:id}/affinitylabels
- GET /vms/{vm:id}/affinitylabels
- GET /vms/{vm:id}/affinitylabels/{label:id}
- DELETE /vms/{vm:id}/affinitylabels/{label:id}
- GET /vms/{vm:id}/applications
- GET /vms/{vm:id}/applications/{application:id}
- POST /vms/{vm:id}/cancelmigration
- POST /vms/{vm:id}/cdroms
- GET /vms/{vm:id}/cdroms
- GET /vms/{vm:id}/cdroms/{cdrom:id}
- PUT /vms/{vm:id}/cdroms/{cdrom:id}
- POST /vms/{vm:id}/clone
- POST /vms/{vm:id}/commitsnapshot
- POST /vms/{vm:id}/detach
- POST /vms/{vm:id}/diskattachments
- GET /vms/{vm:id}/diskattachments
- GET /vms/{vm:id}/diskattachments/{attachment:id}
- DELETE /vms/{vm:id}/diskattachments/{attachment:id}
- PUT /vms/{vm:id}/diskattachments/{attachment:id}
- POST /vms/{vm:id}/export
- POST /vms/{vm:id}/freezefilesystems
- POST /vms/{vm:id}/graphicsconsoles
- GET /vms/{vm:id}/graphicsconsoles
- GET /vms/{vm:id}/graphicsconsoles/{console:id}
- DELETE /vms/{vm:id}/graphicsconsoles/{console:id}
- POST /vms/{vm:id}/graphicsconsoles/{console:id}/proxyticket
- POST /vms/{vm:id}/graphicsconsoles/{console:id}/remoteviewerconnectionfile
- POST /vms/{vm:id}/graphicsconsoles/{console:id}/ticket
- POST /vms/{vm:id}/hostdevices
- GET /vms/{vm:id}/hostdevices
- GET /vms/{vm:id}/hostdevices/{device:id}
- DELETE /vms/{vm:id}/hostdevices/{device:id}
- GET /vms/{vm:id}/katelloerrata
- GET /vms/{vm:id}/katelloerrata/{katelloerratum:id}
- POST /vms/{vm:id}/logon
- POST /vms/{vm:id}/maintenance
- POST /vms/{vm:id}/migrate
- POST /vms/{vm:id}/nics
- GET /vms/{vm:id}/nics
- GET /vms/{vm:id}/nics/{nic:id}
- PUT /vms/{vm:id}/nics/{nic:id}
- DELETE /vms/{vm:id}/nics/{nic:id}
- POST /vms/{vm:id}/nics/{nic:id}/activate
- POST /vms/{vm:id}/nics/{nic:id}/deactivate
- GET /vms/{vm:id}/nics/{nic:id}/networkfilterparameters
- POST /vms/{vm:id}/nics/{nic:id}/networkfilterparameters
- GET /vms/{vm:id}/nics/{nic:id}/networkfilterparameters/{parameter:id}
- PUT /vms/{vm:id}/nics/{nic:id}/networkfilterparameters/{parameter:id}
- DELETE /vms/{vm:id}/nics/{nic:id}/networkfilterparameters/{parameter:id}
- GET /vms/{vm:id}/nics/{nic:id}/reporteddevices
- GET /vms/{vm:id}/nics/{nic:id}/reporteddevices/{reporteddevice:id}
- GET /vms/{vm:id}/nics/{nic:id}/statistics
- GET /vms/{vm:id}/nics/{nic:id}/statistics/{statistic:id}
- POST /vms/{vm:id}/numanodes
- GET /vms/{vm:id}/numanodes
- GET /vms/{vm:id}/numanodes/{node:id}
- PUT /vms/{vm:id}/numanodes/{node:id}
- DELETE /vms/{vm:id}/numanodes/{node:id}
- POST /vms/{vm:id}/permissions
- GET /vms/{vm:id}/permissions
- GET /vms/{vm:id}/permissions/{permission:id}
- DELETE /vms/{vm:id}/permissions/{permission:id}
- POST /vms/{vm:id}/previewsnapshot
- POST /vms/{vm:id}/reboot
- POST /vms/{vm:id}/reordermacaddresses
- GET /vms/{vm:id}/reporteddevices
- GET /vms/{vm:id}/reporteddevices/{reporteddevice:id}
- GET /vms/{vm:id}/sessions
- GET /vms/{vm:id}/sessions/{session:id}
- POST /vms/{vm:id}/shutdown
- POST /vms/{vm:id}/snapshots
- GET /vms/{vm:id}/snapshots
- GET /vms/{vm:id}/snapshots/{snapshot:id}
- DELETE /vms/{vm:id}/snapshots/{snapshot:id}
- GET /vms/{vm:id}/snapshots/{snapshot:id}/cdroms
- GET /vms/{vm:id}/snapshots/{snapshot:id}/cdroms/{cdrom:id}
- GET /vms/{vm:id}/snapshots/{snapshot:id}/disks
- GET /vms/{vm:id}/snapshots/{snapshot:id}/disks/{disk:id}
- GET /vms/{vm:id}/snapshots/{snapshot:id}/nics
- GET /vms/{vm:id}/snapshots/{snapshot:id}/nics/{nic:id}
- POST /vms/{vm:id}/snapshots/{snapshot:id}/restore
- POST /vms/{vm:id}/start
- GET /vms/{vm:id}/statistics
- GET /vms/{vm:id}/statistics/{statistic:id}
- POST /vms/{vm:id}/stop
- POST /vms/{vm:id}/suspend
- POST /vms/{vm:id}/tags
- GET /vms/{vm:id}/tags
- GET /vms/{vm:id}/tags/{tag:id}
- DELETE /vms/{vm:id}/tags/{tag:id}
- POST /vms/{vm:id}/thawfilesystems
- POST /vms/{vm:id}/ticket
- POST /vms/{vm:id}/undosnapshot
- POST /vms/{vm:id}/watchdogs
- GET /vms/{vm:id}/watchdogs
- GET /vms/{vm:id}/watchdogs/{watchdog:id}
- PUT /vms/{vm:id}/watchdogs/{watchdog:id}
- DELETE /vms/{vm:id}/watchdogs/{watchdog:id}
- POST /vnicprofiles
- GET /vnicprofiles
- GET /vnicprofiles/{profile:id}
- PUT /vnicprofiles/{profile:id}
- DELETE /vnicprofiles/{profile:id}
- POST /vnicprofiles/{profile:id}/permissions
- GET /vnicprofiles/{profile:id}/permissions
- GET /vnicprofiles/{profile:id}/permissions/{permission:id}
- DELETE /vnicprofiles/{profile:id}/permissions/{permission:id}
Chapter 6. Services
This section enumerates all the services that are available in the API.
6.1. AffinityGroup
This service manages a single affinity group.
Table 6.1. Methods summary
Name | Summary |
---|---|
| Retrieve the affinity group details. |
| Remove the affinity group. |
| Update the affinity group. |
6.1.1. get GET
Retrieve the affinity group details.
<affinity_group id="00000000-0000-0000-0000-000000000000"> <name>AF_GROUP_001</name> <cluster id="00000000-0000-0000-0000-000000000000"/> <positive>true</positive> <enforcing>true</enforcing> </affinity_group>
Table 6.2. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out | The affinity group. |
6.1.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.1.2. remove DELETE
Remove the affinity group.
DELETE /ovirt-engine/api/clusters/000-000/affinitygroups/123-456
Table 6.3. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the removal should be performed asynchronously. |
6.1.3. update PUT
Update the affinity group.
Table 6.4. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the update should be performed asynchronously. | |
| In/Out | The affinity group. |
6.2. AffinityGroupVm
This service manages a single virtual machine to affinity group assignment.
Table 6.5. Methods summary
Name | Summary |
---|---|
| Remove this virtual machine from the affinity group. |
6.2.1. remove DELETE
Remove this virtual machine from the affinity group.
Table 6.6. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the removal should be performed asynchronously. |
6.3. AffinityGroupVms
This service manages a collection of all the virtual machines assigned to an affinity group.
Table 6.7. Methods summary
Name | Summary |
---|---|
| Adds a virtual machine to the affinity group. |
| List all virtual machines assigned to this affinity group. |
6.3.1. add POST
Adds a virtual machine to the affinity group.
For example, to add the virtual machine 789
to the affinity group 456
of cluster 123
, send a request like this:
POST /ovirt-engine/api/clusters/123/affinitygroups/456/vms
With the following body:
<vm id="789"/>
Table 6.8. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.3.2. list GET
List all virtual machines assigned to this affinity group.
The order of the returned virtual machines isn’t guaranteed.
Table 6.9. Parameters summary
6.3.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.3.2.2. max
Sets the maximum number of virtual machines to return. If not specified, all the virtual machines are returned.
6.4. AffinityGroups
The affinity groups service manages virtual machine relationships and dependencies.
Table 6.10. Methods summary
Name | Summary |
---|---|
| Create a new affinity group. |
| List existing affinity groups. |
6.4.1. add POST
Create a new affinity group.
Post a request like in the example below to create a new affinity group:
POST /ovirt-engine/api/clusters/000-000/affinitygroups
And use the following example in its body:
<affinity_group> <name>AF_GROUP_001</name> <hosts_rule> <enforcing>true</enforcing> <positive>true</positive> </hosts_rule> <vms_rule> <enabled>false</enabled> </vms_rule> </affinity_group>
Table 6.11. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The affinity group object to create. |
6.4.2. list GET
List existing affinity groups.
The order of the affinity groups results isn’t guaranteed.
Table 6.12. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out | The list of existing affinity groups. | |
| In | Sets the maximum number of affinity groups to return. |
6.4.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.4.2.2. max
Sets the maximum number of affinity groups to return. If not specified all the affinity groups are returned.
6.5. AffinityLabel
The details of a single affinity label.
Table 6.13. Methods summary
Name | Summary |
---|---|
| Retrieves the details of a label. |
| Removes a label from the system and clears all assignments of the removed label. |
| Updates a label. |
6.5.1. get GET
Retrieves the details of a label.
Table 6.14. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.5.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.5.2. remove DELETE
Removes a label from the system and clears all assignments of the removed label.
6.5.3. update PUT
Updates a label. This call will update all metadata, such as the name or description.
Table 6.15. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.6. AffinityLabelHost
This service represents a host that has a specific label when accessed through the affinitylabels/hosts subcollection.
Table 6.16. Methods summary
Name | Summary |
---|---|
| Retrieves details about a host that has this label assigned. |
| Remove a label from a host. |
6.6.1. get GET
Retrieves details about a host that has this label assigned.
Table 6.17. Parameters summary
6.6.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.6.2. remove DELETE
Remove a label from a host.
6.7. AffinityLabelHosts
This service represents list of hosts that have a specific label when accessed through the affinitylabels/hosts subcollection.
Table 6.18. Methods summary
Name | Summary |
---|---|
| Add a label to a host. |
| List all hosts with the label. |
6.7.1. add POST
Add a label to a host.
Table 6.19. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.7.2. list GET
List all hosts with the label.
The order of the returned hosts isn’t guaranteed.
Table 6.20. Parameters summary
6.7.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.8. AffinityLabelVm
This service represents a vm that has a specific label when accessed through the affinitylabels/vms subcollection.
Table 6.21. Methods summary
Name | Summary |
---|---|
| Retrieves details about a vm that has this label assigned. |
| Remove a label from a vm. |
6.8.1. get GET
Retrieves details about a vm that has this label assigned.
Table 6.22. Parameters summary
6.8.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.8.2. remove DELETE
Remove a label from a vm.
6.9. AffinityLabelVms
This service represents list of vms that have a specific label when accessed through the affinitylabels/vms subcollection.
Table 6.23. Methods summary
Name | Summary |
---|---|
| Add a label to a vm. |
| List all virtual machines with the label. |
6.9.1. add POST
Add a label to a vm.
Table 6.24. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.9.2. list GET
List all virtual machines with the label.
The order of the returned virtual machines isn’t guaranteed.
Table 6.25. Parameters summary
6.9.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.10. AffinityLabels
Manages the affinity labels available in the system.
Table 6.26. Methods summary
Name | Summary |
---|---|
| Creates a new label. |
| Lists all labels present in the system. |
6.10.1. add POST
Creates a new label. The label is automatically attached to all entities mentioned in the vms or hosts lists.
Table 6.27. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.10.2. list GET
Lists all labels present in the system.
The order of the returned labels isn’t guaranteed.
Table 6.28. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out | ||
| In | Sets the maximum number of labels to return. |
6.10.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.10.2.2. max
Sets the maximum number of labels to return. If not specified all the labels are returned.
6.11. Area
This annotation is intended to specify what oVirt area is the annotated concept related to. Currently the following areas are in use, and they are closely related to the oVirt teams, but not necessarily the same:
- Infrastructure
- Network
- SLA
- Storage
- Virtualization
A concept may be associated to more than one area, or to no area.
The value of this annotation is intended for reporting only, and it doesn’t affect at all the generated code or the validity of the model
6.12. AssignedAffinityLabel
This service represents one label to entity assignment when accessed using the entities/affinitylabels subcollection.
Table 6.29. Methods summary
Name | Summary |
---|---|
| Retrieves details about the attached label. |
| Removes the label from an entity. |
6.12.1. get GET
Retrieves details about the attached label.
Table 6.30. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.12.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.12.2. remove DELETE
Removes the label from an entity. Does not touch the label itself.
6.13. AssignedAffinityLabels
This service is used to list and manipulate affinity labels that are assigned to supported entities when accessed using entities/affinitylabels.
Table 6.31. Methods summary
Name | Summary |
---|---|
| Attaches a label to an entity. |
| Lists all labels that are attached to an entity. |
6.13.1. add POST
Attaches a label to an entity.
Table 6.32. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.13.2. list GET
Lists all labels that are attached to an entity.
The order of the returned entities isn’t guaranteed.
Table 6.33. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.13.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.14. AssignedCpuProfile
Table 6.34. Methods summary
Name | Summary |
---|---|
| |
|
6.14.1. get GET
Table 6.35. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.14.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.14.2. remove DELETE
Table 6.36. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.15. AssignedCpuProfiles
Table 6.37. Methods summary
Name | Summary |
---|---|
| Add a new cpu profile for the cluster. |
| List the CPU profiles assigned to the cluster. |
6.15.1. add POST
Add a new cpu profile for the cluster.
Table 6.38. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.15.2. list GET
List the CPU profiles assigned to the cluster.
The order of the returned CPU profiles isn’t guaranteed.
Table 6.39. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| In | Sets the maximum number of profiles to return. | |
| Out |
6.15.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.15.2.2. max
Sets the maximum number of profiles to return. If not specified all the profiles are returned.
6.16. AssignedDiskProfile
Table 6.40. Methods summary
Name | Summary |
---|---|
| |
|
6.16.1. get GET
Table 6.41. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| Out | ||
| In | Indicates which inner links should be followed. |
6.16.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.16.2. remove DELETE
Table 6.42. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.17. AssignedDiskProfiles
Table 6.43. Methods summary
Name | Summary |
---|---|
| Add a new disk profile for the storage domain. |
| Returns the list of disk profiles assigned to the storage domain. |
6.17.1. add POST
Add a new disk profile for the storage domain.
Table 6.44. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.17.2. list GET
Returns the list of disk profiles assigned to the storage domain.
The order of the returned disk profiles isn’t guaranteed.
Table 6.45. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| In | Sets the maximum number of profiles to return. | |
| Out |
6.17.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.17.2.2. max
Sets the maximum number of profiles to return. If not specified all the profiles are returned.
6.18. AssignedPermissions
Represents a permission sub-collection, scoped by user, group or some entity type.
Table 6.46. Methods summary
Name | Summary |
---|---|
| Assign a new permission to a user or group for specific entity. |
| List all the permissions of the specific entity. |
6.18.1. add POST
Assign a new permission to a user or group for specific entity.
For example, to assign the UserVmManager
role to the virtual machine with id 123
to the user with id 456
send a request like this:
POST /ovirt-engine/api/vms/123/permissions
With a request body like this:
<permission> <role> <name>UserVmManager</name> </role> <user id="456"/> </permission>
To assign the SuperUser
role to the system to the user with id 456
send a request like this:
POST /ovirt-engine/api/permissions
With a request body like this:
<permission> <role> <name>SuperUser</name> </role> <user id="456"/> </permission>
If you want to assign permission to the group instead of the user please replace the user
element with the group
element with proper id
of the group. For example to assign the UserRole
role to the cluster with id 123
to the group with id 789
send a request like this:
POST /ovirt-engine/api/clusters/123/permissions
With a request body like this:
<permission> <role> <name>UserRole</name> </role> <group id="789"/> </permission>
Table 6.47. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The permission. |
6.18.2. list GET
List all the permissions of the specific entity.
For example to list all the permissions of the cluster with id 123
send a request like this:
GET /ovirt-engine/api/clusters/123/permissions
<permissions> <permission id="456"> <cluster id="123"/> <role id="789"/> <user id="451"/> </permission> <permission id="654"> <cluster id="123"/> <role id="789"/> <group id="127"/> </permission> </permissions>
The order of the returned permissions isn’t guaranteed.
Table 6.48. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out | The list of permissions. |
6.18.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.19. AssignedRoles
Represents a roles sub-collection, for example scoped by user.
Table 6.49. Methods summary
Name | Summary |
---|---|
| Returns the roles assigned to the permission. |
6.19.1. list GET
Returns the roles assigned to the permission.
The order of the returned roles isn’t guaranteed.
Table 6.50. Parameters summary
6.19.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.19.1.2. max
Sets the maximum number of roles to return. If not specified all the roles are returned.
6.20. AssignedTag
A service to manage assignment of specific tag to specific entities in system.
Table 6.51. Methods summary
Name | Summary |
---|---|
| Gets the information about the assigned tag. |
| Unassign tag from specific entity in the system. |
6.20.1. get GET
Gets the information about the assigned tag.
For example to retrieve the information about the tag with the id 456
which is assigned to virtual machine with id 123
send a request like this:
GET /ovirt-engine/api/vms/123/tags/456
<tag href="/ovirt-engine/api/tags/456" id="456"> <name>root</name> <description>root</description> <vm href="/ovirt-engine/api/vms/123" id="123"/> </tag>
Table 6.52. Parameters summary
6.20.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.20.2. remove DELETE
Unassign tag from specific entity in the system.
For example to unassign the tag with id 456
from virtual machine with id 123
send a request like this:
DELETE /ovirt-engine/api/vms/123/tags/456
Table 6.53. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.21. AssignedTags
A service to manage collection of assignment of tags to specific entities in system.
Table 6.54. Methods summary
Name | Summary |
---|---|
| Assign tag to specific entity in the system. |
| List all tags assigned to the specific entity. |
6.21.1. add POST
Assign tag to specific entity in the system.
For example to assign tag mytag
to virtual machine with the id 123
send a request like this:
POST /ovirt-engine/api/vms/123/tags
With a request body like this:
<tag> <name>mytag</name> </tag>
Table 6.55. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The assigned tag. |
6.21.2. list GET
List all tags assigned to the specific entity.
For example to list all the tags of the virtual machine with id 123
send a request like this:
GET /ovirt-engine/api/vms/123/tags
<tags> <tag href="/ovirt-engine/api/tags/222" id="222"> <name>mytag</name> <description>mytag</description> <vm href="/ovirt-engine/api/vms/123" id="123"/> </tag> </tags>
The order of the returned tags isn’t guaranteed.
Table 6.56. Parameters summary
6.21.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.21.2.2. max
Sets the maximum number of tags to return. If not specified all the tags are returned.
6.22. AssignedVnicProfile
Table 6.57. Methods summary
Name | Summary |
---|---|
| |
|
6.22.1. get GET
Table 6.58. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.22.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.22.2. remove DELETE
Table 6.59. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.23. AssignedVnicProfiles
Table 6.60. Methods summary
Name | Summary |
---|---|
| Add a new virtual network interface card profile for the network. |
| Returns the list of VNIC profiles assifned to the network. |
6.23.1. add POST
Add a new virtual network interface card profile for the network.
Table 6.61. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.23.2. list GET
Returns the list of VNIC profiles assifned to the network.
The order of the returned VNIC profiles isn’t guaranteed.
Table 6.62. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| In | Sets the maximum number of profiles to return. | |
| Out |
6.23.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.23.2.2. max
Sets the maximum number of profiles to return. If not specified all the profiles are returned.
6.24. AttachedStorageDomain
Table 6.63. Methods summary
Name | Summary |
---|---|
| This operation activates an attached storage domain. |
| This operation deactivates an attached storage domain. |
| |
|
6.24.1. activate POST
This operation activates an attached storage domain. Once the storage domain is activated it is ready for use with the data center.
POST /ovirt-engine/api/datacenters/123/storagedomains/456/activate
The activate action does not take any action specific parameters, so the request body should contain an empty action
:
<action/>
Table 6.64. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the activation should be performed asynchronously. |
6.24.2. deactivate POST
This operation deactivates an attached storage domain. Once the storage domain is deactivated it will not be used with the data center. For example, to deactivate storage domain 456
, send the following request:
POST /ovirt-engine/api/datacenters/123/storagedomains/456/deactivate
With a request body like this:
<action/>
If the force
parameter is true
then the operation will succeed, even if the OVF update which takes place before the deactivation of the storage domain failed. If the force
parameter is false
and the OVF update failed, the deactivation of the storage domain will also fail.
Table 6.65. Parameters summary
6.24.2.1. force
Indicates if the operation should succeed and the storage domain should be moved to a deactivated state, even if the OVF update for the storage domain failed. For example, to deactivate storage domain 456
using force flag, send the following request:
POST /ovirt-engine/api/datacenters/123/storagedomains/456/deactivate
With a request body like this:
<action> <force>true</force> <action>
This parameter is optional, and the default value is false
.
6.24.3. get GET
Table 6.66. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.24.3.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.24.4. remove DELETE
Table 6.67. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.25. AttachedStorageDomainDisk
Manages a single disk available in a storage domain attached to a data center.
Since version 4.2 of the engine this service is intended only to list disks available in the storage domain, and to register unregistered disks. All the other operations, like copying a disk, moving a disk, etc, have been deprecated and will be removed in the future. To perform those operations use the service that manages all the disks of the system, or the service that manages an specific disk.
Table 6.68. Methods summary
Name | Summary |
---|---|
| Copies a disk to the specified storage domain. |
| Exports a disk to an export storage domain. |
| Retrieves the description of the disk. |
| Moves a disk to another storage domain. |
| Registers an unregistered disk. |
| Removes a disk. |
| Sparsify the disk. |
| Updates the disk. |
6.25.1. copy POST
Copies a disk to the specified storage domain.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To copy a disk use the copy operation of the service that manages that disk.
Table 6.69. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Description of the resulting disk. | |
| In | The storage domain where the new disk will be created. |
6.25.2. export POST
Exports a disk to an export storage domain.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To export a disk use the export operation of the service that manages that disk.
Table 6.70. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | The export storage domain where the disk should be exported to. |
6.25.3. get GET
Retrieves the description of the disk.
Table 6.71. Parameters summary
6.25.3.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.25.4. move POST
Moves a disk to another storage domain.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To move a disk use the move operation of the service that manages that disk.
Table 6.72. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the move should be performed asynchronously. | |
| In | Indicates if the results should be filtered according to the permissions of the user. | |
| In | The storage domain where the disk will be moved to. |
6.25.5. register POST
Registers an unregistered disk.
6.25.6. remove DELETE
Removes a disk.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To remove a disk use the remove operation of the service that manages that disk.
6.25.7. sparsify POST
Sparsify the disk.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To remove a disk use the remove operation of the service that manages that disk.
6.25.8. update PUT
Updates the disk.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To update a disk use the update operation of the service that manages that disk.
Table 6.73. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The update to apply to the disk. |
6.26. AttachedStorageDomainDisks
Manages the collection of disks available inside an storage domain that is attached to a data center.
Table 6.74. Methods summary
Name | Summary |
---|---|
| Adds or registers a disk. |
| Retrieve the list of disks that are available in the storage domain. |
6.26.1. add POST
Adds or registers a disk.
Since version 4.2 of the engine this operation is deprecated, and preserved only for backwards compatibility. It will be removed in the future. To add a new disk use the add operation of the service that manages the disks of the system. To register an unregistered disk use the register operation of the service that manages that disk.
Table 6.75. Parameters summary
6.26.1.1. unregistered
Indicates if a new disk should be added or if an existing unregistered disk should be registered. If the value is true
then the identifier of the disk to register needs to be provided. For example, to register the disk with id 456
send a request like this:
POST /ovirt-engine/api/storagedomains/123/disks?unregistered=true
With a request body like this:
<disk id="456"/>
If the value is false
then a new disk will be created in the storage domain. In that case the provisioned_size
, format
and name
attributes are mandatory. For example, to create a new copy on write disk of 1 GiB, send a request like this:
POST /ovirt-engine/api/storagedomains/123/disks
With a request body like this:
<disk> <name>mydisk</name> <format>cow</format> <provisioned_size>1073741824</provisioned_size> </disk>
The default value is false
.
6.26.2. list GET
Retrieve the list of disks that are available in the storage domain.
Table 6.76. Parameters summary
6.26.2.1. disks
List of retrieved disks.
The order of the returned disks isn’t guaranteed.
6.26.2.2. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.26.2.3. max
Sets the maximum number of disks to return. If not specified all the disks are returned.
6.27. AttachedStorageDomains
Manages the storage domains attached to a data center.
Table 6.77. Methods summary
Name | Summary |
---|---|
| Attaches an existing storage domain to the data center. |
| Returns the list of storage domains attached to the data center. |
6.27.1. add POST
Attaches an existing storage domain to the data center.
Table 6.78. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The storage domain to attach to the data center. |
6.27.2. list GET
Returns the list of storage domains attached to the data center.
The order of the returned storage domains isn’t guaranteed.
Table 6.79. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| In | Sets the maximum number of storage domains to return. | |
| Out | A list of storage domains that are attached to the data center. |
6.27.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.27.2.2. max
Sets the maximum number of storage domains to return. If not specified all the storage domains are returned.
6.28. Balance
Table 6.80. Methods summary
Name | Summary |
---|---|
| |
|
6.28.1. get GET
Table 6.81. Parameters summary
6.28.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.28.2. remove DELETE
Table 6.82. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.29. Balances
Table 6.83. Methods summary
Name | Summary |
---|---|
| Add a balance module to a specified user defined scheduling policy. |
| Returns the list of balance modules used by the scheduling policy. |
6.29.1. add POST
Add a balance module to a specified user defined scheduling policy.
Table 6.84. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.29.2. list GET
Returns the list of balance modules used by the scheduling policy.
The order of the returned balance modules isn’t guaranteed.
Table 6.85. Parameters summary
6.29.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.29.2.2. max
Sets the maximum number of balances to return. If not specified all the balances are returned.
6.30. Bookmark
A service to manage a bookmark.
Table 6.86. Methods summary
Name | Summary |
---|---|
| Get a bookmark. |
| Remove a bookmark. |
| Update a bookmark. |
6.30.1. get GET
Get a bookmark.
An example for getting a bookmark:
GET /ovirt-engine/api/bookmarks/123
<bookmark href="/ovirt-engine/api/bookmarks/123" id="123"> <name>example_vm</name> <value>vm: name=example*</value> </bookmark>
Table 6.87. Parameters summary
6.30.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.30.2. remove DELETE
Remove a bookmark.
An example for removing a bookmark:
DELETE /ovirt-engine/api/bookmarks/123
Table 6.88. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.30.3. update PUT
Update a bookmark.
An example for updating a bookmark:
PUT /ovirt-engine/api/bookmarks/123
With the request body:
<bookmark> <name>new_example_vm</name> <value>vm: name=new_example*</value> </bookmark>
6.31. Bookmarks
A service to manage bookmarks.
Table 6.90. Methods summary
Name | Summary |
---|---|
| Adding a new bookmark. |
| Listing all the available bookmarks. |
6.31.1. add POST
Adding a new bookmark.
Example of adding a bookmark:
POST /ovirt-engine/api/bookmarks
<bookmark> <name>new_example_vm</name> <value>vm: name=new_example*</value> </bookmark>
Table 6.91. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The added bookmark. |
6.31.2. list GET
Listing all the available bookmarks.
Example of listing bookmarks:
GET /ovirt-engine/api/bookmarks
<bookmarks> <bookmark href="/ovirt-engine/api/bookmarks/123" id="123"> <name>database</name> <value>vm: name=database*</value> </bookmark> <bookmark href="/ovirt-engine/api/bookmarks/456" id="456"> <name>example</name> <value>vm: name=example*</value> </bookmark> </bookmarks>
The order of the returned bookmarks isn’t guaranteed.
Table 6.92. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| Out | The list of available bookmarks. | |
| In | Indicates which inner links should be followed. | |
| In | Sets the maximum number of bookmarks to return. |
6.31.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.31.2.2. max
Sets the maximum number of bookmarks to return. If not specified all the bookmarks are returned.
6.32. Cluster
A service to manage a specific cluster.
Table 6.93. Methods summary
Name | Summary |
---|---|
| Gets information about the cluster. |
| Removes the cluster from the system. |
| |
| Synchronizes all networks on the cluster. |
| Updates information about the cluster. |
6.32.1. get GET
Gets information about the cluster.
An example of getting a cluster:
GET /ovirt-engine/api/clusters/123
<cluster href="/ovirt-engine/api/clusters/123" id="123"> <actions> <link href="/ovirt-engine/api/clusters/123/resetemulatedmachine" rel="resetemulatedmachine"/> </actions> <name>Default</name> <description>The default server cluster</description> <link href="/ovirt-engine/api/clusters/123/networks" rel="networks"/> <link href="/ovirt-engine/api/clusters/123/permissions" rel="permissions"/> <link href="/ovirt-engine/api/clusters/123/glustervolumes" rel="glustervolumes"/> <link href="/ovirt-engine/api/clusters/123/glusterhooks" rel="glusterhooks"/> <link href="/ovirt-engine/api/clusters/123/affinitygroups" rel="affinitygroups"/> <link href="/ovirt-engine/api/clusters/123/cpuprofiles" rel="cpuprofiles"/> <ballooning_enabled>false</ballooning_enabled> <cpu> <architecture>x86_64</architecture> <type>Intel Penryn Family</type> </cpu> <error_handling> <on_error>migrate</on_error> </error_handling> <fencing_policy> <enabled>true</enabled> <skip_if_connectivity_broken> <enabled>false</enabled> <threshold>50</threshold> </skip_if_connectivity_broken> <skip_if_sd_active> <enabled>false</enabled> </skip_if_sd_active> </fencing_policy> <gluster_service>false</gluster_service> <ha_reservation>false</ha_reservation> <ksm> <enabled>true</enabled> <merge_across_nodes>true</merge_across_nodes> </ksm> <maintenance_reason_required>false</maintenance_reason_required> <memory_policy> <over_commit> <percent>100</percent> </over_commit> <transparent_hugepages> <enabled>true</enabled> </transparent_hugepages> </memory_policy> <migration> <auto_converge>inherit</auto_converge> <bandwidth> <assignment_method>auto</assignment_method> </bandwidth> <compressed>inherit</compressed> </migration> <optional_reason>false</optional_reason> <required_rng_sources> <required_rng_source>random</required_rng_source> </required_rng_sources> <scheduling_policy href="/ovirt-engine/api/schedulingpolicies/456" id="456"/> <threads_as_cores>false</threads_as_cores> <trusted_service>false</trusted_service> <tunnel_migration>false</tunnel_migration> <version> <major>4</major> <minor>0</minor> </version> <virt_service>true</virt_service> <data_center href="/ovirt-engine/api/datacenters/111" id="111"/> </cluster>
Table 6.94. Parameters summary
6.32.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.32.2. remove DELETE
Removes the cluster from the system.
DELETE /ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000
Table 6.95. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the remove should be performed asynchronously. |
6.32.3. resetemulatedmachine POST
Table 6.96. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the reset should be performed asynchronously. |
6.32.4. syncallnetworks POST
Synchronizes all networks on the cluster.
POST /ovirt-engine/api/clusters/123/syncallnetworks
With a request body like this:
<action/>
Table 6.97. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates if the action should be performed asynchronously. |
6.32.5. update PUT
Updates information about the cluster.
Only the specified fields are updated; others remain unchanged.
For example, to update the cluster’s CPU:
PUT /ovirt-engine/api/clusters/123
With a request body like this:
<cluster> <cpu> <type>Intel Haswell-noTSX Family</type> </cpu> </cluster>
6.33. ClusterEnabledFeature
Represents a feature enabled for the cluster.
Table 6.99. Methods summary
Name | Summary |
---|---|
| Provides the information about the cluster feature enabled. |
| Disables a cluster feature. |
6.33.1. get GET
Provides the information about the cluster feature enabled.
For example, to find details of the enabled feature 456
for cluster 123
, send a request like this:
GET /ovirt-engine/api/clusters/123/enabledfeatures/456
That will return a ClusterFeature object containing the name:
<cluster_feature id="456"> <name>libgfapi_supported</name> </cluster_feature>
Table 6.100. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| Out | Retrieved cluster feature that’s enabled. | |
| In | Indicates which inner links should be followed. |
6.33.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.33.2. remove DELETE
Disables a cluster feature.
For example, to disable the feature 456
of cluster 123
send a request like this:
DELETE /ovirt-engine/api/clusters/123/enabledfeatures/456
6.34. ClusterEnabledFeatures
Provides information about the additional features that are enabled for this cluster. The features that are enabled are the available features for the cluster level
Table 6.101. Methods summary
Name | Summary |
---|---|
| Enable an additional feature for a cluster. |
| Lists the additional features enabled for the cluster. |
6.34.1. add POST
Enable an additional feature for a cluster.
For example, to enable a feature 456
on cluster 123
, send a request like this:
POST /ovirt-engine/api/clusters/123/enabledfeatures
The request body should look like this:
<cluster_feature id="456"/>
Table 6.102. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out |
6.34.2. list GET
Lists the additional features enabled for the cluster.
For example, to get the features enabled for cluster 123
send a request like this:
GET /ovirt-engine/api/clusters/123/enabledfeatures
This will return a list of features:
<enabled_features> <cluster_feature id="123"> <name>test_feature</name> </cluster_feature> ... </enabled_features>
Table 6.103. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| Out | Retrieved features. | |
| In | Indicates which inner links should be followed. |
6.34.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.35. ClusterExternalProviders
This service lists external providers.
Table 6.104. Methods summary
Name | Summary |
---|---|
| Returns the list of external providers. |
6.35.1. list GET
Returns the list of external providers.
The order of the returned list of providers is not guaranteed.
Table 6.105. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out |
6.35.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.36. ClusterFeature
Represents a feature enabled for the cluster level
Table 6.106. Methods summary
Name | Summary |
---|---|
| Provides the information about the a cluster feature supported by a cluster level. |
6.36.1. get GET
Provides the information about the a cluster feature supported by a cluster level.
For example, to find details of the cluster feature 456
for cluster level 4.1, send a request like this:
GET /ovirt-engine/api/clusterlevels/4.1/clusterfeatures/456
That will return a ClusterFeature object containing the name:
<cluster_feature id="456"> <name>libgfapi_supported</name> </cluster_feature>
Table 6.107. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| Out | Retrieved cluster feature. | |
| In | Indicates which inner links should be followed. |
6.36.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.37. ClusterFeatures
Provides information about the cluster features that are supported by a cluster level.
Table 6.108. Methods summary
Name | Summary |
---|---|
| Lists the cluster features supported by the cluster level. |
6.37.1. list GET
Lists the cluster features supported by the cluster level.
GET /ovirt-engine/api/clusterlevels/4.1/clusterfeatures
This will return a list of cluster features supported by the cluster level:
<cluster_features> <cluster_feature id="123"> <name>test_feature</name> </cluster_feature> ... </cluster_features>
Table 6.109. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| Out | Retrieved features. | |
| In | Indicates which inner links should be followed. |
6.37.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.38. ClusterLevel
Provides information about a specific cluster level. See the ClusterLevels service for more information.
Table 6.110. Methods summary
Name | Summary |
---|---|
| Provides the information about the capabilities of the specific cluster level managed by this service. |
6.38.1. get GET
Provides the information about the capabilities of the specific cluster level managed by this service.
For example, to find what CPU types are supported by level 3.6 you can send a request like this:
GET /ovirt-engine/api/clusterlevels/3.6
That will return a ClusterLevel object containing the supported CPU types, and other information which describes the cluster level:
<cluster_level id="3.6"> <cpu_types> <cpu_type> <name>Intel Conroe Family</name> <level>3</level> <architecture>x86_64</architecture> </cpu_type> ... </cpu_types> <permits> <permit id="1"> <name>create_vm</name> <administrative>false</administrative> </permit> ... </permits> </cluster_level>
Table 6.111. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out | Retreived cluster level. |
6.38.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.39. ClusterLevels
Provides information about the capabilities of different cluster levels supported by the engine. Version 4.0 of the engine supports levels 4.0 and 3.6. Each of these levels support different sets of CPU types, for example. This service provides that information.
Table 6.112. Methods summary
Name | Summary |
---|---|
| Lists the cluster levels supported by the system. |
6.39.1. list GET
Lists the cluster levels supported by the system.
GET /ovirt-engine/api/clusterlevels
This will return a list of available cluster levels.
<cluster_levels> <cluster_level id="4.0"> ... </cluster_level> ... </cluster_levels>
The order of the returned cluster levels isn’t guaranteed.
Table 6.113. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In | Indicates which inner links should be followed. | |
| Out | Retrieved cluster levels. |
6.39.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.40. ClusterNetwork
A service to manage a specific cluster network.
Table 6.114. Methods summary
Name | Summary |
---|---|
| Retrieves the cluster network details. |
| Unassigns the network from a cluster. |
| Updates the network in the cluster. |
6.40.1. get GET
Retrieves the cluster network details.
Table 6.115. Parameters summary
6.40.1.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.40.2. remove DELETE
Unassigns the network from a cluster.
6.40.3. update PUT
Updates the network in the cluster.
Table 6.116. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The cluster network. |
6.41. ClusterNetworks
A service to manage cluster networks.
Table 6.117. Methods summary
Name | Summary |
---|---|
| Assigns the network to a cluster. |
| Lists the networks that are assigned to the cluster. |
6.41.1. add POST
Assigns the network to a cluster.
Post a request like in the example below to assign the network to a cluster:
POST /ovirt-engine/api/clusters/123/networks
Use the following example in its body:
<network id="123" />
Table 6.118. Parameters summary
Name | Type | Direction | Summary |
---|---|---|---|
| In/Out | The network object to be assigned to the cluster. |
6.41.2. list GET
Lists the networks that are assigned to the cluster.
The order of the returned clusters isn’t guaranteed.
Table 6.119. Parameters summary
6.41.2.1. follow
Indicates which inner links should be followed. The objects referenced by these links will be fetched as part of the current request. See here for details.
6.41.2.2. max
Sets the maximum number of networks to return. If not specified, all the networks are returned.
6.42. Clusters
A service to manage clusters.
Table 6.120. Methods summary
Name | Summary |
---|---|
| Creates a new cluster. |
| Returns the list of clusters of the system. |
6.42.1. add POST
Creates a new cluster.
This requires the name
, cpu.type
, and data_center
attributes. Identify the data center with either the id
or name
attribute.
POST /ovirt-engine/api/clusters
With a request body like this:
<cluster> <name>mycluster</name> <cpu> <type>Intel Penryn Family</type> </cpu> <data_center id="123"/> </cluster>
To create a cluster with an external network provider to be deployed on every host that is added to the cluster, send a request like this:
POST /ovirt-engine/api/clusters
With a request body containing a reference to the desired provider:
<cluster> <name>mycluster</name> <cpu> <type>Intel Penryn Family</type> </cpu> <data_center id="123"/> <external_network_providers> <external_provider name="ovirt-provider-ovn"/> </external_network_providers> </cluster>
Table 6.121. Parameters summary