1. Introduction
The oVirt Engine provides a Representational State Transfer (REST) API. The API provides software developers and system administrators with control over their oVirt environment outside of the standard web interface. The API is useful for developers and administrators who aim to integrate the functionality of an oVirt 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 an oVirt environment with scripts.
This documentation acts as a reference to the oVirt API. It aims to provide developers and administrators with instructions and examples to help harness the functionality of their oVirt 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 independent of any other request and contains all necessary information to complete the request.
1.2. API Prerequisites
Prerequisites for using the oVirt API:
-
A networked installation of oVirt Engine, 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), which is 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.
2. Authentication and Security
2.1. TLS/SSL Certification
The oVirt API requires Hypertext Transfer Protocol Secure (HTTPS) [1] for secure interaction with client software, such as the SDK and CLI components. This involves a process of obtaining a certificate from the oVirt Engine and importing it into the certificate store of your client.
Important
|
Obtain your certificate from the oVirt Engine using a secure network connection. |
2.1.1. Obtaining a Certificate
You can obtain a certificate from the oVirt Engine and transfer it to the client machine using one of three methods:
-
Method 1 - Use a command line tool to download the certificate from the engine. Examples of command line tools include
curl
andwget
, both of which are available on multiple platforms.-
If using
curl
:$ curl \ -o ca.crt \ 'https://myengine.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA'
-
If using
wget
:$ wget \ -O ca.crt \ 'https://myengine.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA'
-
-
Method 2 - 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
.
-
-
Method 3 - Log in to the engine, export the certificate from the truststore and copy it to your client machine.
-
Log in to the engine machine as the
root
user. -
Export the certificate from the truststore using the Java
keytool
management utility:$ keytool \ -exportcert \ -keystore \ /etc/pki/ovirt-engine/.truststore \ -alias cacert \ -storepass mypass \ -file ca.crt
This creates a certificate file called
ca.crt
. -
Copy the certificate to the client machine using the
scp
command:$ scp ca.cer myuser@myclient.example.com:/home/myuser/.
-
Each of these methods results in a certificate file named ca.crt
on
your client machine. An API user imports 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 itself stores and interprets certificates. This guide contains some examples on importing certificates. For clients not using Network Security Services (NSS) or Java KeyStore (JKS), see your client documentation for more information on importing a certificate.
2.2. HTTP Authentication
Any user with an oVirt Engine account has access to the API. An API
user submits a mandatory oVirt Engine user name and password with all
requests to the API. Each request uses HTTP Basic Authentication
[2] to encode these credentials. If a
request does not include an appropriate Authorization
header, the API
sends a 401 Authorization Required
as a result:
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. An API user encodes an appropriate oVirt Engine domain and user
in the supplied credentials with the username@domain:password
convention.
The following table shows the process for encoding credentials in Base64.
Item | Value |
---|---|
User name |
|
Domain |
|
Password |
|
Unencoded credentials |
|
Base64 encoded credentials |
|
An API user provides 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
Important
|
Basic authentication involves potentially sensitive information, such as passwords, sent as plain text. API requires Hypertext Transfer Protocol Secure (HTTPS) for transport-level encryption of plain-text requests. |
Important
|
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.3. Authentication Sessions
The API also provides the ability for authentication session support. An API user sends an initial request with authentication details, then sends all subsequent requests using a session cookie to authenticate. The following procedure demonstrates how to use an authenticated session.
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
Note the
JSESSIONID=
value. In this example the value is5dQja5ubr4yvI2MM2z+LZxrK
. -
Send all subsequent requests with the
Prefer: persistent-auth
andCookie
headers with theJSESSIONID=
value. The `Authorization 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 ...
3. Quick start example
This chapter provides an example to demonstrate the REST API’s ability to setup a basic oVirt environment and create a virtual machine. In addition to the standard prerequisites, this example requires the following:
-
A networked and configured oVirt installation;
-
An ISO file containing a desired virtual machine operating system to install. This chapter uses CentOS 7 for our installation ISO example; and
-
oVirt’s
engine-iso-uploader
tool to upload your chosen operating system ISO file.
This example uses curl
to demonstrate API
requests with a client application. Note that any application capable of
HTTP requests can substitute for curl
.
Important
|
For simplicity, 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 oVirt.
|
Important
|
All the curl examples use admin@internal as the user
name, mypassword as the password, /etc/pki/ovirt-engine/ca.pem as the
certificate location and myengine.example.com as the host name. These
are just examples, Make sure to replace them with valid values for your
environment.
|
Note
|
oVirt generates an unique identifier for the id
attribute for each resource. Identifier codes in this example might
appear different to the identifier codes in your oVirt
environment.
|
Note
|
In many examples of this section some of the attributes of results
returned by the API have been omitted, to make them shorter. You can
always use the reference to find the complete list of attributes. For
example, if you want to see the complete list of attributes of the
Cluster type, just go here.
|
3.1. Example: Access API entry point
The following request retrieves a representation of the main entry point for version 4 of of the API:
GET /ovirt-engine/api HTTP/1.1 Version: 4 Accept: application/xml
Same request, but using the /v4
URL prefix instead of the Version
header:
GET /ovirt-engine/api/v4 HTTP/1.1 Accept: application/xml
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 will be 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>
Important
|
When neither the header nor the URL prefix are used, the server will
automatically select a version. The default is version # 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.
3.2. Example: List data centers
oVirt creates a Default
data center on installation. This
example uses the Default
data center as the basis for our virtual
environment.
The following request retrieves a representation of the data centers:
GET /ovirt-engine/api/datacenters HTTP/1.1 Accept: application/xml
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.
3.3. Example: List host clusters
oVirt creates a Default
hosts cluster on installation. This
example uses the Default
cluster to group resources in your
oVirt environment.
The following request retrieves a representation of the cluster collection:
GET /ovirt-engine/api/clusters HTTP/1.1 Accept: application/xml
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.
3.4. Example: List logical networks
oVirt creates a default ovirtmgmt
network on installation.
This network acts as the management network for oVirt Engine to access
hosts.
This network is associated with our Default
cluster and is a member of
the Default
data center. This example uses the ovirtmgmt
network to
connect our virtual machines.
The following request retrieves the list of logical networks:
GET /ovirt-engine/api/networks HTTP/1.1 Accept: application/xml
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.
3.5. Example: 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
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.
3.6. Example: 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>
3.7. Example: 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>
3.8. Example: 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>
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>
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
3.9. Example: 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>
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>
3.10. Example: 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>
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
3.11. Example: 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>
<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>
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> <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.
3.12. Example: Attach ISO image to virtual machine
The boot media for our example virtual machine requires an CD-ROM or DVD ISO image for an operating system installation. This example uses a CentOS 7 image for installation.
ISO images must be available in the myisos
ISO domain for the virtual
machines to use. oVirt provides an uploader tool that ensures
that the ISO images are uploaded into the correct directory path with
the correct user permissions.
Once the ISO 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
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 our 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>
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.
3.13. Example: 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>
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.
4. Requests
This section enumerates all the requests that are available in the API.
-
DELETE /clusters/{cluster:id}/affinitygroups/{group:id}/vms/{vm: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}/stopprofile
-
POST /clusters/{cluster:id}/glustervolumes/{volume:id}/stoprebalance
-
GET /clusters/{cluster:id}/networkfilters/{networkfilter:id}
-
DELETE /cpuprofiles/{profile:id}/permissions/{permission: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}/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
-
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/{network:id}/networklabels
-
GET /datacenters/{datacenter:id}/networks/{network:id}/networklabels
-
GET /datacenters/{datacenter:id}/networks/{network:id}/networklabels/{label:id}
-
DELETE /datacenters/{datacenter:id}/networks/{network:id}/networklabels/{label:id}
-
POST /datacenters/{datacenter:id}/networks/{network:id}/permissions
-
GET /datacenters/{datacenter:id}/networks/{network:id}/permissions
-
GET /datacenters/{datacenter:id}/networks/{network:id}/permissions/{permission:id}
-
DELETE /datacenters/{datacenter:id}/networks/{network:id}/permissions/{permission:id}
-
POST /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles
-
GET /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles
-
GET /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles/{profile:id}
-
DELETE /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles/{profile:id}
-
POST /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions
-
GET /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions
-
GET /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions/{permission:id}
-
DELETE /datacenters/{datacenter:id}/networks/{network:id}/vnicprofiles/{profile:id}/permissions/{permission:id}
-
GET /datacenters/{datacenter:id}/permissions/{permission:id}
-
DELETE /datacenters/{datacenter:id}/permissions/{permission: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}
-
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
-
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}
-
GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/statistics
-
GET /datacenters/{datacenter:id}/storagedomains/{storagedomain:id}/disks/{disk:id}/statistics/{statistic:id}
-
GET /diskprofiles/{diskprofile:id}/permissions/{permission:id}
-
DELETE /diskprofiles/{diskprofile:id}/permissions/{permission:id}
-
GET /externalhostproviders/{provider:id}/certificates/{certificate:id}
-
GET /externalhostproviders/{provider:id}/computeresources/{resource:id}
-
GET /externalhostproviders/{provider:id}/discoveredhosts/{host:id}
-
GET /externalhostproviders/{provider:id}/hostgroups/{group:id}
-
POST /externalhostproviders/{provider:id}/importcertificates
-
DELETE /groups/{group:id}/roles/{role:id}/permits/{permit:id}
-
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}
-
DELETE /hosts/{host:id}/nics/{nic:id}/networklabels/{label:id}
-
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/{node:id}/statistics/{statistic:id}
-
GET /hosts/{host:id}/storageconnectionextensions/{storageconnectionextension:id}
-
PUT /hosts/{host:id}/storageconnectionextensions/{storageconnectionextension:id}
-
DELETE /hosts/{host:id}/storageconnectionextensions/{storageconnectionextension:id}
-
GET /hosts/{host:id}/unmanagednetworks/{unmanagednetwork:id}
-
DELETE /hosts/{host:id}/unmanagednetworks/{unmanagednetwork:id}
-
GET /instancetypes/{instancetype:id}/graphicsconsoles/{console:id}
-
DELETE /instancetypes/{instancetype:id}/graphicsconsoles/{console:id}
-
GET /instancetypes/{instancetype:id}/watchdogs/{watchdog:id}
-
PUT /instancetypes/{instancetype:id}/watchdogs/{watchdog:id}
-
DELETE /instancetypes/{instancetype:id}/watchdogs/{watchdog:id}
-
GET /jobs/{job:id}/steps/{step:id}/statistics/{statistic: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}
-
GET /openstackimageproviders/{provider:id}/certificates/{certificate:id}
-
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
-
GET /openstacknetworkproviders/{provider:id}/certificates/{certificate:id}
-
POST /openstacknetworkproviders/{provider:id}/importcertificates
-
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/{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/{certificate:id}
-
POST /openstackvolumeproviders/{provider:id}/importcertificates
-
POST /openstackvolumeproviders/{provider:id}/testconnectivity
-
GET /openstackvolumeproviders/{provider:id}/volumetypes/{type:id}
-
DELETE /schedulingpolicies/{policy:id}/balances/{balance:id}
-
GET /storagedomains/{storagedomain:id}/diskprofiles/{profile:id}
-
DELETE /storagedomains/{storagedomain:id}/diskprofiles/{profile: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}
-
GET /storagedomains/{storagedomain:id}/disks/{disk:id}/statistics
-
GET /storagedomains/{storagedomain:id}/disks/{disk:id}/statistics/{statistic:id}
-
GET /storagedomains/{storagedomain:id}/disksnapshots/{snapshot:id}
-
DELETE /storagedomains/{storagedomain:id}/disksnapshots/{snapshot:id}
-
POST /storagedomains/{storagedomain:id}/images/{image:id}/import
-
GET /storagedomains/{storagedomain:id}/permissions/{permission:id}
-
DELETE /storagedomains/{storagedomain:id}/permissions/{permission:id}
-
GET /storagedomains/{storagedomain:id}/storageconnections/{connection:id}
-
DELETE /storagedomains/{storagedomain:id}/storageconnections/{connection:id}
-
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
-
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/{disk:id}
-
POST /storagedomains/{storagedomain:id}/vms/{vm:id}/register
-
GET /templates/{template:id}/diskattachments/{attachment:id}
-
DELETE /templates/{template:id}/diskattachments/{attachment:id}
-
DELETE /templates/{template:id}/graphicsconsoles/{console:id}
-
GET /vms/{vm:id}/nics/{nic:id}/reporteddevices/{reporteddevice:id}
-
DELETE /vnicprofiles/{profile:id}/permissions/{permission:id}
5. Services
This section enumerates all the services that are available in the API.
5.1. AffinityGroup
This service manages a single affinity group.
Name | Summary |
---|---|
|
Retrieve the affinity group details. |
|
Remove the affinity group. |
|
Update the affinity group. |
5.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>
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
The affinity group. |
5.1.2. remove DELETE
Remove the affinity group.
DELETE /ovirt-engine/api/clusters/000-000/affinitygroups/123-456
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.2. AffinityGroupVm
This service manages a single virtual machine to affinity group assignment.
Name | Summary |
---|---|
|
Remove this virtual machine from the affinity group. |
5.3. AffinityGroupVms
This service manages a collection of all virtual machines assigned to an affinity group.
Name | Summary |
---|---|
|
Add a virtual machine to the affinity group. |
|
List all virtual machines assigned to this affinity group. |
5.3.1. add POST
Add a virtual machine to the affinity group.
For example to add the virtual machine 000-000 to affinity group 123-456 send a request to:
POST /ovirt-engine/api/clusters/000-000/affinitygroups/123-456/vms
With the following body:
<vm id="000-000"/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.4. AffinityGroups
Affinity groups service manages virtual machine relationships and dependencies.
Name | Summary |
---|---|
|
Create a new affinity group. |
|
List existing affinity groups. |
5.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>
<positive>true</positive>
<enforcing>true</enforcing>
</affinity_group>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
The affinity group object to create. |
5.5. AffinityLabel
Single affinity label details.
Name | Summary |
---|---|
|
Retrieves details about a label. |
|
Removes a label from system and clears all assignments of the removed label. |
|
Updates a label. |
5.5.1. get GET
Retrieves details about a label.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.6. AffinityLabelHost
This service represents a host that has a specific label when accessed through the affinitylabels/hosts subcollection.
Name | Summary |
---|---|
|
Retrieves details about a host that has this label assigned. |
|
Remove a label from a host. |
5.7. AffinityLabelHosts
This service represents list of hosts that have a specific label when accessed through the affinitylabels/hosts subcollection.
Name | Summary |
---|---|
|
Add a label to a host. |
|
List all hosts with the label. |
5.7.1. add POST
Add a label to a host.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.8. AffinityLabelVm
This service represents a vm that has a specific label when accessed through the affinitylabels/vms subcollection.
Name | Summary |
---|---|
|
Retrieves details about a vm that has this label assigned. |
|
Remove a label from a vm. |
5.9. AffinityLabelVms
This service represents list of vms that have a specific label when accessed through the affinitylabels/vms subcollection.
Name | Summary |
---|---|
|
Add a label to a vm. |
|
List all vms with the label. |
5.9.1. add POST
Add a label to a vm.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.10. AffinityLabels
Manages the affinity labels available in the system.
Name | Summary |
---|---|
|
Creates a new label. |
|
Lists all labels present in the system. |
5.10.1. add POST
Creates a new label. The label is automatically attached to all entities mentioned in the vms or hosts lists.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.11. AssignedAffinityLabel
This service represents one label to entity assignment when accessed using the entities/affinitylabels subcollection.
Name | Summary |
---|---|
|
Retrieves details about the attached label. |
|
Removes the label from an entity. |
5.12. AssignedAffinityLabels
This service is used to list and manipulate affinity labels that are assigned to supported entities when accessed using entities/affinitylabels.
Name | Summary |
---|---|
|
Attaches a label to an entity. |
|
Lists all labels that are attached to an entity. |
5.12.1. add POST
Attaches a label to an entity.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.13. AssignedCpuProfile
Name | Summary |
---|---|
|
|
|
5.14. AssignedCpuProfiles
Name | Summary |
---|---|
|
|
|
5.15. AssignedDiskProfile
Name | Summary |
---|---|
|
|
|
5.16. AssignedDiskProfiles
Name | Summary |
---|---|
|
|
|
5.17. AssignedNetwork
Name | Summary |
---|---|
|
|
|
|
|
5.18. AssignedNetworks
Name | Summary |
---|---|
|
|
|
5.19. AssignedPermissions
Represents a permission sub-collection, scoped by User or some entity type.
Name | Summary |
---|---|
|
|
|
5.20. AssignedRoles
Represents a roles sub-collection, for example scoped by user.
Name | Summary |
---|---|
|
5.21. AssignedTag
Name | Summary |
---|---|
|
|
|
5.22. AssignedTags
Name | Summary |
---|---|
|
|
|
5.23. AssignedVnicProfile
Name | Summary |
---|---|
|
|
|
5.24. AssignedVnicProfiles
Name | Summary |
---|---|
|
|
|
5.25. AttachedStorageDomain
Name | Summary |
---|---|
|
This operation activates an attached storage domain. |
|
This operation deactivates an attached storage domain. |
|
|
|
5.25.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/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the activation should be performed asynchronously. |
5.25.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.
POST /ovirt-engine/api/datacenters/123/storagedomains/456/deactivate
The deactivate action does not take any action specific parameters,
so the request body should contain an empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the deactivation should be performed asynchronously. |
5.26. AttachedStorageDomains
Name | Summary |
---|---|
|
|
|
5.27. Balance
Name | Summary |
---|---|
|
|
|
5.27.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
5.28. Balances
Name | Summary |
---|---|
|
|
|
5.29. Bookmark
Name | Summary |
---|---|
|
|
|
|
|
5.30. Bookmarks
Name | Summary |
---|---|
|
|
|
5.31. Cluster
Name | Summary |
---|---|
|
|
|
Removes cluster from the system. |
|
|
|
Updates information about the cluster. |
5.31.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
5.31.2. remove DELETE
Removes cluster from the system.
DELETE /ovirt-engine/api/clusters/00000000-0000-0000-0000-000000000000
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.31.3. resetemulatedmachine POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the reset should be performed asynchronously. |
5.31.4. update PUT
Updates information about the cluster.
Only specified fields are updated, others remain unchanged.
E.g. update cluster’s CPU:
PUT /ovirt-engine/api/clusters/123
With request body like:
<cluster>
<cpu>
<type>Intel Haswell-noTSX Family</type>
</cpu>
</cluster>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.32. ClusterLevel
Provides information about a specific cluster level. See the ClusterLevels service for more information.
Name | Summary |
---|---|
|
Provides the information about the capabilities of the specific cluster level managed by this service. |
5.33. 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. For example, to find what CPU types are supported by level 3.6 the 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 describing the cluster level:
<cluster_level id="3.6" href="/ovirt-engine/api/clusterlevel/3.6">
<cpu_types>
<cpu_type>
<name>Intel Conroe Family</name>
<level>3</level>
<architecture>x86_64</architecture>
</cpu_type>
...
</cpu_types>
...
</cluster_level>
Name | Summary |
---|---|
|
Lists the cluster levels supported by the system. |
5.34. Clusters
Name | Summary |
---|---|
|
Creates a new cluster. |
|
5.34.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
attributes.
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>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.34.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
Sets the maximum number of clusters to return. |
|
|
In |
A query string used to restrict the returned clusters. |
5.35. Copyable
Name | Summary |
---|---|
|
5.36. CpuProfile
Name | Summary |
---|---|
|
|
|
|
|
5.36.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.37. CpuProfiles
Name | Summary |
---|---|
|
|
|
5.38. DataCenter
Name | Summary |
---|---|
|
|
|
Removes the data center. |
|
Updates the data center. |
5.38.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
5.38.2. remove DELETE
Removes the data center.
DELETE /ovirt-engine/api/datacenters/123
Without any special parameters, the storage domains attached to the data center are detached and then removed from the storage. If something fails when performing this operation, for example if there is no host available to remove the storage domains from the storage, the complete operation will fail.
If the force
parameter is true
then the operation will always succeed, even if something fails while removing
one storage domain, for example. The failure is just ignored and the data center is removed from the database
anyway.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
|
|
In |
Indicates if the operation should succeed, and the storage domain removed from the database, even if something fails during the operation. |
5.38.3. update PUT
Updates the data center.
The name
, description
, storage_type
, version
, storage_format
and mac_pool
elements are updatable
post-creation. For example, to change the name and description of data center 123
send a request like this:
PUT /ovirt-engine/api/datacenters/123
With a request body like this:
<data_center>
<name>myupdatedname</name>
<description>An updated description for the data center</description>
</data_center>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
The data center that is being updated. |
5.39. DataCenters
Name | Summary |
---|---|
|
Creates a new data center. |
|
Lists the data centers. |
5.39.1. add POST
Creates a new data center.
Creation of a new data center requires the name
and local
elements. For example, to create a data center
named mydc
that uses shared storage (NFS, iSCSI or fibre channel) send a request like this:
POST /ovirt-engine/api/datacenters
With a request body like this:
<data_center>
<name>mydc</name>
<local>false</local>
</data_center>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
The data center that is being added. |
5.39.2. list GET
Lists the data centers.
The following request retrieves a representation of the data centers:
GET /ovirt-engine/api/datacenters
The above request performed with curl
:
curl \
--request GET \
--cacert /etc/pki/ovirt-engine/ca.pem \
--header "Version: 4" \
--header "Accept: application/xml" \
--user "admin@internal:mypassword" \
https://myengine.example.com/ovirt-engine/api/datacenters
This is what an example response could look like:
<data_center href="/ovirt-engine/api/datacenters/123" id="123">
<name>Default</name>
<description>The default Data Center</description>
<link href="/ovirt-engine/api/datacenters/123/networks" rel="networks"/>
<link href="/ovirt-engine/api/datacenters/123/storagedomains" rel="storagedomains"/>
<link href="/ovirt-engine/api/datacenters/123/permissions" rel="permissions"/>
<link href="/ovirt-engine/api/datacenters/123/clusters" rel="clusters"/>
<link href="/ovirt-engine/api/datacenters/123/qoss" rel="qoss"/>
<link href="/ovirt-engine/api/datacenters/123/iscsibonds" rel="iscsibonds"/>
<link href="/ovirt-engine/api/datacenters/123/quotas" rel="quotas"/>
<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>
Note the id
code of your Default
data center. This code identifies this data center in relation to other
resources of your virtual environment.
The data center also contains a link to the storage domains collection. The data center uses this collection to attach storage domains from the storage domains main collection.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
Sets the maximum number of data centers to return. |
|
|
In |
A query string used to restrict the returned data centers. |
5.40. Disk
Manages a single disk.
Name | Summary |
---|---|
|
This operation copies a disk to the specified storage domain. |
|
|
|
|
|
Moves a disk to another storage domain. |
|
5.40.1. copy POST
This operation copies a disk to the specified storage domain.
For example, copy of a disk can be facilitated using the following request:
POST /ovirt-engine/api/disks/123/copy
With a request body like this:
<action>
<storage_domain id="456"/>
<disk>
<name>mydisk</name>
</disk>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the copy should be performed asynchronously. |
|
|
In |
||
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
5.40.2. export POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the export should be performed asynchronously. |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
5.40.4. move POST
Moves a disk to another storage domain.
For example, to move the disk with identifier 123
to a storage domain with identifier 456
send the following
request:
POST /ovirt-engine/api/disks/123/move
With the following request body:
<action>
<storage_domain id="456"/>
</action>
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 |
5.41. DiskAttachment
This service manages the attachment of a disk to a virtual machine.
Name | Summary |
---|---|
|
Returns the details of the attachment, including the bootable flag and link to the disk. |
|
Removes the disk attachment. |
|
Update the disk attachment and the disk properties within it. |
5.41.1. get GET
Returns the details of the attachment, including the bootable flag and link to the disk.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.41.2. remove DELETE
Removes the disk attachment. This will only detach the disk from the virtual machine, but won’t remove it from
the system, unless the detach_only
parameter is false
.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the disk should only be detached from the virtual machine, but not removed from the system. |
5.41.3. update PUT
Update the disk attachment and the disk properties within it.
PUT /vms/{vm:id}/disksattachments/{attachment:id}
<disk_attachment>
<bootable>true</bootable>
<interface>ide</interface>
<disk>
<name>mydisk</name>
<provisioned_size>1024</provisioned_size>
...
</disk>
</disk_attachment>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.42. DiskAttachments
This service manages the set of disks attached to a virtual machine. Each attached disk is represented by a DiskAttachment, containing the bootable flag, the disk interface and the reference to the disk.
Name | Summary |
---|---|
|
Adds a new disk attachment to the virtual machine. |
|
List the disk that are attached to the virtual machine. |
5.42.1. add POST
Adds a new disk attachment to the virtual machine. The attachment
parameter can contain just a reference, if
the disk already exists:
<disk_attachment>
<bootable>true</bootable>
<interface>ide</interface>
<disk id="123"/>
</disk_attachment>
Or it can contain the complete representation of the disk, if the disk doesn’t exist yet:
<disk_attachment>
<bootable>true</bootable>
<interface>ide</interface>
<disk>
<name>mydisk</name>
<provisioned_size>1024</provisioned_size>
...
</disk>
</disk_attachment>
In this case the disk will be created and then attached to the virtual machine.
In both cases, use the following URL for a virtual machine with an id 345
:
POST /ovirt-engine/api/vms/345/diskattachments
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.43. DiskProfile
Name | Summary |
---|---|
|
|
|
|
|
5.43.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.44. DiskProfiles
Name | Summary |
---|---|
|
|
|
5.45. DiskSnapshot
Name | Summary |
---|---|
|
|
|
5.46. DiskSnapshots
Name | Summary |
---|---|
|
5.47. Disks
Manages the collection of disks available in the system.
Name | Summary |
---|---|
|
Adds a new floating disk. |
|
5.47.1. add POST
Adds a new floating disk.
When creating a new floating Disk, the API requires the storage_domain
, provisioned_size
and
format
attributes.
To create a new floating disk with specified provisioned_size
, format
and name
on a storage domain with an
id e9fedf39-5edc-4e0a-8628-253f1b9c5693
, send a request as follows:
POST /ovirt-engine/api/disks
With a request body as follows:
<disk>
<storage_domains>
<storage_domain id="e9fedf39-5edc-4e0a-8628-253f1b9c5693"/>
</storage_domains>
<name>disk1</name>
<provisioned_size>1048576</provisioned_size>
<format>cow</format>
</disk>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.47.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Sets the maximum number of disks to return. |
|
|
In |
A query string used to restrict the returned disks. |
5.48. Domain
Name | Summary |
---|---|
|
5.49. DomainGroup
Name | Summary |
---|---|
|
5.50. DomainGroups
Name | Summary |
---|---|
|
5.50.1. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Sets the maximum number of groups to return. |
|
|
In |
A query string used to restrict the returned groups. |
5.51. DomainUser
Name | Summary |
---|---|
|
5.52. DomainUsers
Name | Summary |
---|---|
|
5.52.1. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Sets the maximum number of users to return. |
|
|
In |
A query string used to restrict the returned users. |
|
|
Out |
5.54. EngineKatelloErrata
This service doesn’t add any new methods, it is just a placeholder for the annotation that specifies the path of the resource that manages the Katello errata assigned to the engine.
Name | Summary |
---|---|
|
5.55. Event
Name | Summary |
---|---|
|
|
|
Removes an event from internal audit log. |
5.56. Events
Name | Summary |
---|---|
|
Adds an external event to the internal audit log. |
|
Get list of events. |
|
5.56.1. add POST
Adds an external event to the internal audit log.
This is intended for integration with external systems that detect or produce events relevant for the administrator of the system. For example, an external monitoring tool may be able to detect that a file system is full inside the guest operating system of a virtual machine. This event can be added to the internal audit log sending a request like this:
POST /ovirt-engine/api/events
<event>
<description>File system /home is full</description>
<severity>alert</severity>
<origin>mymonitor</origin>
<custom_id>1467879754</custom_id>
</event>
Events can also be linked to specific objects. For example, the above event could be linked to the specific
virtual machine where it happened, using the vm
link:
POST /ovirt-engine/api/events
<event>
<description>File system /home is full</description>
<severity>alert</severity>
<origin>mymonitor</origin>
<custom_id>1467879754</custom_id>
<vm id="aae98225-5b73-490d-a252-899209af17e9"/>
</event>
Note
|
When using links, like the vm in the previous example, only the id attribute is accepted. The name
attribute, if provided, is simply ignored.
|
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.56.2. list GET
Get list of events.
GET /ovirt-engine/api/events
To the above request we get following reponse:
<events>
<event href="/ovirt-engine/api/events/2" id="2">
<description>User admin@internal-authz logged out.</description>
<code>31</code>
<correlation_id>1e892ea9</correlation_id>
<custom_id>-1</custom_id>
<flood_rate>30</flood_rate>
<origin>oVirt</origin>
<severity>normal</severity>
<time>2016-09-14T12:14:34.541+02:00</time>
<user href="/ovirt-engine/api/users/57d91d48-00da-0137-0138-000000000244" id="57d91d48-00da-0137-0138-000000000244"/>
</event>
<event href="/ovirt-engine/api/events/1" id="1">
<description>User admin logged in.</description>
<code>30</code>
<correlation_id>1fbd81f4</correlation_id>
<custom_id>-1</custom_id>
<flood_rate>30</flood_rate>
<origin>oVirt</origin>
<severity>normal</severity>
<time>2016-09-14T11:54:35.229+02:00</time>
<user href="/ovirt-engine/api/users/57d91d48-00da-0137-0138-000000000244" id="57d91d48-00da-0137-0138-000000000244"/>
</event>
</events>
The following events occur:
-
id="1" - The API logs in the admin user account.
-
id="2" - The API logs out of the admin user account.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Indicates the identifier of the the first event that should be returned. |
|
|
In |
Sets the maximum number of events to return. |
|
|
In |
The events service provides search queries similar to other resource services. |
case_sensitive
Indicates if the search performed using the search
parameter should be performed taking case into
account. The default value is true
, which means that case is taken into account. If you want to search
ignoring case set it to false
.
from
Indicates the identifier of the the first event that should be returned. The identifiers of events are
strictly increasing, so when this parameter is used only the events with that identifiers equal or greater
than the given value will be returned. For example, the following request will return only the events
with identifiers greater or equal than 123
:
GET /ovirt-engine/api/events?from=123
This parameter is optional, and if not specified then the first event returned will be most recently generated.
search
The events service provides search queries similar to other resource services.
We can search by providing specific severity.
GET /ovirt-engine/api/events?search=severity%3Dnormal
To the above request we get a list of events which severity is equal to normal
:
<events>
<event href="/ovirt-engine/api/events/2" id="2">
<description>User admin@internal-authz logged out.</description>
<code>31</code>
<correlation_id>1fbd81f4</correlation_id>
<custom_id>-1</custom_id>
<flood_rate>30</flood_rate>
<origin>oVirt</origin>
<severity>normal</severity>
<time>2016-09-14T11:54:35.229+02:00</time>
<user href="/ovirt-engine/api/users/57d91d48-00da-0137-0138-000000000244" id="57d91d48-00da-0137-0138-000000000244"/>
</event>
<event href="/ovirt-engine/api/events/1" id="1">
<description>Affinity Rules Enforcement Manager started.</description>
<code>10780</code>
<custom_id>-1</custom_id>
<flood_rate>30</flood_rate>
<origin>oVirt</origin>
<severity>normal</severity>
<time>2016-09-14T11:52:18.861+02:00</time>
</event>
</events>
A virtualization environment generates a large amount of events after a period of time. However, the API only displays a default number of events for one search query. To display more than the default, the API separates results into pages with the page command in a search query. The following search query tells the API to paginate results using a page value in combination with the sortby clause:
sortby time asc page 1
Below example paginates event resources. The URL-encoded request is:
GET /ovirt-engine/api/events?search=sortby%20time%20asc%20page%201
Increase the page value to view the next page of results.
GET /ovirt-engine/api/events?search=sortby%20time%20asc%20page%202
5.57. ExternalComputeResource
Name | Summary |
---|---|
|
5.58. ExternalComputeResources
Name | Summary |
---|---|
|
5.59. ExternalDiscoveredHost
Name | Summary |
---|---|
|
5.60. ExternalDiscoveredHosts
Name | Summary |
---|---|
|
5.61. ExternalHost
Name | Summary |
---|---|
|
5.62. ExternalHostGroup
Name | Summary |
---|---|
|
5.63. ExternalHostGroups
Name | Summary |
---|---|
|
5.64. ExternalHostProvider
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
5.64.2. importcertificates POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
5.64.3. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.64.4. testconnectivity POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the test should be performed asynchronously. |
5.65. ExternalHostProviders
Name | Summary |
---|---|
|
|
|
5.66. ExternalHosts
Name | Summary |
---|---|
|
5.67. ExternalProvider
Name | Summary |
---|---|
|
|
|
5.67.1. importcertificates POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
5.68. ExternalProviderCertificate
Name | Summary |
---|---|
|
5.69. ExternalProviderCertificates
Name | Summary |
---|---|
|
5.70. ExternalVmImports
Provides capability to import external virtual machines.
Name | Summary |
---|---|
|
This operation is used to import a virtual machine from external hypervisor, such as KVM, XEN or VMware. |
5.70.1. add POST
This operation is used to import a virtual machine from external hypervisor, such as KVM, XEN or VMware.
For example import of a virtual machine from VMware can be facilitated using the following request:
POST /externalvmimports
With request body of type ExternalVmImport, for example:
<external_vm_import>
<vm>
<name>my_vm</name>
</vm>
<cluster id="360014051136c20574f743bdbd28177fd" />
<storage_domain id="8bb5ade5-e988-4000-8b93-dbfc6717fe50" />
<name>vm_name_as_is_in_vmware</name>
<sparse>true</sparse>
<username>vmware_user</username>
<password>123456</password>
<provider>VMWARE</provider>
<url>vpx://wmware_user@vcenter-host/DataCenter/Cluster/esxi-host?no_verify=1</url>
<drivers_iso id="virtio-win-1.6.7.iso" />
</external_vm_import>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.71. FenceAgent
Name | Summary |
---|---|
|
|
|
|
|
5.72. FenceAgents
Name | Summary |
---|---|
|
|
|
5.73. File
Name | Summary |
---|---|
|
5.74. Files
Provides a way for clients to list available files.
This services is specifically targeted to ISO storage domains, which contain ISO images and virtual floppy disks (VFDs) that an administrator uploads.
The addition of a CDROM device to a virtual machine requires an ISO image from the files of an ISO storage domain.
Name | Summary |
---|---|
|
5.74.1. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Sets the maximum number of files to return. |
|
|
In |
A query string used to restrict the returned files. |
5.75. Filter
Name | Summary |
---|---|
|
|
|
5.75.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.76. Filters
Name | Summary |
---|---|
|
|
|
5.77. GlusterBrick
Name | Summary |
---|---|
|
|
|
Removes this brick from the volume and deletes it from the database. |
|
Replaces this brick with a new one. |
5.78. GlusterBricks
Name | Summary |
---|---|
|
|
|
Adds given list of bricks to the volume, and updates the database accordingly. |
|
|
|
|
|
Removes the given list of bricks brick from the volume and deletes them from the database. |
|
5.78.1. activate POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the activation should be performed asynchronously. |
|
|
In |
5.78.2. add POST
Adds given list of bricks to the volume, and updates the database accordingly. The properties serverId
and
`brickDir`are required.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
The list of bricks to be added to the volume |
5.78.3. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Sets the maximum number of bricks to return. |
5.78.4. migrate POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the migration should be performed asynchronously. |
|
|
In |
5.78.5. remove DELETE
Removes the given list of bricks brick from the volume and deletes them from the database.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
|
|
In |
The list of bricks to be removed |
5.79. GlusterHook
Name | Summary |
---|---|
|
Resolves status conflict of hook among servers in cluster by disabling Gluster hook in all servers of the cluster. |
|
Resolves status conflict of hook among servers in cluster by disabling Gluster hook in all servers of the cluster. |
|
|
|
Removes the this Gluster hook from all servers in cluster and deletes it from the database. |
|
Resolves missing hook conflict depending on the resolution type. |
5.79.1. disable POST
Resolves status conflict of hook among servers in cluster by disabling Gluster hook in all servers of the
cluster. This updates the hook status to DISABLED
in database.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.79.2. enable POST
Resolves status conflict of hook among servers in cluster by disabling Gluster hook in all servers of the
cluster. This updates the hook status to DISABLED
in database.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.79.4. remove DELETE
Removes the this Gluster hook from all servers in cluster and deletes it from the database.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.79.5. resolve POST
Resolves missing hook conflict depending on the resolution type.
For ADD
resolves by copying hook stored in engine database to all servers where the hook is missing. The
engine maintains a list of all servers where hook is missing.
For COPY
resolves conflict in hook content by copying hook stored in engine database to all servers where
the hook is missing. The engine maintains a list of all servers where the content is conflicting. If a host
id is passed as parameter, the hook content from the server is used as the master to copy to other servers
in cluster.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
||
|
In |
5.80. GlusterHooks
Name | Summary |
---|---|
|
5.81. GlusterVolume
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.81.2. getprofilestatistics POST
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.81.3. rebalance POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the rebalance should be performed asynchronously. |
|
|
In |
||
|
In |
5.81.4. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.81.5. resetalloptions POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the reset should be performed asynchronously. |
5.81.6. resetoption POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the reset should be performed asynchronously. |
|
|
In |
||
|
In |
5.81.7. setoption POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
5.81.8. start POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
5.81.9. startprofile POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.81.10. stop POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
5.81.11. stopprofile POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.82. GlusterVolumes
Name | Summary |
---|---|
|
Creates a new Gluster volume and adds it to the database. |
|
5.82.1. add POST
Creates a new Gluster volume and adds it to the database. The volume is created based on properties of the
volume
parameter. The properties name
, volumeType
and bricks
are required.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
The Gluster volume definition from which to create the volume is passed as input and the newly created volume is returned. |
5.82.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Sets the maximum number of volumes to return. |
|
|
In |
A query string used to restrict the returned volumes. |
|
|
Out |
5.83. GraphicsConsole
Name | Summary |
---|---|
|
Gets the configuration of the graphics console. |
|
5.83.1. get GET
Gets the configuration of the graphics console.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Use the following query to obtain the current run-time configuration of the graphics console. |
5.84. GraphicsConsoles
Name | Summary |
---|---|
|
|
|
Lists all the configured graphics consoles of the virtual machine. |
5.84.2. list GET
Lists all the configured graphics consoles of the virtual machine.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Use the following query to obtain the current run-time configuration of the graphics consoles. |
|
|
In |
Sets the maximum number of consoles to return. |
5.85. Group
Name | Summary |
---|---|
|
|
|
5.86. Groups
Name | Summary |
---|---|
|
Add group from a directory service. |
|
5.86.1. add POST
Add group from a directory service. Please note that domain name is name of the authorization provider.
For example, to add the Developers
group from the internal-authz
authorization provider send a request
like this:
POST /ovirt-engine/api/groups
With a request body like this:
<group>
<name>Developers</name>
<domain>
<name>internal-authz</name>
</domain>
</group>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.86.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Sets the maximum number of groups to return. |
|
|
In |
A query string used to restrict the returned groups. |
5.87. Host
Name | Summary |
---|---|
|
Activate the host for use, such as running virtual machines. |
|
Approve a pre-installed Hypervisor host for usage in the virtualization environment. |
|
Marks the network configuration as good and persists it inside the host. |
|
Deactivate the host to perform maintenance tasks. |
|
Enroll certificate of the host. |
|
Controls host’s power management device. |
|
Manually set a host as the storage pool manager (SPM). |
|
Get the host details. |
|
Install VDSM and related software on the host. |
|
|
|
|
|
|
|
Remove the host from the system. |
|
This method is used to change the configuration of the network interfaces of a host. |
|
|
|
Update the host properties. |
|
Upgrade VDSM and selected software on the host. |
5.87.1. activate POST
Activate the host for use, such as running virtual machines.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the activation should be performed asynchronously. |
5.87.2. approve POST
Approve a pre-installed Hypervisor host for usage in the virtualization environment.
This action also accepts an optional cluster element to define the target cluster for this host.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the approval should be performed asynchronously. |
|
|
In |
5.87.3. commitnetconfig POST
Marks the network configuration as good and persists it inside the host.
An API user commits the network configuration to persist a host network interface attachment or detachment, or persist the creation and deletion of a bonded interface.
Important
|
Networking configuration is only committed after the engine has established that host connectivity is not lost as a result of the configuration changes. If host connectivity is lost, the host requires a reboot and automatically reverts to the previous networking configuration. |
For example, to commit the network configuration of host with id 123
send a request like this:
POST /ovirt-engine/api/hosts/123/commitnetconfig
With a request body like this:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.87.4. deactivate POST
Deactivate the host to perform maintenance tasks.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the deactivation should be performed asynchronously. |
|
|
In |
||
|
In |
Indicates if the gluster service should be stopped as part of deactivating the host. |
5.87.5. enrollcertificate POST
Enroll certificate of the host. Useful in case you get a warning that it is about to, or already expired.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the enrollment should be performed asynchronously. |
5.87.6. fence POST
Controls host’s power management device.
For example, let’s assume you want to start the host. This can be done via:
#!/bin/sh -ex
url="https://engine.example.com/ovirt-engine/api"
user="admin@internal"
password="..."
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--user "${user}:${password}" \
--request POST \
--header "Version: 4" \
--header "Content-Type: application/xml" \
--header "Accept: application/xml" \
--data '
<action>
<fence_type>start</fence_type>
</action>
' \
"${url}/hosts/123/fence"
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the fencing should be performed asynchronously. |
|
|
In |
||
|
Out |
5.87.7. forceselectspm POST
Manually set a host as the storage pool manager (SPM).
POST /ovirt-engine/api/hosts/123/forceselectspm
With a request body like this:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.87.8. get GET
Get the host details.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.87.9. install POST
Install VDSM and related software on the host. The host type defines additional parameters for the action.
Example of installing a host, using curl
and JSON, plain:
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--request PUT \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--header "Version: 4" \
--user "admin@internal:..." \
--data '
{
"root_password": "myrootpassword"
}
' \
"https://engine.example.com/ovirt-engine/api/hosts/123"
Example of installing a host, using curl
and JSON, with hosted engine components:
curl \
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--request PUT \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--header "Version: 4" \
--user "admin@internal:..." \
--data '
{
"root_password": "myrootpassword"
}
' \
"https://engine.example.com/ovirt-engine/api/hosts/123?deploy_hosted_engine=true"
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the installation should be performed asynchronously. |
|
|
In |
When set to |
|
|
In |
This |
|
|
In |
When installing an oVirt node a image ISO file is needed. |
|
|
In |
The password of of the |
|
|
In |
The SSH details used to connect to the host. |
|
|
In |
When set to |
deploy_hosted_engine
When set to true
it means this host should deploy also hosted
engine components. Missing value is treated as true
i.e deploy.
Omitting this parameter means false
and will perform no operation
in hosted engine area.
undeploy_hosted_engine
When set to true
it means this host should un-deploy hosted engine
components and this host will not function as part of the High
Availability cluster. Missing value is treated as true
i.e un-deploy
Omitting this parameter means false
and will perform no operation
in hosted engine area.
5.87.10. iscsidiscover POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the discovery should be performed asynchronously. |
|
|
In |
||
|
Out |
5.87.11. iscsilogin POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the login should be performed asynchronously. |
|
|
In |
5.87.12. refresh POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the refresh should be performed asynchronously. |
5.87.13. remove DELETE
Remove the host from the system.
#!/bin/sh -ex
url="https://engine.example.com/ovirt-engine/api"
user="admin@internal"
password="..."
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--user "${user}:${password}" \
--request DELETE \
--header "Version: 4" \
"${url}/hosts/1ff7a191-2f3b-4eff-812b-9f91a30c3acc"
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.87.14. setupnetworks POST
This method is used to change the configuration of the network interfaces of a host.
For example, lets assume that you have a host with three network interfaces eth0
, eth1
and eth2
and that
you want to configure a new bond using eth0
and eth1
, and put a VLAN on top of it. Using a simple shell
script and the curl
command line HTTP client that can be done as follows:
#!/bin/sh -ex
url="https://engine.example.com/ovirt-engine/api"
user="admin@internal"
password="..."
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--user "${user}:${password}" \
--request POST \
--header "Version: 4" \
--header "Content-Type: application/xml" \
--header "Accept: application/xml" \
--data '
<action>
<modified_bonds>
<host_nic>
<name>bond0</name>
<bonding>
<options>
<option>
<name>mode</name>
<value>4</value>
</option>
<option>
<name>miimon</name>
<value>100</value>
</option>
</options>
<slaves>
<host_nic>
<name>eth1</name>
</host_nic>
<host_nic>
<name>eth2</name>
</host_nic>
</slaves>
</bonding>
</host_nic>
</modified_bonds>
<modified_network_attachments>
<network_attachment>
<network>
<name>myvlan</name>
</network>
<host_nic>
<name>bond0</name>
</host_nic>
<ip_address_assignments>
<assignment_method>static</assignment_method>
<ip_address_assignment>
<ip>
<address>192.168.122.10</address>
<netmask>255.255.255.0</netmask>
</ip>
</ip_address_assignment>
</ip_address_assignments>
</network_attachment>
</modified_network_attachments>
</action>
' \
"${url}/hosts/1ff7a191-2f3b-4eff-812b-9f91a30c3acc/setupnetworks"
Note that this is valid for version 4 of the API. In previous versions some elements were represented as XML
attributes instead of XML elements. In particular the options
and ip
elements were represented as follows:
<options name="mode" value="4"/>
<options name="miimon" value="100"/>
<ip address="192.168.122.10" netmask="255.255.255.0"/>
Using the Python SDK the same can be done with the following code:
host.setupnetworks(
params.Action(
modified_bonds=params.HostNics(
host_nic=[
params.HostNIC(
name="bond0",
bonding=params.Bonding(
options=params.Options(
option=[
params.Option(name="mode", value="4"),
params.Option(name="miimon", value="100"),
],
),
slaves=params.Slaves(
host_nic=[
params.HostNIC(name="eth1"),
params.HostNIC(name="eth2"),
],
),
),
),
],
),
modified_network_attachments=params.NetworkAttachments(
network_attachment=[
params.NetworkAttachment(
network=params.Network(name="myvlan"),
host_nic=params.HostNIC(name="bond0"),
ip_address_assignments=params.IpAddressAssignments(
ip_address_assignment=[
params.IpAddressAssignment(
assignment_method="static",
ip=params.IP(
address="192.168.122.10",
netmask="255.255.255.0",
),
),
],
),
),
],
),
),
)
Important
|
To make sure that the network configuration has been saved in the host, and that it will be applied when the host is rebooted, remember to call commitnetconfig. |
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
5.87.15. unregisteredstoragedomainsdiscover POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the discovery should be performed asynchronously. |
|
|
In |
||
|
Out |
5.87.16. update PUT
Update the host properties.
For example, to update a the kernel command line of a host send a request like this:
PUT /ovirt-engine/api/hosts/123
With request body like this:
<host>
<os>
<custom_kernel_cmdline>vfio_iommu_type1.allow_unsafe_interrupts=1</custom_kernel_cmdline>
</os>
</host>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.88. HostDevice
Name | Summary |
---|---|
|
5.89. HostDevices
Name | Summary |
---|---|
|
5.90. HostHook
Name | Summary |
---|---|
|
5.92. HostNic
Name | Summary |
---|---|
|
|
|
The action updates virtual function configuration in case the current resource represents an SR-IOV enabled NIC. |
5.92.2. updatevirtualfunctionsconfiguration POST
The action updates virtual function configuration in case the current resource represents an SR-IOV enabled NIC. The input should be consisted of at least one of the following properties:
-
allNetworksAllowed
-
numberOfVirtualFunctions
Please see the HostNicVirtualFunctionsConfiguration
type for the meaning of the properties.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In |
5.94. HostNumaNode
Name | Summary |
---|---|
|
5.95. HostNumaNodes
Name | Summary |
---|---|
|
5.96. HostStorage
Name | Summary |
---|---|
|
5.96.1. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the status of the LUNs in the storage should be checked. |
|
|
Out |
report_status
Indicates if the status of the LUNs in the storage should be checked. Checking the status of the LUN is an heavy weight operation and this data is not always needed by the user. This parameter will give the option to not perform the status check of the LUNs.
The default is true
for backward compatibility.
Here an example with the LUN status :
<host_storage id="360014051136c20574f743bdbd28177fd">
<logical_units>
<logical_unit id="360014051136c20574f743bdbd28177fd">
<lun_mapping>0</lun_mapping>
<paths>1</paths>
<product_id>lun0</product_id>
<serial>SLIO-ORG_lun0_1136c205-74f7-43bd-bd28-177fd5ce6993</serial>
<size>10737418240</size>
<status>used</status>
<vendor_id>LIO-ORG</vendor_id>
<volume_group_id>O9Du7I-RahN-ECe1-dZ1w-nh0b-64io-MNzIBZ</volume_group_id>
</logical_unit>
</logical_units>
<type>iscsi</type>
<host id="8bb5ade5-e988-4000-8b93-dbfc6717fe50"/>
</host_storage>
Here an example without the LUN status :
<host_storage id="360014051136c20574f743bdbd28177fd">
<logical_units>
<logical_unit id="360014051136c20574f743bdbd28177fd">
<lun_mapping>0</lun_mapping>
<paths>1</paths>
<product_id>lun0</product_id>
<serial>SLIO-ORG_lun0_1136c205-74f7-43bd-bd28-177fd5ce6993</serial>
<size>10737418240</size>
<vendor_id>LIO-ORG</vendor_id>
<volume_group_id>O9Du7I-RahN-ECe1-dZ1w-nh0b-64io-MNzIBZ</volume_group_id>
</logical_unit>
</logical_units>
<type>iscsi</type>
<host id="8bb5ade5-e988-4000-8b93-dbfc6717fe50"/>
</host_storage>
5.97. Hosts
Name | Summary |
---|---|
|
Creates a new host. |
|
5.97.1. add POST
Creates a new host.
The host is created based on the attributes of the host
parameter. The name
, address
and root_password
properties are required.
For example, to add a host send the following request:
POST /ovirt-engine/api/hosts
With the following request body:
<host>
<name>myhost</name>
<address>myhost.example.com</address>
<root_password>myrootpassword</root_password>
</host>
Note
|
The root_password element is only included in the client-provided initial representation and is not
exposed in the representations returned from subsequent requests.
|
To add a hosted engine host, use the optional deploy_hosted_engine
parameter:
POST /ovirt-engine/api/hosts?deploy_hosted_engine=true
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
When set to |
|
|
In/Out |
The host definition from which to create the new host is passed as parameter, and the newly created host is returned. |
|
|
In |
When set to |
deploy_hosted_engine
When set to true
it means this host should deploy also hosted engine components. Missing value is treated
as true
i.e deploy. Omitting this parameter means false
and will perform no operation in hosted engine
area.
undeploy_hosted_engine
When set to true
it means this host should un-deploy hosted engine components and this host will not
function as part of the High Availability cluster. Missing value is treated as true
i.e un-deploy.
Omitting this parameter means false
and will perform no operation in hosted engine area.
5.97.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
||
|
In |
Sets the maximum number of hosts to return. |
|
|
In |
A query string used to restrict the returned hosts. |
5.98. Icon
Name | Summary |
---|---|
|
5.100. Image
Name | Summary |
---|---|
|
|
|
5.100.2. import POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the import should be performed asynchronously. |
|
|
In |
Cluster where the image should be imported. |
|
|
In |
The disk which should be imported. |
|
|
In |
Specify if template should be created from the imported disk. |
|
|
In |
Storage domain where disk should be imported. |
|
|
In |
Name of the template, which should be created. |
5.101. ImageTransfer
This service provides a mechanism to control an image transfer. The client will have to create a transfer by using add of the ImageTransfers service, stating the image to transfer data to/from.
After doing that, the transfer is managed by this service.
E.g., for uploading to the disk image with id 52cb593f-837c-4633-a444-35a0a0383706
,
the client can use oVirt’s Python’s SDK as follows:
transfers_service = system_service.image_transfers_service()
transfer = transfers_service.add(
types.ImageTransfer(
image=types.Image(
id='52cb593f-837c-4633-a444-35a0a0383706'
)
)
)
Transfers have phases, which govern the flow of the upload/download. A client implementing such a flow should poll/check the transfer’s phase and act accordingly. All the possible phases can be found in ImageTransferPhase.
After adding a new transfer, its phase will be initializing. The client will have to poll on the transfer’s phase until it changes. When the phase becomes transferring, the session is ready to start the transfer.
For example:
transfer_service = transfers_service.image_transfer_service(transfer.id)
while transfer.phase == types.ImageTransferPhase.INITIALIZING:
time.sleep(3)
transfer = transfer_service.get()
At that stage, if the transfer’s phase is paused_system, then the session was not successfully established. One possible reason for that is that the ovirt-imageio-daemon is not running in the host that was selected for transfer. The transfer can be resumed by calling resume of the service that manages it.
If the session was successfully established - the returned transfer entity will contain the proxy_url and signed_ticket attributes, which the client needs to use in order to transfer the required data. The client can choose whatever technique and tool for sending the HTTPS request with the image’s data.
-
proxy_url
is the address of a proxy server to the image, to do I/O to. -
signed_ticket
is the content that needs to be added to theAuthentication
header in the HTTPS request, in order to perform a trusted communication.
For example, Python’s HTTPSConnection can be used in order to perform an upload,
so an upload_headers
dict is set for the upcoming upload:
upload_headers = {
'Authorization' : transfer.signed_ticket,
}
Using Python’s HTTPSConnection
, a new connection is established:
# Extract the URI, port, and path from the transfer's proxy_url.
url = urlparse(transfer.proxy_url)
# Create a new instance of the connection.
proxy_connection = HTTPSConnection(
url.hostname,
url.port,
context=ssl.SSLContext(ssl.PROTOCOL_SSLv23)
)
The specific content range being sent must be noted in the Content-Range
HTTPS
header. This can be used in order to split the transfer into several requests for
a more flexible process.
For doing that, the client will have to repeatedly extend the transfer session
to keep the channel open. Otherwise, the session will terminate and the transfer will
get into paused_system
phase, and HTTPS requests to the server will be rejected.
E.g., the client can iterate on chunks of the file, and send them to the proxy server while asking the service to extend the session:
path = "/path/to/image"
MB_per_request = 32
with open(path, "rb") as disk:
size = os.path.getsize(path)
chunk_size = 1024*1024*MB_per_request
pos = 0
while (pos < size):
transfer_service.extend()
upload_headers['Content-Range'] = "bytes %d-%d/%d" % (pos, min(pos + chunk_size, size)-1, size)
proxy_connection.request(
'PUT',
url.path,
disk.read(chunk_size),
headers=upload_headers
)
r = proxy_connection.getresponse()
print r.status, r.reason, "Completed", "{:.0%}".format(pos/ float(size))
pos += chunk_size
When finishing the transfer, the user should call finalize. This will make the final adjustments and verifications for finishing the transfer process.
For example:
transfer_service.finalize()
In case of an error, the transfer’s phase will be changed to
finished_failure, and
the disk’s status will be changed to Illegal
. Otherwise it will be changed to
finished_success, and the disk will be ready
to be used. In both cases, the transfer entity will be removed shortly after.
Name | Summary |
---|---|
|
Extend the image transfer session. |
|
After finishing to transfer the data, finalize the transfer. |
|
Get the image transfer entity. |
|
Pause the image transfer session. |
|
Resume the image transfer session. |
5.101.2. finalize POST
After finishing to transfer the data, finalize the transfer.
This will make sure that the data being transferred is valid and fits the image entity that was targeted in the transfer. Specifically, will verify that if the image entity is a QCOW disk, the data uploaded is indeed a QCOW file, and that the image doesn’t have a backing file.
5.101.3. get GET
Get the image transfer entity.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.101.5. resume POST
Resume the image transfer session. The client will need to poll the transfer’s phase until
it is different than resuming
. For example:
transfer_service = transfers_service.image_transfer_service(transfer.id)
transfer_service.resume()
transfer = transfer_service.get()
while transfer.phase == types.ImageTransferPhase.RESUMING:
time.sleep(1)
transfer = transfer_service.get()
5.102. ImageTransfers
This service manages image transfers, for performing Image I/O API in oVirt. Please refer to image transfer for further documentation.
Name | Summary |
---|---|
|
Add a new image transfer. |
|
Retrieves the list of image transfers that are currently being performed. |
5.102.1. add POST
Add a new image transfer. An image needs to be specified in order to make a new transfer.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.104. InstanceType
Name | Summary |
---|---|
|
|
|
|
|
5.104.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.105. InstanceTypeNic
Name | Summary |
---|---|
|
|
|
|
|
5.106. InstanceTypeNics
Name | Summary |
---|---|
|
|
|
5.107. InstanceTypeWatchdog
Name | Summary |
---|---|
|
|
|
|
|
5.108. InstanceTypeWatchdogs
Name | Summary |
---|---|
|
|
|
5.109. InstanceTypes
Name | Summary |
---|---|
|
|
|
5.109.1. add POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.110. IscsiBond
Name | Summary |
---|---|
|
|
|
Removes of an exisitng iSCSI bond. |
|
Updates an iSCSI bond. |
5.110.2. remove DELETE
Removes of an exisitng iSCSI bond.
For example, to remove the iSCSI bond 456
send a request like this:
DELETE /ovirt-engine/api/datacenters/123/iscsibonds/456
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.110.3. update PUT
Updates an iSCSI bond.
Updating of an iSCSI bond can be done on the name
and the description
attributes only. For example, to
update the iSCSI bond 456
of data center 123
, send a request like this:
PUT /ovirt-engine/api/datacenters/123/iscsibonds/1234
The request body should look like this:
<iscsi_bond>
<name>mybond</name>
<description>My iSCSI bond</description>
</iscsi_bond>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.111. IscsiBonds
Name | Summary |
---|---|
|
Create a new iSCSI bond on a data center. |
|
5.111.1. add POST
Create a new iSCSI bond on a data center.
For example, to create a new iSCSI bond on data center 123
using storage connections 456
and 789
, send a
request like this:
POST /ovirt-engine/api/datacenters/123/iscsibonds
The request body should look like this:
<iscsi_bond>
<name>mybond</name>
<storage_connections>
<storage_connection id="456"/>
<storage_connection id="789"/>
</storage_connections>
<networks>
<network id="abc"/>
</networks>
</iscsi_bond>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.112. Job
Name | Summary |
---|---|
|
|
|
|
|
5.112.1. clear POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.112.2. end POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
5.113. Jobs
Name | Summary |
---|---|
|
|
|
5.114. KatelloErrata
Name | Summary |
---|---|
|
5.115. KatelloErratum
Name | Summary |
---|---|
|
5.116. MacPool
Name | Summary |
---|---|
|
|
|
Removes a MAC address pool. |
|
Updates a MAC address pool. |
5.116.2. remove DELETE
Removes a MAC address pool.
For example, to remove the MAC address pool having id 123
send a request like this:
DELETE /ovirt-engine/api/macpools/123
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.116.3. update PUT
Updates a MAC address pool.
The name
, description
, allow_duplicates
, and ranges
attributes can be updated.
For example, to update the MAC address pool of id 123
send a request like this:
PUT /ovirt-engine/api/macpools/123
With a request body like this:
<mac_pool>
<name>UpdatedMACPool</name>
<description>An updated MAC address pool</description>
<allow_duplicates>false</allow_duplicates>
<ranges>
<range>
<from>00:1A:4A:16:01:51</from>
<to>00:1A:4A:16:01:e6</to>
</range>
<range>
<from>02:1A:4A:01:00:00</from>
<to>02:1A:4A:FF:FF:FF</to>
</range>
</ranges>
</mac_pool>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.117. MacPools
Name | Summary |
---|---|
|
Creates a new MAC address pool. |
|
5.117.1. add POST
Creates a new MAC address pool.
Creation of a MAC address pool requires values for the name
and ranges
attributes.
For example, to create MAC address pool send a request like this:
POST /ovirt-engine/api/macpools
With a request body like this:
<mac_pool>
<name>MACPool</name>
<description>A MAC address pool</description>
<allow_duplicates>true</allow_duplicates>
<default_pool>false</default_pool>
<ranges>
<range>
<from>00:1A:4A:16:01:51</from>
<to>00:1A:4A:16:01:e6</to>
</range>
</ranges>
</mac_pool>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.119. Moveable
Name | Summary |
---|---|
|
5.120. Network
Name | Summary |
---|---|
|
|
|
Removes a logical network, or the association of a logical network to a data center. |
|
Updates a logical network. |
5.120.2. remove DELETE
Removes a logical network, or the association of a logical network to a data center.
For example, to remove the logical network 123
send a request like this:
DELETE /ovirt-engine/api/networks/123
Each network is bound exactly to one data center. So if we disassociate network with data center it has the same
result as if we would just remove that network. However it might be more specific to say we’re removing network
456
of data center 123
.
For example, to remove the association of network 456
to data center 123
send a request like this:
DELETE /ovirt-engine/api/datacenters/123/networks/456
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.120.3. update PUT
Updates a logical network.
The name
, description
, ip
, vlan
, stp
and display
attributes can be updated.
For example, to update the description of the logcial network 123
send a request like this:
PUT /ovirt-engine/api/networks/123
With a request body like this:
<network>
<description>My updated description</description>
</network>
The maximum transmission unit of a network is set using a PUT request to
specify the integer value of the mtu
attribute.
For example, to set the maximum transmission unit send a request like this:
PUT /ovirt-engine/api/datacenters/123/networks/456
With a request body like this:
<network>
<mtu>1500</mtu>
</network>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.121. NetworkAttachment
Name | Summary |
---|---|
|
|
|
|
|
5.121.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.122. NetworkAttachments
Name | Summary |
---|---|
|
|
|
5.123. NetworkFilter
Manages a network filter.
<network_filter id="00000019-0019-0019-0019-00000000026b">
<name>example-network-filter-b</name>
<version>
<major>4</major>
<minor>0</minor>
<build>-1</build>
<revision>-1</revision>
</version>
</network_filter>
Please note that version is referring to the minimal support version for the specific filter.
Name | Summary |
---|---|
|
Retrieves a representation of the network filter. |
5.124. NetworkFilters
Represents a readonly network filters sub-collection.
The network filter enables to filter packets send to/from the VM’s nic according to defined rules. For more information please refer to NetworkFilter service documentation
Network filters are supported in different versions, starting from version 3.0.
A network filter is defined for each vnic profile.
A vnic profile is defined for a specific network.
A network can be assigned to several different clusters. In the future, each network will be defined in cluster level.
Currently, each network is being defined at data center level. Potential network filters for each network are determined by the network’s data center compatibility version V. V must be >= the network filter version in order to configure this network filter for a specific network. Please note, that if a network is assigned to cluster with a version supporting a network filter, the filter may not be available due to the data center version being smaller then the network filter’s version.
Example of listing all of the supported network filters for a specific cluster:
GET http://localhost:8080/ovirt-engine/api/clusters/{cluster:id}/networkfilters
Output:
<network_filters>
<network_filter id="00000019-0019-0019-0019-00000000026c">
<name>example-network-filter-a</name>
<version>
<major>4</major>
<minor>0</minor>
<build>-1</build>
<revision>-1</revision>
</version>
</network_filter>
<network_filter id="00000019-0019-0019-0019-00000000026b">
<name>example-network-filter-b</name>
<version>
<major>4</major>
<minor>0</minor>
<build>-1</build>
<revision>-1</revision>
</version>
</network_filter>
<network_filter id="00000019-0019-0019-0019-00000000026a">
<name>example-network-filter-a</name>
<version>
<major>3</major>
<minor>0</minor>
<build>-1</build>
<revision>-1</revision>
</version>
</network_filter>
</network_filters>
Name | Summary |
---|---|
|
Retrieves the representations of the network filters. |
5.125. NetworkLabel
Name | Summary |
---|---|
|
|
|
Removes a label from a logical network. |
5.125.2. remove DELETE
Removes a label from a logical network.
For example, to remove the label exemplary
from a logical network having id 123
send the following request:
DELETE /ovirt-engine/api/networks/123/labels/exemplary
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.126. NetworkLabels
Name | Summary |
---|---|
|
Attaches label to logical network. |
|
5.126.1. add POST
Attaches label to logical network.
You can attach labels to a logical network to automate the association of that logical network with physical host network interfaces to which the same label has been attached.
For example, to attach the label mylabel
to a logical network having id 123
send a request like this:
POST /ovirt-engine/api/networks/123/labels
With a request body like this:
<label id="mylabel"/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.127. Networks
Manages logical networks.
The engine creates a default ovirtmgmt
network on installation. This network acts as the management network for
access to hypervisor hosts. This network is associated with the Default
cluster and is a member of the Default
data center.
Name | Summary |
---|---|
|
Creates a new logical network, or associates an existing network with a data center. |
|
List logical networks. |
5.127.1. add POST
Creates a new logical network, or associates an existing network with a data center.
Creation of a new network requires the name
and data_center
elements.
For example, to create a network named mynetwork
for data center 123
send a request like this:
POST /ovirt-engine/api/networks
With a request body like this:
<network>
<name>mynetwork</name>
<data_center id="123"/>
</network>
To associate the existing network 456
with the data center 123
send a request like this:
POST /ovirt-engine/api/datacenters/123/networks
With a request body like this:
<network>
<name>ovirtmgmt</name>
</network>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.127.2. list GET
List logical networks.
For example:
GET /ovirt-engine/api/networks
Will respond:
<networks>
<network href="/ovirt-engine/api/networks/123" id="123">
<name>ovirtmgmt</name>
<description>Default Management Network</description>
<link href="/ovirt-engine/api/networks/123/permissions" rel="permissions"/>
<link href="/ovirt-engine/api/networks/123/vnicprofiles" rel="vnicprofiles"/>
<link href="/ovirt-engine/api/networks/123/networklabels" rel="networklabels"/>
<mtu>0</mtu>
<stp>false</stp>
<usages>
<usage>vm</usage>
</usages>
<data_center href="/ovirt-engine/api/datacenters/456" id="456"/>
</network>
...
</networks>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Sets the maximum number of networks to return. |
|
|
Out |
||
|
In |
A query string used to restrict the returned networks. |
5.128. OpenstackImage
Name | Summary |
---|---|
|
|
|
Imports a virtual machine from a Glance image storage domain. |
5.128.2. import POST
Imports a virtual machine from a Glance image storage domain.
For example, to import the image with identifier 456
from the
storage domain with identifier 123
send a request like this:
POST /ovirt-engine/api/openstackimageproviders/123/images/456/import
With a request body like this:
<action>
<storage_domain>
<name>images0</name>
</storage_domain>
<cluster>
<name>images0</name>
</cluster>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the import should be performed asynchronously. |
|
|
In |
This parameter is mandatory in case of using |
|
|
In |
||
|
In |
Indicates whether the image should be imported as a template. |
|
|
In |
||
|
In |
5.129. OpenstackImageProvider
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
5.129.2. importcertificates POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
5.129.3. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.129.4. testconnectivity POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the test should be performed asynchronously. |
5.130. OpenstackImageProviders
Name | Summary |
---|---|
|
|
|
5.131. OpenstackImages
Name | Summary |
---|---|
|
Lists the images of a Glance image storage domain. |
5.132. OpenstackNetwork
Name | Summary |
---|---|
|
|
|
This operation imports an external network into oVirt. |
5.132.2. import POST
This operation imports an external network into oVirt. The network will be added to the data center specified.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the import should be performed asynchronously. |
|
|
In |
The data center into which the network is to be imported. |
5.133. OpenstackNetworkProvider
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
5.133.2. importcertificates POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
5.133.3. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.133.4. testconnectivity POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the test should be performed asynchronously. |
5.134. OpenstackNetworkProviders
Name | Summary |
---|---|
|
The operation adds a new network provider to the system. |
|
5.134.1. add POST
The operation adds a new network provider to the system.
If the type
property is not present, a default value of NEUTRON
will be used.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.135. OpenstackNetworks
Name | Summary |
---|---|
|
5.136. OpenstackSubnet
Name | Summary |
---|---|
|
|
|
5.137. OpenstackSubnets
Name | Summary |
---|---|
|
|
|
5.138. OpenstackVolumeAuthenticationKey
Name | Summary |
---|---|
|
|
|
|
|
5.138.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.139. OpenstackVolumeAuthenticationKeys
Name | Summary |
---|---|
|
|
|
5.140. OpenstackVolumeProvider
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
5.140.2. importcertificates POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
5.140.3. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.140.4. testconnectivity POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the test should be performed asynchronously. |
5.141. OpenstackVolumeProviders
Name | Summary |
---|---|
|
Adds a new volume provider. |
|
Retrieves the list of volume providers. |
5.141.1. add POST
Adds a new volume provider.
For example:
POST /ovirt-engine/api/openstackvolumeproviders
With a request body like this:
<openstack_volume_provider>
<name>mycinder</name>
<url>https://mycinder.example.com:8776</url>
<data_center>
<name>mydc</name>
</data_center>
<requires_authentication>true</requires_authentication>
<username>admin</username>
<password>mypassword</password>
<tenant_name>mytenant</tenant_name>
</openstack_volume_provider>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.142. OpenstackVolumeType
Name | Summary |
---|---|
|
5.143. OpenstackVolumeTypes
Name | Summary |
---|---|
|
5.144. OperatingSystem
Name | Summary |
---|---|
|
5.145. OperatingSystems
Name | Summary |
---|---|
|
5.146. Permission
Name | Summary |
---|---|
|
|
|
5.147. Permit
Name | Summary |
---|---|
|
|
|
5.148. Permits
Name | Summary |
---|---|
|
Adds a permit to the set aggregated by parent role. |
|
5.149. Qos
Name | Summary |
---|---|
|
|
|
|
|
5.150. Qoss
Name | Summary |
---|---|
|
|
|
5.151. Quota
Name | Summary |
---|---|
|
Retrieves a quota. |
|
Delete a quota. |
|
Updates a quota. |
5.151.1. get GET
Retrieves a quota.
An example of retrieving a quota:
GET /ovirt-engine/api/datacenters/123/quotas/456
<quota id="456">
<name>myquota</name>
<description>My new quota for virtual machines</description>
<cluster_hard_limit_pct>20</cluster_hard_limit_pct>
<cluster_soft_limit_pct>80</cluster_soft_limit_pct>
<storage_hard_limit_pct>20</storage_hard_limit_pct>
<storage_soft_limit_pct>80</storage_soft_limit_pct>
</quota>
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.151.2. remove DELETE
Delete a quota.
An example of deleting a quota:
DELETE /ovirt-engine/api/datacenters/123-456/quotas/654-321
-0472718ab224 HTTP/1.1
Accept: application/xml
Content-type: application/xml
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.151.3. update PUT
Updates a quota.
An example of updating a quota:
PUT /ovirt-engine/api/datacenters/123/quotas/456
<quota>
<cluster_hard_limit_pct>30</cluster_hard_limit_pct>
<cluster_soft_limit_pct>70</cluster_soft_limit_pct>
<storage_hard_limit_pct>20</storage_hard_limit_pct>
<storage_soft_limit_pct>80</storage_soft_limit_pct>
</quota>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.152. QuotaClusterLimit
Name | Summary |
---|---|
|
|
|
5.153. QuotaClusterLimits
Name | Summary |
---|---|
|
|
|
5.154. QuotaStorageLimit
Name | Summary |
---|---|
|
|
|
5.155. QuotaStorageLimits
Name | Summary |
---|---|
|
|
|
5.156. Quotas
Name | Summary |
---|---|
|
Creates a new quota. |
|
Lists quotas of a data center |
5.156.1. add POST
Creates a new quota.
An example of creating a new quota:
POST /ovirt-engine/api/datacenters/123/quotas
<quota>
<name>myquota</name>
<description>My new quota for virtual machines</description>
</quota>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.157. Role
Name | Summary |
---|---|
|
|
|
Removes the role. |
|
Updates a role. |
5.157.2. remove DELETE
Removes the role.
To remove the role you need to know its id, then send request like this:
DELETE /ovirt-engine/api/roles/{role_id}
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.157.3. update PUT
Updates a role. You are allowed to update name
, description
and administrative
attributes after role is
created. Within this endpoint you can’t add or remove roles permits you need to use
service that manages permits of role.
For example to update role’s name
, description
and administrative
attributes send a request like this:
PUT /ovirt-engine/api/roles/123
With a request body like this:
<role>
<name>MyNewRoleName</name>
<description>My new description of the role</description>
<administrative>true</administrative>
</group>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.158. Roles
Provides read-only access to the global set of roles
Name | Summary |
---|---|
|
Create a new role. |
|
5.158.1. add POST
Create a new role. The role can be administrative or non-administrative and can have different permits.
For example, to add the MyRole
non-administrative role with permits to login and create virtual machines
send a request like this (note that you have to pass permit id):
POST /ovirt-engine/api/roles
With a request body like this:
<role>
<name>MyRole</name>
<description>My custom role to create virtual machines</description>
<administrative>false</administrative>
<permits>
<permit id="1"/>
<permit id="1300"/>
</permits>
</group>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.159. SchedulingPolicies
Name | Summary |
---|---|
|
|
|
5.160. SchedulingPolicy
Name | Summary |
---|---|
|
|
|
|
|
5.160.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.160.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.161. SchedulingPolicyUnit
Name | Summary |
---|---|
|
|
|
5.161.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.162. SchedulingPolicyUnits
Name | Summary |
---|---|
|
5.163. Snapshot
Name | Summary |
---|---|
|
|
|
|
|
Restores a virtual machine snapshot. |
5.163.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.163.3. restore POST
Restores a virtual machine snapshot.
For example, to restore the snapshot with identifier 456
of virtual machine with identifier 123
send a
request like this:
POST /ovirt-engine/api/vms/123/snapshots/456/restore
With an empty action
in the body:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the restore should be performed asynchronously. |
|
|
In |
||
|
In |
5.164. SnapshotCdrom
Name | Summary |
---|---|
|
5.166. SnapshotDisk
Name | Summary |
---|---|
|
5.168. SnapshotNic
Name | Summary |
---|---|
|
5.170. Snapshots
Name | Summary |
---|---|
|
Creates a virtual machine snapshot. |
|
5.170.1. add POST
Creates a virtual machine snapshot.
For example, to create a new snapshot for virtual machine 123
send a request like this:
POST /ovirt-engine/api/vms/123/snapshots
With a request body like this:
<snapshot>
<description>My snapshot</description>
</snapshot>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.171. SshPublicKey
Name | Summary |
---|---|
|
|
|
|
|
5.171.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.172. SshPublicKeys
Name | Summary |
---|---|
|
|
|
5.173. Statistic
Name | Summary |
---|---|
|
5.174. Statistics
Name | Summary |
---|---|
|
5.175. Step
Name | Summary |
---|---|
|
|
|
5.175.1. end POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
||
|
In |
5.176. Steps
Name | Summary |
---|---|
|
|
|
5.177. Storage
Name | Summary |
---|---|
|
5.177.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the status of the LUNs in the storage should be checked. |
|
|
Out |
report_status
Indicates if the status of the LUNs in the storage should be checked. Checking the status of the LUN is an heavy weight operation and this data is not always needed by the user. This parameter will give the option to not perform the status check of the LUNs.
The default is true
for backward compatibility.
Here an example with the LUN status :
<host_storage id="360014051136c20574f743bdbd28177fd">
<logical_units>
<logical_unit id="360014051136c20574f743bdbd28177fd">
<lun_mapping>0</lun_mapping>
<paths>1</paths>
<product_id>lun0</product_id>
<serial>SLIO-ORG_lun0_1136c205-74f7-43bd-bd28-177fd5ce6993</serial>
<size>10737418240</size>
<status>used</status>
<vendor_id>LIO-ORG</vendor_id>
<volume_group_id>O9Du7I-RahN-ECe1-dZ1w-nh0b-64io-MNzIBZ</volume_group_id>
</logical_unit>
</logical_units>
<type>iscsi</type>
<host id="8bb5ade5-e988-4000-8b93-dbfc6717fe50"/>
</host_storage>
Here an example without the LUN status :
<host_storage id="360014051136c20574f743bdbd28177fd">
<logical_units>
<logical_unit id="360014051136c20574f743bdbd28177fd">
<lun_mapping>0</lun_mapping>
<paths>1</paths>
<product_id>lun0</product_id>
<serial>SLIO-ORG_lun0_1136c205-74f7-43bd-bd28-177fd5ce6993</serial>
<size>10737418240</size>
<vendor_id>LIO-ORG</vendor_id>
<volume_group_id>O9Du7I-RahN-ECe1-dZ1w-nh0b-64io-MNzIBZ</volume_group_id>
</logical_unit>
</logical_units>
<type>iscsi</type>
<host id="8bb5ade5-e988-4000-8b93-dbfc6717fe50"/>
</host_storage>
5.178. StorageDomain
Name | Summary |
---|---|
|
|
|
|
|
This operation refreshes the LUN size. |
|
Removes the storage domain. |
|
Updates a storage domain. |
|
This operation forces the update of the |
5.178.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.178.2. isattached POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
||
|
Out |
5.178.3. refreshluns POST
This operation refreshes the LUN size.
After increasing the size of the underlying LUN on the storage server, the user can refresh the LUN size. This action forces a rescan of the provided LUNs and updates the database with the new size if required.
For example, in order to refresh the size of two LUNs send a request like this:
POST /ovirt-engine/api/storagedomains/262b056b-aede-40f1-9666-b883eff59d40/refreshluns
With a request body like this:
<action>
<logical_units>
<logical_unit id="1IET_00010001"/>
<logical_unit id="1IET_00010002"/>
</logical_units>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the refresh should be performed asynchronously. |
|
|
In |
The LUNs that need to be refreshed. |
5.178.4. remove DELETE
Removes the storage domain.
Without any special parameters, the storage domain is detached from the system and removed from the database. The storage domain can then be imported to the same or different setup, with all the data on it. If the storage isn’t accessible the operation will fail.
If the destroy
parameter is true
then the operation will always succeed, even if the storage isn’t
accessible, the failure is just ignored and the storage domain is removed from the database anyway.
If the format
parameter is true
then the actual storage is formatted, and the metadata is removed from the
LUN or directory, so it can no longer be imported to the same or a different setup.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
|
|
In |
Indicates if the operation should succeed, and the storage domain removed from the database, even if the storage isn’t accessible. |
|
|
In |
Indicates if the actual storage should be formatted, removing all the metadata from the underlying LUN or directory: [source] ---- DELETE /ovirt-engine/api/storagedomains/123?format=true ---- This parameter is optional, and the default value is |
|
|
In |
Indicates what host should be used to remove the storage domain. |
destroy
Indicates if the operation should succeed, and the storage domain removed from the database, even if the storage isn’t accessible.
DELETE /ovirt-engine/api/storagedomains/123?destroy=true
This parameter is optional, and the default value is false
.
host
Indicates what host should be used to remove the storage domain.
This parameter is mandatory, and it can contain the name or the identifier of the host. For example, to use
the host named myhost
to remove the storage domain with identifier 123
send a request like this:
DELETE /ovirt-engine/api/storagedomains/123?host=myhost
5.178.5. update PUT
Updates a storage domain.
Not all of the StorageDomain's attributes are updatable post-creation. Those that can be
updated are: name
, description
, comment
, warning_low_space_indicator
, critical_space_action_blocker
and
wipe_after_delete
(note that changing the wipe_after_delete
attribute will not change the wipe after delete
property of disks that already exist).
To update the name
and wipe_after_delete
attributes of a storage domain with an identifier 123
, send a
request as follows:
PUT /ovirt-engine/api/storagedomains/123
With a request body as follows:
<storage_domain>
<name>data2</name>
<wipe_after_delete>true</wipe_after_delete>
</storage_domain>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.178.6. updateovfstore POST
This operation forces the update of the OVF_STORE
of this storage domain.
The OVF_STORE
is a disk image that contains the meta-data
of virtual machines and disks that reside in the
storage domain. This meta-data is used in case the
domain is imported or exported to or from a different
data center or a different installation.
By default the OVF_STORE
is updated periodically
(set by default to 60 minutes) but users might want to force an
update after an important change, or when the they believe the
OVF_STORE
is corrupt.
When initiated by the user, OVF_STORE
update will be performed whether
an update is needed or not.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the |
5.180. StorageDomainContentDisks
Name | Summary |
---|---|
|
5.180.1. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
Out |
||
|
In |
Sets the maximum number of disks to return. |
|
|
In |
A query string used to restrict the returned disks. |
5.181. StorageDomainServerConnection
Name | Summary |
---|---|
|
|
|
Detaches a storage connection from storage. |
5.182. StorageDomainServerConnections
Name | Summary |
---|---|
|
|
|
5.183. StorageDomainTemplate
Name | Summary |
---|---|
|
|
|
|
|
|
|
5.183.2. import POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the import should be performed asynchronously. |
|
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
||
|
In |
5.183.3. register POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the registration should be performed asynchronously. |
|
|
In |
||
|
In |
||
|
In |
||
|
In |
5.184. StorageDomainTemplates
Name | Summary |
---|---|
|
5.185. StorageDomainVm
Name | Summary |
---|---|
|
|
|
Imports a virtual machine from an export storage domain. |
|
|
|
Deletes a virtual machine from an export storage domain. |
5.185.2. import POST
Imports a virtual machine from an export storage domain.
For example, send a request like this:
POST /ovirt-engine/api/storagedomains/123/vms/456/import
With a request body like this:
<action>
<storage_domain>
<name>mydata</name>
</storage_domain>
<cluster>
<name>mycluster</name>
</cluster>
</action>
To import a virtual machine as a new entity add the clone
parameter:
<action>
<storage_domain>
<name>mydata</name>
</storage_domain>
<cluster>
<name>mycluster</name>
</cluster>
<clone>true</clone>
<vm>
<name>myvm</name>
</vm>
</action>
Include an optional disks
parameter to choose which disks to import. For example, to import the disks
of the template that have the identifiers 123
and 456
send the following request body:
<action>
<cluster>
<name>mycluster</name>
</cluster>
<vm>
<name>myvm</name>
</vm>
<disks>
<disk id="123"/>
<disk id="456"/>
</disks>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the import should be performed asynchronously. |
|
|
In |
Indicates if the identifiers of the imported virtual machine should be regenerated. |
|
|
In |
||
|
In |
Indicates of the snapshots of the virtual machine that is imported should be collapsed, so that the result will be a virtual machine without snapshots. |
|
|
In |
||
|
In |
clone
Indicates if the identifiers of the imported virtual machine should be regenerated.
By default when a virtual machine is imported the identifiers
are preserved. This means that the same virtual machine can’t
be imported multiple times, as that identifiers needs to be
unique. To allow importing the same machine multiple times set
this parameter to true
, as the default is false
.
5.185.3. register POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the registration should be performed asynchronously. |
|
|
In |
||
|
In |
||
|
In |
5.185.4. remove DELETE
Deletes a virtual machine from an export storage domain.
For example, to delete the virtual machine 456
from the storage domain 123
, send a request like this:
DELETE /ovirt-engine/api/storagedomains/123/vms/456
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.186. StorageDomainVmDiskAttachment
Returns the details of the disks attached to a virtual machine in the export domain.
Name | Summary |
---|---|
|
Returns the details of the attachment with all its properties and a link to the disk. |
5.187. StorageDomainVmDiskAttachments
Returns the details of a disk attached to a virtual machine in the export domain.
Name | Summary |
---|---|
|
List the disks that are attached to the virtual machine. |
5.188. StorageDomainVms
Lists the virtual machines of an export storage domain.
For example, to retrieve the virtual machines that are available in the storage domain with identifier 123
send the
following request:
GET /ovirt-engine/api/storagedomains/123/vms
This will return the following response body:
<vms>
<vm id="456" href="/api/storagedomains/123/vms/456">
<name>vm1</name>
...
<storage_domain id="123" href="/api/storagedomains/123"/>
<actions>
<link rel="import" href="/api/storagedomains/123/vms/456/import"/>
</actions>
</vm>
</vms>
Virtual machines and templates in these collections have a similar representation to their counterparts in the top-level Vm and Template collections, except they also contain a StorageDomain reference and an import action.
Name | Summary |
---|---|
|
5.189. StorageDomains
Name | Summary |
---|---|
|
Adds a new storage domain. |
|
5.189.1. add POST
Adds a new storage domain.
Creation of a new StorageDomain requires the name
, type
, host
and storage
attributes. Identify the host
attribute with the id
or name
attributes. In oVirt 3.6 and later 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.
To add a new storage domain with specified name
, type
, storage.type
, storage.address
and storage.path
and by using a host with an id 123
, send a request as follows:
POST /ovirt-engine/api/storagedomains
With a request body as follows:
<storage_domain>
<name>mydata</name>
<type>data</type>
<storage>
<type>nfs</type>
<address>mynfs.example.com</address>
<path>/exports/mydata</path>
</storage>
<host>
<name>myhost</name>
</host>
</storage_domain>
To create a new NFS ISO storage domain send a request like this:
<storage_domain>
<name>myisos</name>
<type>iso</type>
<storage>
<type>nfs</type>
<address>mynfs.example.com</address>
<path>/export/myisos</path>
</storage>
<host>
<name>myhost</name>
</host>
</storage_domain>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.189.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
Sets the maximum number of storage domains to return. |
|
|
In |
A query string used to restrict the returned storage domains. |
|
|
Out |
5.190. StorageServerConnection
Name | Summary |
---|---|
|
|
|
Removes a storage connection. |
|
Updates the storage connection. |
5.190.2. remove DELETE
Removes a storage connection.
A storage connection can only be deleted if neither storage domain nor LUN disks reference it. The host name or id is optional; providing it disconnects (unmounts) the connection from that host.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
|
|
In |
The name or identifier of the host from which the connection would be unmounted (disconnected). |
host
The name or identifier of the host from which the connection would be unmounted (disconnected). If not provided, no host will be disconnected.
For example, to use the host with identifier 456
to delete the storage connection with identifier 123
send a request like this:
DELETE /ovirt-engine/api/storageconnections/123?host=456
5.190.3. update PUT
Updates the storage connection.
For example, to change the address of the storage server send a request like this:
PUT /ovirt-engine/api/storageconnections/123
With a request body like this:
<storage_connection>
<address>mynewnfs.example.com</address>
<host>
<name>myhost</name>
</host>
</storage_connection>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
||
|
In |
Indicates if the operation should succeed regardless to the relevant storage domain’s status (i. |
5.191. StorageServerConnectionExtension
Name | Summary |
---|---|
|
|
|
|
|
Update a storage server connection extension for the given host. |
5.191.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.191.3. update PUT
Update a storage server connection extension for the given host.
To update the storage connection 456
of host 123
send a request like this:
PUT /ovirt-engine/api/hosts/123/storageconnectionextensions/456
With a request body like this:
<storage_connection_extension>
<target>iqn.2016-01.com.example:mytarget</target>
<username>myuser</username>
<password>mypassword</password>
</storage_connection_extension>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.192. StorageServerConnectionExtensions
Name | Summary |
---|---|
|
Creates a new storage server connection extension for the given host. |
|
5.192.1. add POST
Creates a new storage server connection extension for the given host.
The extension lets the user define credentials for an iSCSI target for a specific host. For example to use
myuser
and mypassword
as the credentials when connecting to the iSCSI target from host 123
send a request
like this:
POST /ovirt-engine/api/hosts/123/storageconnectionextensions
With a request body like this:
<storage_connection_extension>
<target>iqn.2016-01.com.example:mytarget</target>
<username>myuser</username>
<password>mypassword</password>
</storage_connection_extension>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.193. StorageServerConnections
Name | Summary |
---|---|
|
Creates a new storage connection. |
|
5.193.1. add POST
Creates a new storage connection.
For example, to create a new storage connection for the NFS server mynfs.example.com
and NFS share
/export/mydata
send a request like this:
POST /ovirt-engine/api/storageconnections
With a request body like this:
<storage_connection>
<type>nfs</type>
<address>mynfs.example.com</address>
<path>/export/mydata</path>
<host>
<name>myhost</name>
</host>
</storage_connection>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.194. System
Name | Summary |
---|---|
|
Returns basic information describing the API, like the product name, the version number and a summary of the number of relevant objects. |
|
5.194.1. get GET
Returns basic information describing the API, like the product name, the version number and a summary of the number of relevant objects.
GET /ovirt-engine/api
We get following response:
<api>
<link rel="capabilities" href="/api/capabilities"/>
<link rel="clusters" href="/api/clusters"/>
<link rel="clusters/search" href="/api/clusters?search={query}"/>
<link rel="datacenters" href="/api/datacenters"/>
<link rel="datacenters/search" href="/api/datacenters?search={query}"/>
<link rel="events" href="/api/events"/>
<link rel="events/search" href="/api/events?search={query}"/>
<link rel="hosts" href="/api/hosts"/>
<link rel="hosts/search" href="/api/hosts?search={query}"/>
<link rel="networks" href="/api/networks"/>
<link rel="roles" href="/api/roles"/>
<link rel="storagedomains" href="/api/storagedomains"/>
<link rel="storagedomains/search" href="/api/storagedomains?search={query}"/>
<link rel="tags" href="/api/tags"/>
<link rel="templates" href="/api/templates"/>
<link rel="templates/search" href="/api/templates?search={query}"/>
<link rel="users" href="/api/users"/>
<link rel="groups" href="/api/groups"/>
<link rel="domains" href="/api/domains"/>
<link rel="vmpools" href="/api/vmpools"/>
<link rel="vmpools/search" href="/api/vmpools?search={query}"/>
<link rel="vms" href="/api/vms"/>
<link rel="vms/search" href="/api/vms?search={query}"/>
<product_info>
<name>oVirt Engine</name>
<vendor>ovirt.org</vendor>
<version>
<build>4</build>
<full_version>4.0.4</full_version>
<major>4</major>
<minor>0</minor>
<revision>0</revision>
</version>
</product_info>
<special_objects>
<blank_template href="/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000"/>
<root_tag href="/ovirt-engine/api/tags/00000000-0000-0000-0000-000000000000" id="00000000-0000-0000-0000-000000000000"/>
</special_objects>
<summary>
<hosts>
<active>0</active>
<total>0</total>
</hosts>
<storage_domains>
<active>0</active>
<total>1</total>
</storage_domains>
<users>
<active>1</active>
<total>1</total>
</users>
<vms>
<active>0</active>
<total>0</total>
</vms>
</summary>
<time>2016-09-14T12:00:48.132+02:00</time>
</api>
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 entry point also contains other data such as product_info
,
special_objects
and summary
.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.195. SystemPermissions
This service doesn’t add any new methods, it is just a placeholder for the annotation that specifies the path of the resource that manages the permissions assigned to the system object.
Name | Summary |
---|---|
|
|
|
5.196. Tag
Name | Summary |
---|---|
|
|
|
|
|
5.197. Tags
Name | Summary |
---|---|
|
|
|
5.198. Template
Name | Summary |
---|---|
|
Exports a template to the data center export domain. |
|
|
|
Removas a virtual machine template. |
|
Updates the template. |
5.198.1. export POST
Exports a template to the data center export domain.
For example, the operation can be facilitated using the following request:
POST /ovirt-engine/api/templates/123/export
With a request body like this:
<action>
<storage_domain id="456"/>
<exclusive>true<exclusive/>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the existing templates with the same name should be overwritten. |
|
|
In |
Specifies the destination export storage domain. |
5.198.2. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.198.3. remove DELETE
Removas a virtual machine template.
DELETE /ovirt-engine/api/templates/123
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.198.4. update PUT
Updates the template.
The name
, description
, type
, memory
, cpu
, topology
, os
, high_availability
, display
,
stateless
, usb
and timezone
elements can be updated after a template has been created.
For example, to update a template to so that it has 1 GiB of memory send a request like this:
PUT /ovirt-engine/api/templates/123
With the following request body:
<template>
<memory>1073741824</memory>
</template>
The version_name
name attribute is the only one that can be updated within the version
attribute used for
template versions:
<template>
<version>
<version_name>mytemplate_2</version_name>
</version>
</template>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.199. TemplateCdrom
Name | Summary |
---|---|
|
5.201. TemplateDisk
Name | Summary |
---|---|
|
|
|
|
|
|
|
5.201.1. copy POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the copy should be performed asynchronously. |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
5.201.2. export POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the export should be performed asynchronously. |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
5.202. TemplateDiskAttachment
This service manages the attachment of a disk to a template.
Name | Summary |
---|---|
|
Returns the details of the attachment. |
|
Removes the disk from the template. |
5.202.1. get GET
Returns the details of the attachment.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
5.202.2. remove DELETE
Removes the disk from the template. The disk will only be removed if there are other existing copies of the disk on other storage domains.
A storage domain has to be specified to determine which of the copies should be removed (template disks can have copies on multiple storage domains).
DELETE /ovirt-engine/api/templates/{template:id}/diskattachments/{attachment:id}?storage_domain=072fbaa1-08f3-4a40-9f34-a5ca22dd1d74
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
||
|
In |
Specifies the identifier of the storage domain the image to be removed resides on. |
5.203. TemplateDiskAttachments
This service manages the set of disks attached to a template. Each attached disk is represented by a DiskAttachment.
Name | Summary |
---|---|
|
List the disks that are attached to the template. |
5.205. TemplateNic
Name | Summary |
---|---|
|
|
|
|
|
5.206. TemplateNics
Name | Summary |
---|---|
|
|
|
5.207. TemplateWatchdog
Name | Summary |
---|---|
|
|
|
|
|
5.208. TemplateWatchdogs
Name | Summary |
---|---|
|
|
|
5.209. Templates
Name | Summary |
---|---|
|
Creates a new template. |
|
5.209.1. add POST
Creates a new template.
This requires the name
and vm
elements. Identify the virtual machine with the id
name
attributes.
POST /ovirt-engine/api/templates
With a request body like this:
<template>
<name>mytemplate</name>
<vm id="123"/>
</template>
The template can be created as a sub version of an existing template.This requires the name
and vm
attributes
for the new template, and the base_template
and version_name
attributes for the new template version. The
base_template
and version_name
attributes must be specified within a version
section enclosed in the
template
section. Identify the virtual machine with the id
or name
attributes.
<template>
<name>mytemplate</name>
<vm id="123"/>
<version>
<base_template id="456"/>
<version_name>mytemplate_001</version_name>
</version>
</template>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Specifies if the permissions of the virtual machine should be copied to the template. |
|
|
In/Out |
clone_permissions
Specifies if the permissions of the virtual machine should be copied to the template.
If this optional parameter is provided, and its values is true
then the permissions of the virtual machine
(only the direct ones, not the inherited ones) will be copied to the created template. For example, to create
a template from the myvm
virtual machine copying its permissions, send a request like this:
POST /ovirt-engine/api/templates?clone_permissions=true
With a request body like this:
<template>
<name>mytemplate<name>
<vm>
<name>myvm<name>
</vm>
</template>
5.209.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
Sets the maximum number of templates to return. |
|
|
In |
A query string used to restrict the returned templates. |
|
|
Out |
5.210. UnmanagedNetwork
Name | Summary |
---|---|
|
|
|
5.211. UnmanagedNetworks
Name | Summary |
---|---|
|
5.212. User
Name | Summary |
---|---|
|
|
|
5.213. Users
Name | Summary |
---|---|
|
Add user from a directory service. |
|
5.213.1. add POST
Add user from a directory service.
For example, to add the myuser
user from the myextension-authz
authorization provider send a request
like this:
POST /ovirt-engine/api/users
With a request body like this:
<user>
<user_name>myuser@myextension-authz</user_name>
<domain>
<name>myextension-authz</name>
</domain>
</user>
In case you are working with Active Directory you have to pass user principal name (UPN) as username
, followed
by authorization provider name. Due to bug 1147900 you need to provide
also principal
parameter set to UPN of the user.
For example, to add the user with UPN myuser@mysubdomain.mydomain.com
from the myextension-authz
authorization provider send a request body like this:
<user>
<principal>myuser@mysubdomain.mydomain.com</principal>
<user_name>myuser@mysubdomain.mydomain.com@myextension-authz</user_name>
<domain>
<name>myextension-authz</name>
</domain>
</user>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.213.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Sets the maximum number of users to return. |
|
|
In |
A query string used to restrict the returned users. |
|
|
Out |
5.214. VirtualFunctionAllowedNetwork
Name | Summary |
---|---|
|
|
|
5.215. VirtualFunctionAllowedNetworks
Name | Summary |
---|---|
|
|
|
5.216. Vm
Name | Summary |
---|---|
|
This operation stops any migration of a virtual machine to another physical host. |
|
|
|
|
|
Detaches a virtual machine from a pool. |
|
Export a virtual machine to an export domain. |
|
Freeze virtual machine file systems. |
|
Retrieves the description of the virtual machine. |
|
Initiates the automatic user logon to access a virtual machine from an external console. |
|
|
|
This operation migrates a virtual machine to another physical host. |
|
|
|
This operation sends a reboot request to a virtual machine. |
|
Removes the virtual machine, including the virtual disks attached to it. |
|
|
|
This operation sends a shutdown request to a virtual machine. |
|
Starts the virtual machine. |
|
This operation forces a virtual machine to power-off. |
|
This operation saves the virtual machine state to disk and stops it. |
|
Thaw virtual machine file systems. |
|
Generates a time-sensitive authentication token for accessing a virtual machine’s display. |
|
|
|
5.216.1. cancelmigration POST
This operation stops any migration of a virtual machine to another physical host.
POST /ovirt-engine/api/vms/123/cancelmigration
The cancel migration action does not take any action specific parameters,
so the request body should contain an empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the migration should cancelled asynchronously. |
5.216.2. clone POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the clone should be performed asynchronously. |
|
|
In |
5.216.3. commitsnapshot POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the snapshots should be committed asynchronously. |
5.216.4. detach POST
Detaches a virtual machine from a pool.
POST /ovirt-engine/api/vms/123/detach
The detach action does not take any action specific parameters, so the request body should contain an
empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the detach should be performed asynchronously. |
5.216.5. export POST
Export a virtual machine to an export domain.
For example to export virtual machine 123
to the export domain myexport
, send a request like this:
POST /ovirt-engine/api/vms/123/export
With a request body like this:
<action>
<storage_domain>
<name>myexport</name>
</storage_domain>
<exclusive>true</exclusive>
<discard_snapshots>true</discard_snapshots>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the export should be performed asynchronously. |
|
|
In |
The |
|
|
In |
The |
|
|
In |
5.216.6. freezefilesystems POST
Freeze virtual machine file systems.
This operation freezes a virtual machine’s file systems using the QEMU guest agent when taking a live snapshot of a running virtual machine. Normally, this is done automatically by the manager, but this must be executed manually with the API for virtual machines using OpenStack Volume (Cinder) disks.
Example:
POST /ovirt-engine/api/vms/123/freezefilesystems
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the freeze should be performed asynchronously. |
5.216.7. get GET
Retrieves the description of the virtual machine.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if all the attributes of the virtual machine should be included in the response. |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
Indicates if the returned result describes the virtual machine as it is currently running, or if describes it with the modifications that have already been performed but that will have effect only when it is restarted. |
|
|
Out |
Description of the virtual machine. |
all_content
Indicates if all the attributes of the virtual machine should be included in the response.
By default the following attributes are excluded:
-
console
-
initialization.configuration.data
- The OVF document describing the virtual machine. -
rng_source
-
soundcard
-
virtio_scsi
For example, to retrieve the complete representation of the virtual machine '123' send a request like this:
GET /ovirt-engine/api/vms/123?all_content=true
Note
|
The reason for not including these attributes is performance: they are seldom used and they require additional queries to the database. So try to use the this parameter only when it is really needed. |
next_run
Indicates if the returned result describes the virtual machine as it is currently running, or if describes
it with the modifications that have already been performed but that will have effect only when it is
restarted. By default the values is false
.
If the parameter is included in the request, but without a value, it is assumed that the value is true
, so
the following request:
GET /vms/{vm:id};next_run
Is equivalent to using the value true
:
GET /vms/{vm:id};next_run=true
5.216.8. logon POST
Initiates the automatic user logon to access a virtual machine from an external console.
This action requires the ovirt-guest-agent-gdm-plugin
and the ovirt-guest-agent-pam-module
packages to be
installed and the ovirt-guest-agent
service to be running on the virtual machine.
Users require the appropriate user permissions for the virtual machine in order to access the virtual machine from an external console.
This is how an example request would look like:
POST /ovirt-engine/api/vms/123/logon
Request body:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the logon should be performed asynchronously. |
5.216.9. maintenance POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
5.216.10. migrate POST
This operation migrates a virtual machine to another physical host.
POST /ovirt-engine/api/vms/123/migrate
One can specify a specific host to migrate the virtual machine to:
<action>
<host id="2ab5e1da-b726-4274-bbf7-0a42b16a0fc3"/>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the migration should be performed asynchronously. |
|
|
In |
Specifies the cluster the virtual machine should migrate to. |
|
|
In |
Specifies the virtual machine should migrate although it might be defined as non migratable. |
|
|
In |
Specifies a specific host the virtual machine should migrate to. |
cluster
Specifies the cluster the virtual machine should migrate to. This is an optional parameter. By default, the virtual machine is migrated to another host within the same cluster.
force
Specifies the virtual machine should migrate although it might be defined as non migratable. This is an
optional parameter. By default, it is set to false
.
host
Specifies a specific host the virtual machine should migrate to. This is an optional parameters. By default,
the oVirt Engine automatically selects a default host for migration within the same cluster. If an API user
requires a specific host, the user can specify the host with either an id
or name
parameter.
5.216.11. previewsnapshot POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the preview should be performed asynchronously. |
|
|
In |
||
|
In |
||
|
In |
||
|
In |
5.216.12. reboot POST
This operation sends a reboot request to a virtual machine.
POST /ovirt-engine/api/vms/123/reboot
The reboot action does not take any action specific parameters, so the request body should contain an
empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the reboot should be performed asynchronously. |
5.216.13. remove DELETE
Removes the virtual machine, including the virtual disks attached to it.
For example, to remove the virtual machine with identifier 123
send a request like this:
DELETE /ovirt-engine/api/vms/123
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
|
|
In |
Indicates if the attached virtual disks should be detached first and preserved instead of being removed. |
|
|
In |
Indicates if the virtual machine should be forcibly removed. |
5.216.14. reordermacaddresses POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.216.15. shutdown POST
This operation sends a shutdown request to a virtual machine.
POST /ovirt-engine/api/vms/123/shutdown
The shutdown action does not take any action specific parameters,
so the request body should contain an empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the shutdown should be performed asynchronously. |
5.216.16. start POST
Starts the virtual machine.
If the virtual environment is complete and the virtual machine contains all necessary components to function, it can be started.
This example starts the virtual machine:
POST /ovirt-engine/api/vms/123/start
With a request body:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
If set to |
|
|
In |
If set to |
|
|
In |
If set to |
|
|
In |
The definition of the virtual machine for this specific run. |
use_cloud_init
If set to true
, the initialization type is set to cloud-init. The default value is false
.
See this for details.
use_sysprep
If set to true
, the initialization type is set to Sysprep. The default value is false
.
See this for details.
vm
The definition of the virtual machine for this specific run.
For example:
<action>
<vm>
<os>
<boot>
<devices>
<device>cdrom</device>
</devices>
</boot>
</os>
</vm>
</action>
This will set the boot device to the CDROM only for this specific start. After the virtual machine will be powered off, this definition will be reverted.
5.216.17. stop POST
This operation forces a virtual machine to power-off.
POST /ovirt-engine/api/vms/123/stop
The stop action does not take any action specific parameters,
so the request body should contain an empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.216.18. suspend POST
This operation saves the virtual machine state to disk and stops it. Start a suspended virtual machine and restore the virtual machine state with the start action.
POST /ovirt-engine/api/vms/123/suspend
The suspend action does not take any action specific parameters,
so the request body should contain an empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.216.19. thawfilesystems POST
Thaw virtual machine file systems.
This operation thaws a virtual machine’s file systems using the QEMU guest agent when taking a live snapshot of a running virtual machine. Normally, this is done automatically by the manager, but this must be executed manually with the API for virtual machines using OpenStack Volume (Cinder) disks.
Example:
POST /api/vms/123/thawfilesystems
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.216.20. ticket POST
Generates a time-sensitive authentication token for accessing a virtual machine’s display.
POST /ovirt-engine/api/vms/123/ticket
The client-provided action optionally includes a desired ticket value and/or an expiry time in seconds.
In any case, the response specifies the actual ticket value and expiry used.
<action>
<ticket>
<value>abcd12345</value>
<expiry>120</expiry>
</ticket>
</action>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the generation of the ticket should be performed asynchronously. |
|
|
In/Out |
5.216.21. undosnapshot POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the action should be performed asynchronously. |
5.216.22. update PUT
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In |
Indicates if the update should be applied to the virtual machine immediately, or if it should be applied only when the virtual machine is restarted. |
|
|
In/Out |
5.217. VmApplication
Name | Summary |
---|---|
|
5.218. VmApplications
Name | Summary |
---|---|
|
5.219. VmCdrom
Manages a CDROM device of a virtual machine.
If there is a disk inserted then the file
attribute will contain a reference to the ISO image:
<cdrom>
<file id="mycd.iso"/>
</cdrom>
If there is no disk inserted then the file
attribute won’t be reported:
<cdrom>
</cdrom>
Changing and ejecting the disk is done using always the update
method, to change the value of the file
attribute.
For example, to insert or change the disk send a request like this:
PUT /ovirt-engine/api/vms/123/cdroms/00000000-0000-0000-0000-000000000000
The body should contain the new value for the file
attribute:
<cdrom>
<file id="mycd.iso"/>
</cdrom>
The value of the id
attribute, mycd.iso
in this example, should correspond to a file available in an attached
ISO storage domain.
To eject the disk use a file
with an empty id
:
<cdrom>
<file id=""/>
</cdrom>
By default the above operations change permanently the disk that will be visible to the virtual machine after the
next boot, but they don’t have any effect on the currently running virtual machine. If you want to change the disk
that is visible to the current running virtual machine, add the current=true
parameter. For example, to eject the
current disk send a request like this:
PUT /ovirt-engine/api/vms/123/cdroms/00000000-0000-0000-0000-000000000000?current=true
With a request body like this:
<cdrom>
<file id=""/>
</cdrom>
Important
|
The changes made with the current=true parameter are never persisted, so they won’t have any effect
after the virtual machine is rebooted.
|
Name | Summary |
---|---|
|
Returns the information about this CDROM device. |
|
Updates the information about this CDROM device. |
5.219.1. get GET
Returns the information about this CDROM device.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
The information about the CDROM device. |
|
|
In |
Indicates if the operation should return the information for the currently running virtual machine. |
5.219.2. update PUT
Updates the information about this CDROM device.
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
The information about the CDROM device. |
|
|
In |
Indicates if the update should apply to the currently running virtual machine, or to the virtual machine after the next boot. |
5.220. VmCdroms
Manages the CDROM devices of a virtual machine.
Currently virtual machines have exactly one CDROM device. No new devices can be added, and the existing one can’t
be removed, thus there are no add
or remove
methods. Changing and ejecting CDROM disks is done with the
update method of the service that manages the
CDROM device.
Name | Summary |
---|---|
|
Returns the list of CDROM devices of the virtual machine. |
5.221. VmDisk
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
Detach the disk from the virtual machine. |
|
5.221.1. activate POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the activation should be performed asynchronously. |
5.221.2. deactivate POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the deactivation should be performed asynchronously. |
5.221.3. export POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the export should be performed asynchronously. |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
5.221.5. move POST
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. |
5.221.6. remove DELETE
Detach the disk from the virtual machine.
Note
|
In version 3 of the API this used to also remove the disk completely from the system, but starting with version 4 it doesn’t. If you need to remove it completely use the remove method of the top level disk service. |
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.222. VmDisks
Name | Summary |
---|---|
|
|
|
5.223. VmGraphicsConsole
Name | Summary |
---|---|
|
Gets the configuration of the graphics console. |
|
|
|
5.223.1. get GET
Gets the configuration of the graphics console.
Name | Type | Direction | Summary |
---|---|---|---|
|
Out |
||
|
In |
Use the following query to obtain the current run-time configuration of the graphics console. |
5.223.2. proxyticket POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the generation of the ticket should be performed asynchronously. |
|
|
Out |
5.224. VmHostDevice
Name | Summary |
---|---|
|
|
|
5.225. VmHostDevices
Name | Summary |
---|---|
|
|
|
5.226. VmNic
Name | Summary |
---|---|
|
|
|
|
|
|
|
Removes the NIC. |
|
Updates the NIC. |
5.226.1. activate POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the activation should be performed asynchronously. |
5.226.2. deactivate POST
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the deactivation should be performed asynchronously. |
5.226.4. remove DELETE
Removes the NIC.
For example, to remove the NIC with id 456
from the virtual machine with id 123
send a request like this:
DELETE /ovirt-engine/api/vms/123/nics/456
Important
|
The hotplugging feature only supports virtual machine operating systems with hotplugging operations. Example operating systems include:
|
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.226.5. update PUT
Updates the NIC.
For example, to update the NIC having with 456
belonging to virtual the machine with id 123
send a request
like this:
PUT /ovirt-engine/api/vms/123/nics/456
With a request body like this:
<nic>
<name>mynic</name>
<interface>e1000</interface>
</nic>
Important
|
The hotplugging feature only supports virtual machine operating systems with hotplugging operations. Example operating systems include:
|
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.227. VmNics
Name | Summary |
---|---|
|
Adds a NIC to the virtual machine. |
|
5.227.1. add POST
Adds a NIC to the virtual machine.
The following example adds a network interface named mynic
using virtio
and the ovirtmgmt
network to the
virtual machine.
POST /ovirt-engine/api/vms/123/nics
<nic>
<interface>virtio</interface>
<name>mynic</name>
<network>
<name>ovirtmgmt</name>
</network>
</nic>
The following example sends that request using curl
:
curl \
--request POST \
--header "Version: 4" \
--header "Content-Type: application/xml" \
--header "Accept: application/xml" \
--user "admin@internal:mypassword" \
--cacert /etc/pki/ovirt-engine/ca.pem \
--data '
<nic>
<name>mynic</name>
<network>
<name>ovirtmgmt</name>
</network>
</nic>
' \
https://myengine.example.com/ovirt-engine/api/vms/123/nics
Important
|
The hotplugging feature only supports virtual machine operating systems with hotplugging operations. Example operating systems include:
|
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.228. VmNumaNode
Name | Summary |
---|---|
|
|
|
Removes a virtual NUMA node. |
|
Updates a virtual NUMA node. |
5.228.2. remove DELETE
Removes a virtual NUMA node.
An example of removing a virtual NUMA node:
DELETE /ovirt-engine/api/vms/123/numanodes/456
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.228.3. update PUT
Updates a virtual NUMA node.
An example of pinning a virtual NUMA node to a physical NUMA node on the host:
PUT /ovirt-engine/api/vms/123/numanodes/456
The request body should contain the following:
<vm_numa_node>
<numa_node_pins>
<numa_node_pin>
<host_numa_node id="789"/>
<index>0</index>
<pinned>true</pinned>
</numa_node_pin>
</numa_node_pins>
</vm_numa_node>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
5.229. VmNumaNodes
Name | Summary |
---|---|
|
Creates a new virtual NUMA node for the virtual machine. |
|
Lists virtual NUMA nodes of a virtual machine. |
5.229.1. add POST
Creates a new virtual NUMA node for the virtual machine.
An example of creating a NUMA node:
POST /ovirt-engine/api/vms/c7ecd2dc/numanodes
Accept: application/xml
Content-type: application/xml
The request body can contain the following:
<vm_numa_node>
<cpu>
<cores>
<core>
<index>0</index>
</core>
</cores>
</cpu>
<index>0</index>
<memory>1024</memory>
</vm_numa_node>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.230. VmPool
Name | Summary |
---|---|
|
This operation allocates a virtual machine in the virtual machine pool. |
|
|
|
Removes a virtual machine pool. |
|
Update the virtual machine pool. |
5.230.1. allocatevm POST
This operation allocates a virtual machine in the virtual machine pool.
POST /ovirt-engine/api/vmpools/123/allocatevm
The allocate virtual machine action does not take any action specific parameters, so the request body should
contain an empty action
:
<action/>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the allocation should be performed asynchronously. |
5.230.2. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.230.3. remove DELETE
Removes a virtual machine pool.
DELETE /ovirt-engine/api/vmpools/123
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.230.4. update PUT
Update the virtual machine pool.
PUT /ovirt-engine/api/vmpools/123
The name
, description
, size
, prestarted_vms
and max_user_vms
attributes can be updated after the virtual machine pool has been
created.
<vmpool>
<name>VM_Pool_B</name>
<description>Virtual Machine Pool B</description>
<size>3</size>
<prestarted_vms>1</size>
<max_user_vms>2</size>
</vmpool>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the update should be performed asynchronously. |
|
|
In/Out |
The virtual machine pool that is being updated. |
5.231. VmPools
Name | Summary |
---|---|
|
Creates a new virtual machine pool. |
|
5.231.1. add POST
Creates a new virtual machine pool.
A new pool requires the name
, cluster
and template
attributes. Identify the cluster and template with the
id
or name
nested attributes:
POST /ovirt-engine/api/vmpools
With the following body:
<vmpool>
<name>mypool</name>
<cluster id="123"/>
<template id="456"/>
</vmpool>
Name | Type | Direction | Summary |
---|---|---|---|
|
In/Out |
5.231.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the search performed using the |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
Sets the maximum number of pools to return. |
|
|
Out |
||
|
In |
A query string used to restrict the returned pools. |
5.232. VmReportedDevice
Name | Summary |
---|---|
|
5.233. VmReportedDevices
Name | Summary |
---|---|
|
5.234. VmSession
Name | Summary |
---|---|
|
5.235. VmSessions
Provides information about virtual machine user sessions.
Name | Summary |
---|---|
|
Lists all user sessions for this virtual machine. |
5.235.1. list GET
Lists all user sessions for this virtual machine.
For example, to retrieve the session information for virtual machine 123
send a request like this:
GET /ovirt-engine/api/vms/123/sessions
The response body will contain something like this:
<sessions>
<session href="/ovirt-engine/api/vms/123/sessions/456" id="456">
<console_user>true</console_user>
<ip>
<address>192.168.122.1</address>
</ip>
<user href="/ovirt-engine/api/users/789" id="789"/>
<vm href="/ovirt-engine/api/vms/123" id="123"/>
</session>
...
</sessions>
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Sets the maximum number of sessions to return. |
|
|
Out |
5.236. VmWatchdog
Name | Summary |
---|---|
|
|
|
|
|
5.237. VmWatchdogs
Name | Summary |
---|---|
|
|
|
5.238. Vms
Name | Summary |
---|---|
|
Creates a new virtual machine. |
|
5.238.1. add POST
Creates a new virtual machine.
The virtual machine can be created in different ways:
-
From a template. In this case the identifier or name of the template must be provided. For example, using a plain shell script and XML:
#!/bin/sh -ex
url="https://engine.example.com/ovirt-engine/api"
user="admin@internal"
password="..."
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--user "${user}:${password}" \
--request POST \
--header "Version: 4" \
--header "Content-Type: application/xml" \
--header "Accept: application/xml" \
--data '
<vm>
<name>myvm</name>
<template>
<name>Blank</name>
</template>
<cluster>
<name>mycluster</name>
</cluster>
</vm>
' \
"${url}/vms"
-
From a snapshot. In this case the identifier of the snapshot has to be provided. For example, using a plain shel script and XML:
#!/bin/sh -ex
url="https://engine.example.com/ovirt-engine/api"
user="admin@internal"
password="..."
curl \
--verbose \
--cacert /etc/pki/ovirt-engine/ca.pem \
--user "${user}:${password}" \
--request POST \
--header "Content-Type: application/xml" \
--header "Accept: application/xml" \
--data '
<vm>
<name>myvm</name>
<snapshots>
<snapshot id="266742a5-6a65-483c-816d-d2ce49746680"/>
</snapshots>
<cluster>
<name>mycluster</name>
</cluster>
</vm>
' \
"${url}/vms"
When creating a virtual machine from a template or from a snapshot it is usually useful to explicitly indicate
in what storage domain to create the disks for the virtual machine. If the virtual machine is created from
a template then this is achieved passing a set of disk_attachment
elements that indicate the mapping:
<vm>
...
<disk_attachments>
<disk_attachment>
<disk id="8d4bd566-6c86-4592-a4a7-912dbf93c298">
<storage_domains>
<storage_domain id="9cb6cb0a-cf1d-41c2-92ca-5a6d665649c9"/>
</storage_domains>
</disk>
<disk_attachment>
</disk_attachments>
</vm>
When the virtual machine is created from a snapshot this set of disks is slightly different, it uses the
image_id
attribute instead of id
.
<vm>
...
<disk_attachments>
<disk_attachment>
<disk>
<image_id>8d4bd566-6c86-4592-a4a7-912dbf93c298</image_id>
<storage_domains>
<storage_domain id="9cb6cb0a-cf1d-41c2-92ca-5a6d665649c9"/>
</storage_domains>
</disk>
<disk_attachment>
</disk_attachments>
</vm>
It is possible to specify additional virtual machine parameters in the XML description, e.g. a virtual machine
of desktop
type, with 2 GiB of RAM and additional description can be added sending a request body like the
following:
<vm>
<name>myvm</name>
<description>My Desktop Virtual Machine</description>
<type>desktop</type>
<memory>2147483648</memory>
...
</vm>
A bootable CDROM device can be set like this:
<vm>
...
<os>
<boot dev="cdrom"/>
</os>
</vm>
In order to boot from CDROM, you first need to insert a disk, as described in the
CDROM service. Then booting from that CDROM can be specified using the os.boot.devices
attribute:
<vm>
...
<os>
<boot>
<devices>
<device>cdrom</device>
</devices>
</boot>
</os>
</vm>
In all cases the name or identifier of the cluster where the virtual machine will be created is mandatory.
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Specifies if the virtual machine should be independent of the template. |
|
|
In |
Specifies if the permissions of the template should be copied to the virtual machine. |
|
|
In/Out |
clone
Specifies if the virtual machine should be independent of the template.
When a virtual machine is created from a template by default the disks of the virtual machine depend on
the disks of the template, they are using the copy on write
mechanism so that only the differences from the template take up real storage space. If this parameter is
specified and the value is true
then the disks of the created virtual machine will be cloned, and
independent of the template. For example, to create an independent virtual machine, send a request like this:
POST /ovirt-engine/vms?clone=true
With a request body like this:
<vm>
<name>myvm<name>
<template>
<name>mytemplate<name>
</template>
<cluster>
<name>mycluster<name>
</cluster>
</vm>
Note
|
When this parameter is true the permissions of the template will also be copied, as when using
clone_permissions=true .
|
clone_permissions
Specifies if the permissions of the template should be copied to the virtual machine.
If this optional parameter is provided, and its values is true
then the permissions of the template (only
the direct ones, not the inherited ones) will be copied to the created virtual machine. For example, to
create a virtual machine from the mytemplate
template copying its permissions, send a request like this:
POST /ovirt-engine/api/vms?clone_permissions=true
With a request body like this:
<vm>
<name>myvm<name>
<template>
<name>mytemplate<name>
</template>
<cluster>
<name>mycluster<name>
</cluster>
</vm>
5.238.2. list GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if all the attributes of the virtual machines should be included in the response. |
|
|
In |
Indicates if the search performed using the |
|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
In |
The maximum number of results to return. |
|
|
In |
A query string used to restrict the returned virtual machines. |
|
|
Out |
all_content
Indicates if all the attributes of the virtual machines should be included in the response.
By default the following attributes are excluded:
-
console
-
initialization.configuration.data
- The OVF document describing the virtual machine. -
rng_source
-
soundcard
-
virtio_scsi
For example, to retrieve the complete representation of the virtual machines send a request like this:
GET /ovirt-engine/api/vms?all_content=true
Note
|
The reason for not including these attributes is performance: they are seldom used and they require additional queries to the database. So try to use the this parameter only when it is really needed. |
5.239. VnicProfile
Since 4.0 it is possible to have a customized network filter to each VNIC profile. Please note that there is a default network filter to each VNIC profile. For more details of how the default network filter is calculated please refer to the documentation in NetworkFilters.
The basic POST command of adding a new VNIC profile is as follows:
http://{engine_ip_address}:8080/ovirt-engine/api/networks/{network_id}/vnicprofiles
The output of creating a new VNIC profile depends in the body arguments that were given. In case no network filter was given, the default network filter will be configured. For example:
<vnic_profile>
<name>use_default_network_filter</name>
<network id="00000000-0000-0000-0000-000000000009"/>
</vnic_profile>
In case an empty network filter was given, no network filter will be configured for the specific VNIC profile regardless of the VNIC profile’s default network filter. For example:
<vnic_profile>
<name>no_network_filter</name>
<network id="00000000-0000-0000-0000-000000000009"/>
<network_filter/>
</vnic_profile>
In case that a specific valid network filter id was given, the VNIC profile will be configured with the given network filter regardless of the VNIC profiles’s default network filter. For example:
<vnic_profile>
<name>user_choice_network_filter</name>
<network id="00000000-0000-0000-0000-000000000009"/>
<network_filter id= "0000001b-001b-001b-001b-0000000001d5"/>
</vnic_profile>
Name | Summary |
---|---|
|
|
|
|
|
5.239.2. remove DELETE
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the remove should be performed asynchronously. |
5.240. VnicProfiles
Name | Summary |
---|---|
|
|
|
5.241. Weight
Name | Summary |
---|---|
|
|
|
5.241.1. get GET
Name | Type | Direction | Summary |
---|---|---|---|
|
In |
Indicates if the results should be filtered according to the permissions of the user. |
|
|
Out |
5.242. Weights
Name | Summary |
---|---|
|
|
|
6. Types
This section enumerates all the data types that are available in the API.
6.2. Action struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Free text containing comments about this object. |
|
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.3. AffinityGroup struct
An affinity group represents a group of virtual machines with a defined relationship.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
Specifies whether the affinity group uses hard or soft enforcement of the affinity applied to virtual machines that are members of that affinity group. |
|
|
||
|
A human readable name in plain text. |
|
|
Specifies whether the affinity group applies positive affinity or negative affinity to virtual machines that are members of that affinity group. |
Name | Type | Summary |
---|---|---|
|
A reference to the cluster to which the affinity group applies. |
|
|
List of all virtual machines assigned to this affinity group. |
6.4. AffinityLabel struct
Affinity label is a label that can influence the VM scheduling. It is most often used to create a sub-cluster from available hosts.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
The |
6.4.1. read_only
The readOnly
property marks a label that can’t be modified.
This is mostly the case when listing internally generated labels.
Name | Type | Summary |
---|---|---|
|
List of hosts that were labeled using this scheduling label. |
|
|
List of vms that were labeled using this scheduling label. |
6.5. Agent struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
6.6. AgentConfiguration struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
6.7. Api struct
This type contains the information returned by root service of the API.
Name | Type | Summary |
---|---|---|
|
Information about the product, like its name, the name of the vendor and the version. |
|
|
References to special objects, like the blank template and the root of the hierarchy of tags. |
|
|
A summary containing the total number of relevant objects, like virtual machines, hosts and storage domains. |
|
|
The date and time when this information was generated. |
6.8. ApiSummary struct
A summary containing the total number of relevant objects, like virtual machines, hosts and storage domains.
Name | Type | Summary |
---|---|---|
|
The summary of hosts. |
|
|
The summary of storage domains. |
|
|
The summary of users. |
|
|
The summary of virtual machines. |
6.9. ApiSummaryItem struct
This type contains an item of the API summary. Each item contains the total and active number of some kind of object.
Name | Type | Summary |
---|---|---|
|
The total number of active objects. |
|
|
The total number of objects. |
6.10. Application struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.12. AuthorizedKey struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.14. Balance struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
6.17. Bonding struct
Name | Type | Summary |
---|---|---|
|
The |
|
|
||
|
6.17.1. ad_partner_mac
The ad_partner_mac
property of the partner bond in mode 4. Bond mode 4 is the 802.3ad standard,
also called dynamic link aggregation -
Wikipedia,
Presentation.
ad_partner_mac
is the MAC address of the system (switch) at the other end of a bond.
This parameter is read only. Setting it will have no effect on the bond.
It is retrieved from /sys/class/net/bondX/bonding/ad_partner_mac
file on the system where the bond is located.
6.18. Bookmark struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
6.22. BootProtocol enum
The enum defines the options of the IP address assignment method to a NIC.
Name | Summary |
---|---|
|
Stateless Address Auto-Configuration. |
|
Dynamic Host Configuration Protocol. |
|
No address configuration. |
|
Statically (by user) defined address, mask and gateway. |
6.22.1. autoconf
Stateless Address Auto-Configuration. The mechanism is defined by RFC 4862. Please refer to this wikipedia article.
Note
|
The value is valid for IPv6 addresses only. |
6.22.2. dhcp
Dynamic Host Configuration Protocol. Please refer to this wikipedia article.
6.23. BrickProfileDetail struct
Name | Type | Summary |
---|---|---|
|
Name | Type | Summary |
---|---|---|
|
6.24. Cdrom struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.25. Certificate struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
6.26. CloudInit struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
6.27. Cluster struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
Custom scheduling policy properties of the cluster. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
Type of switch to be used by all networks in given cluster. |
|
|
||
|
||
|
||
|
The compatibility version of the cluster. |
|
|
6.27.1. custom_scheduling_policy_properties
Custom scheduling policy properties of the cluster.
These optional properties override the properties of the
scheduling policy specified by the scheduling_policy
link,
and apply only for this specific cluster.
For example, to update the custom properties of the cluster, send a request:
PUT /ovirt-engine/api/clusters/123
With a request body:
<cluster>
<custom_scheduling_policy_properties>
<property>
<name>HighUtilization</name>
<value>70</value>
</property>
</custom_scheduling_policy_properties>
</cluster>
Update operations using the custom_scheduling_policy_properties
attribute
will not update the the properties of the scheduling policy specified by
the scheduling_policy
link,
they will only be reflected on this specific cluster.
6.27.2. version
The compatibility version of the cluster.
All hosts in this cluster must support at least this compatibility version.
For example:
GET /ovirt-engine/api/clusters/123
Will respond:
<cluster>
...
<version>
<major>4</major>
<minor>0</minor>
</version>
...
</cluster>
To update the compatibility version, use:
PUT /ovirt-engine/api/clusters/123
With a request body:
<cluster>
<version>
<major>4</major>
<minor>1</minor>
</version>
</cluster>
In order to update the cluster compatibility version, all hosts in the cluster must support the new compatibility version.
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Reference to the default scheduling policy used by this cluster. |
6.27.3. scheduling_policy
Reference to the default scheduling policy used by this cluster.
Note
|
The scheduling policy properties are taken by
default from the referenced scheduling policy, but
they are overridden by the properties specified in
the custom_scheduling_policy_properties attribute
for this cluster.
|
6.28. ClusterLevel struct
Describes the capabilities supported by a specific cluster level.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
The CPU types supported by this cluster level. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
The permits supported by this cluster level. |
6.29. Configuration struct
Name | Type | Summary |
---|---|---|
|
The document describing the virtual machine. |
|
|
6.29.1. data
The document describing the virtual machine.
Example of the OVF document:
<?xml version='1.0' encoding='UTF-8'?>
<ovf:Envelope xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1/"
xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"
xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ovf:version="3.5.0.0">
<References/>
<Section xsi:type="ovf:NetworkSection_Type">
<Info>List of networks</Info>
<Network ovf:name="Network 1"/>
</Section>
<Section xsi:type="ovf:DiskSection_Type">
<Info>List of Virtual Disks</Info>
</Section>
<Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type">
<CreationDate>2014/12/03 04:25:45</CreationDate>
<ExportDate>2015/02/09 14:12:24</ExportDate>
<DeleteProtected>false</DeleteProtected>
<SsoMethod>guest_agent</SsoMethod>
<IsSmartcardEnabled>false</IsSmartcardEnabled>
<TimeZone>Etc/GMT</TimeZone>
<default_boot_sequence>0</default_boot_sequence>
<Generation>1</Generation>
<VmType>1</VmType>
<MinAllocatedMem>1024</MinAllocatedMem>
<IsStateless>false</IsStateless>
<IsRunAndPause>false</IsRunAndPause>
<AutoStartup>false</AutoStartup>
<Priority>1</Priority>
<CreatedByUserId>fdfc627c-d875-11e0-90f0-83df133b58cc</CreatedByUserId>
<IsBootMenuEnabled>false</IsBootMenuEnabled>
<IsSpiceFileTransferEnabled>true</IsSpiceFileTransferEnabled>
<IsSpiceCopyPasteEnabled>true</IsSpiceCopyPasteEnabled>
<Name>VM_export</Name>
<TemplateId>00000000-0000-0000-0000-000000000000</TemplateId>
<TemplateName>Blank</TemplateName>
<IsInitilized>false</IsInitilized>
<Origin>3</Origin>
<DefaultDisplayType>1</DefaultDisplayType>
<TrustedService>false</TrustedService>
<OriginalTemplateId>00000000-0000-0000-0000-000000000000</OriginalTemplateId>
<OriginalTemplateName>Blank</OriginalTemplateName>
<UseLatestVersion>false</UseLatestVersion>
<Section ovf:id="70b4d9a7-4f73-4def-89ca-24fc5f60e01a"
ovf:required="false"
xsi:type="ovf:OperatingSystemSection_Type">
<Info>Guest Operating System</Info>
<Description>other</Description>
</Section>
<Section xsi:type="ovf:VirtualHardwareSection_Type">
<Info>1 CPU, 1024 Memeory</Info>
<System>
<vssd:VirtualSystemType>ENGINE 3.5.0.0</vssd:VirtualSystemType>
</System>
<Item>
<rasd:Caption>1 virtual cpu</rasd:Caption>
<rasd:Description>Number of virtual CPU</rasd:Description>
<rasd:InstanceId>1</rasd:InstanceId>
<rasd:ResourceType>3</rasd:ResourceType>
<rasd:num_of_sockets>1</rasd:num_of_sockets>
<rasd:cpu_per_socket>1</rasd:cpu_per_socket>
</Item>
<Item>
<rasd:Caption>1024 MB of memory</rasd:Caption>
<rasd:Description>Memory Size</rasd:Description>
<rasd:InstanceId>2</rasd:InstanceId>
<rasd:ResourceType>4</rasd:ResourceType>
<rasd:AllocationUnits>MegaBytes</rasd:AllocationUnits>
<rasd:VirtualQuantity>1024</rasd:VirtualQuantity>
</Item>
<Item>
<rasd:Caption>USB Controller</rasd:Caption>
<rasd:InstanceId>3</rasd:InstanceId>
<rasd:ResourceType>23</rasd:ResourceType>
<rasd:UsbPolicy>DISABLED</rasd:UsbPolicy>
</Item>
</Section>
</Content>
</ovf:Envelope>
6.33. Cpu struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.35. CpuProfile struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.38. CpuType struct
Describes a supported CPU type.
Name | Type | Summary |
---|---|---|
|
The architecture of the CPU. |
|
|
The level of the CPU type. |
|
|
The name of the CPU type, for example |
6.39. CreationStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
6.41. DataCenter struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
The compatibility version of the data center. |
6.41.1. version
The compatibility version of the data center.
All clusters in this data center have to be already set to at least this compatibility version.
For example:
GET /ovirt-engine/api/datacenters/123
Will respond:
<data_center>
...
<version>
<major>4</major>
<minor>0</minor>
</version>
...
</data_center>
To update the compatibility version, use:
PUT /ovirt-engine/api/datacenters/123
With a request body:
<data_center>
<version>
<major>4</major>
<minor>1</minor>
</version>
</data_center>
Name | Type | Summary |
---|---|---|
|
Reference to clusters inside this data center. |
|
|
Reference to ISCSI bonds used by this data center. |
|
|
Reference to the MAC pool used by this data center. |
|
|
Reference to networks attached to this data center. |
|
|
Reference to permissions assigned to this data center. |
|
|
Reference to quality of service used by this data center. |
|
|
Reference to quotas assigned to this datacenter. |
|
|
Reference to storage domains attached to this data center. |
6.42. DataCenterStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
6.43. Device struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.44. Disk struct
Represents a virtual disk device.
Name | Type | Summary |
---|---|---|
|
||
|
The actual size of the disk, in bytes. |
|
|
||
|
Indicates if the disk is marked as bootable. |
|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
The underlying storage format. |
|
|
||
|
||
|
The type of interface driver used to connect the disk device to the virtual machine. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
Indicates if disk errors should not cause virtual machine to be paused and, instead, disk errors should be propagated to the the guest operating system. |
|
|
The virtual size of the disk, in bytes. |
|
|
Indicates if the disk is in read-only mode. |
|
|
||
|
Indicates if the disk can be attached to multiple virtual machines. |
|
|
Indicates if the physical storage for the disk should not be preallocated. |
|
|
The status of the disk device. |
|
|
||
|
||
|
Indicates if the disk’s blocks will be read back as zeros after it is deleted: - On block storage, the disk will be zeroed and only then deleted. |
6.44.1. actual_size
The actual size of the disk, in bytes.
The actual size is the number of bytes actually used by the disk, and it will be smaller than the provisioned
size for disks that use the cow
format.
6.44.2. bootable
Indicates if the disk is marked as bootable.
Important
|
This attribute only makes sense for disks that are actually connected to virtual machines, and in version 4 of the API it has been moved to the DiskAttachment type. It is preserved here only for backwards compatibility, and it will be removed in the future. |
6.44.3. interface
The type of interface driver used to connect the disk device to the virtual machine.
Important
|
This attribute only makes sense for disks that are actually connected to virtual machines, and in version 4 of the API it has been moved to the DiskAttachment type. It is preserved here only for backwards compatibility, and it will be removed in the future. |
6.44.4. provisioned_size
The virtual size of the disk, in bytes.
This attribute is mandatory when creating a new disk.
6.44.6. wipe_after_delete
Indicates if the disk’s blocks will be read back as zeros after it is deleted:
-
On block storage, the disk will be zeroed and only then deleted.
-
On file storage, since the file system already guarantees that previously removed blocks are read back as zeros, the disk will be deleted immediately.
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The storage domains associated with this disk. |
|
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.45. DiskAttachment struct
Describes how a disk is attached to a virtual machine.
Name | Type | Summary |
---|---|---|
|
This flag indicates if the disk is active in the virtual machine it’s attached to. |
|
|
Indicates if the disk is marked as bootable. |
|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
The type of interface driver used to connect the disk device to the virtual machine. |
|
|
The logical name of the virtual machine’s disk, i. |
|
|
A human readable name in plain text. |
6.45.1. active
This flag indicates if the disk is active in the virtual machine it’s attached to.
A disk attached to a virtual machine in an active status is connected to the virtual machine at run time and can be used.
6.45.2. logical_name
The logical name of the virtual machine’s disk, i.e the name of the disk as seen from inside the virtual machine. Note that the logical name of a disk is reported only when the guest agent is installed and running inside the virtual machine.
For example, if the guest operating system is Linux and
the disk is connected via a VirtIO interface, the logical
name will be reported as /dev/vda
:
<disk_attachment>
...
<logical_name>/dev/vda</logical_name>
</disk_attachment>
If the guest operating system is Windows, the logical
name will be reported as \\.\PHYSICALDRIVE0
.
Name | Type | Summary |
---|---|---|
|
Reference to the disk. |
|
|
Reference to the template. |
|
|
Reference to the virtual machine. |
6.46. DiskFormat enum
The underlying storage format of disks.
Name | Summary |
---|---|
|
The Copy On Write format allows snapshots, with a small performance overhead. |
|
The raw format does not allow snapshots, but offers improved performance. |
6.47. DiskInterface enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
6.48. DiskProfile struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.49. DiskSnapshot struct
Name | Type | Summary |
---|---|---|
|
||
|
The actual size of the disk, in bytes. |
|
|
||
|
Indicates if the disk is marked as bootable. |
|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
The underlying storage format. |
|
|
||
|
||
|
The type of interface driver used to connect the disk device to the virtual machine. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
Indicates if disk errors should not cause virtual machine to be paused and, instead, disk errors should be propagated to the the guest operating system. |
|
|
The virtual size of the disk, in bytes. |
|
|
Indicates if the disk is in read-only mode. |
|
|
||
|
Indicates if the disk can be attached to multiple virtual machines. |
|
|
Indicates if the physical storage for the disk should not be preallocated. |
|
|
The status of the disk device. |
|
|
||
|
||
|
Indicates if the disk’s blocks will be read back as zeros after it is deleted: - On block storage, the disk will be zeroed and only then deleted. |
6.49.1. actual_size
The actual size of the disk, in bytes.
The actual size is the number of bytes actually used by the disk, and it will be smaller than the provisioned
size for disks that use the cow
format.
6.49.2. bootable
Indicates if the disk is marked as bootable.
Important
|
This attribute only makes sense for disks that are actually connected to virtual machines, and in version 4 of the API it has been moved to the DiskAttachment type. It is preserved here only for backwards compatibility, and it will be removed in the future. |
6.49.3. interface
The type of interface driver used to connect the disk device to the virtual machine.
Important
|
This attribute only makes sense for disks that are actually connected to virtual machines, and in version 4 of the API it has been moved to the DiskAttachment type. It is preserved here only for backwards compatibility, and it will be removed in the future. |
6.49.4. provisioned_size
The virtual size of the disk, in bytes.
This attribute is mandatory when creating a new disk.
6.49.6. wipe_after_delete
Indicates if the disk’s blocks will be read back as zeros after it is deleted:
-
On block storage, the disk will be zeroed and only then deleted.
-
On file storage, since the file system already guarantees that previously removed blocks are read back as zeros, the disk will be deleted immediately.
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The storage domains associated with this disk. |
|
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.53. Display struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.56. Domain struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
||
|
6.57. EntityExternalStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
6.58. EntityProfileDetail struct
Name | Type | Summary |
---|---|---|
|
6.60. Event struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
6.61. ExternalComputeResource struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
6.62. ExternalDiscoveredHost struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
6.63. ExternalHost struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.64. ExternalHostGroup struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
6.65. ExternalHostProvider struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
6.66. ExternalProvider struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
6.69. ExternalVmImport struct
Describes parameters of virtual machine import operation from external system.
Name | Type | Summary |
---|---|---|
|
Name of the virtual machine to be imported as is defined within the external system. |
|
|
Password to authenticate against external hypervisor system. |
|
|
Type of external virtual machine provider. |
|
|
Specifies the disk allocation policy of resulting virtual machine: |
|
|
URL to be passed to the |
|
|
Username to authenticate against external hypervisor system. |
6.69.1. url
URL to be passed to the virt-v2v
tool for conversion.
Example:
vpx://wmware_user@vcenter-host/DataCenter/Cluster/esxi-host?no_verify=1
More examples can be found at http://libguestfs.org/virt-v2v.1.html.
Name | Type | Summary |
---|---|---|
|
Specifies the target cluster of the resulting virtual machine. |
|
|
Optionally specifies the cpu profile of the resulting virtual machine. |
|
|
Optional name of ISO carrying drivers that can be used during the virt-v2v conversion process. |
|
|
Optional specification of host (using host’s ID) to be used for the conversion process. |
|
|
Optionally specifies the quota that will be applied to the resulting virtual machine. |
|
|
Specifies the target storage domain for converted disks. |
|
|
Virtual machine entity used to specify the name of the newly created virtual machine. |
6.70. ExternalVmProviderType enum
Describes type of external hypervisor system.
Name | Summary |
---|---|
|
|
|
|
|
6.73. FencingPolicy struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.74. File struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
6.75. Filter struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
6.76. Floppy struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.78. GlusterBrick struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.79. GlusterBrickAdvancedDetails struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.80. GlusterBrickMemoryInfo struct
Name | Type | Summary |
---|---|---|
|
6.81. GlusterBrickStatus enum
Name | Summary |
---|---|
|
Brick is in |
|
When the status cannot be determined due to host being non-responsive. |
|
Brick is in |
6.82. GlusterClient struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.83. GlusterHook struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
6.84. GlusterHookStatus enum
Name | Summary |
---|---|
|
Hook is disabled in the cluster. |
|
Hook is enabled in the cluster. |
|
Unknown/missing hook status. |
6.85. GlusterMemoryPool struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
6.86. GlusterServerHook struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
6.88. GlusterVolume struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.89. GlusterVolumeProfileDetails struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
6.90. GlusterVolumeStatus enum
Name | Summary |
---|---|
|
Volume needs to be started, for clients to be able to mount and use it. |
|
When the status cannot be determined due to host being non-responsive. |
|
Volume is started, and can be mounted and used by clients. |
6.91. GlusterVolumeType enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.93. GraphicsConsole struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.95. Group struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Used only to represent the initial role assignments for a new group, thereafter modification of role assignments
are only supported via the |
|
|
6.96. GuestOperatingSystem struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
6.97. HardwareInformation struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
6.99. Hook struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.103. Host struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
Optionally specify the display address of this host explicitly. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
When creating a new host, a root password is required if the password authentication method is chosen, but this is not subsequently included in the representation. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Indicates if the host contains a full installation of the operating system or a scaled-down version intended only to host virtual machines. |
|
|
||
|
The version of VDSM. |
6.103.1. version
The version of VDSM.
For example:
GET /ovirt-engine/api/hosts/123
This GET
request will return the following output:
<host>
...
<version>
<build>999</build>
<full_version>vdsm-4.18.999-419.gitcf06367.el7</full_version>
<major>4</major>
<minor>18</minor>
<revision>0</revision>
</version>
...
</host>
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.104. HostDevice struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.106. HostNic struct
Represents a host NIC.
For example, the XML representation of a host NIC looks like this:
<host_nic href="/ovirt-engine/api/hosts/123/nics/456" id="456">
<name>eth0</name>
<boot_protocol>static</boot_protocol>
<bridged>true</bridged>
<custom_configuration>true</custom_configuration>
<ip>
<address>192.168.122.39</address>
<gateway>192.168.122.1</gateway>
<netmask>255.255.255.0</netmask>
<version>v4</version>
</ip>
<ipv6>
<gateway>::</gateway>
<version>v6</version>
</ipv6>
<ipv6_boot_protocol>none</ipv6_boot_protocol>
<mac>
<address>52:54:00:0c:79:1d</address>
</mac>
<mtu>1500</mtu>
<status>up</status>
</host_nic>
Name | Type | Summary |
---|---|---|
|
The |
|
|
||
|
||
|
||
|
||
|
||
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
The MAC address of the NIC. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
A link to the statistics of the NIC. |
|
|
||
|
For a SR-IOV physical function NIC describes its virtual functions configuration. |
|
|
6.106.1. ad_aggregator_id
The ad_aggregator_id
property of a bond or bond slave, for bonds in mode 4.
Bond mode 4 is the 802.3ad standard, also called dynamic link aggregation -
Wikipedia
Presentation.
This is only valid for bonds in mode 4, or NICs (NIC - network interface card) which are part of a bond.
It is not present for bonds in other modes, or NICs which are not part in a bond in mode 4.
The ad_aggregator_id
property indicates which of the bond slaves are active. The value of the
ad_aggregator_id
of an active slave is the same the value of the ad_aggregator_id
property of the bond.
This parameter is read only. Setting it will have no effect on the bond/NIC.
It is retrieved from /sys/class/net/bondX/bonding/ad_aggregator
file for a bond, and the
/sys/class/net/ensX/bonding_slave/ad_aggregator_id
file for a NIC.
Name | Type | Summary |
---|---|---|
|
||
|
A reference to the network which the interface should be connected. |
|
|
For a SR-IOV virtual function NIC references to its physical function NIC. |
|
|
6.107. HostNicVirtualFunctionsConfiguration struct
Describes virtual functions configuration for an SR-IOV enabled physical function NIC.
Name | Type | Summary |
---|---|---|
|
Defines whether all networks are allowed to be defined on the related virtual functions or specified ones only. |
|
|
Maximum number of virtual functions the NIC supports. |
|
|
Number of curently defined virtual functions. |
6.109. HostStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.110. HostStorage struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
The number of times to retry a request before attempting further recovery actions. |
|
|
The time in tenths of a second to wait for a response before retrying NFS requests. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.110.1. nfs_retrans
The number of times to retry a request before attempting further recovery actions. The value must be in the
range of 0 to 65535. For more details see the description of the retrans
mount option in the nfs
man page.
6.111. HostType enum
This enumerated type is used to what type of operating system is used by the host.
Name | Summary |
---|---|
|
The host is NGN (Next Generation Node) - a new implementation of RHEV_H which is like RHEL, CentOS or Fedora installation. |
|
The host contains a full RHEL, CentOS or Fedora installation. |
|
The host contains a small scaled version of RHEL, CentOS or Fedora, used solely to host virtual machines. |
6.111.1. ovirt_node
The host is NGN (Next Generation Node) - a new implementation of RHEV_H which is like RHEL, CentOS or Fedora installation. The main difference between NGN and legacy RHEV-H is that NGN has a writeable file system and will handle its installation instead of pushing RPMs to it by the engine in legacy RHEV-H.
6.112. HostedEngine struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
6.113. Icon struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
6.114. Identified struct
This interface is intended to be the base for all types of the model that represents objects with an identifier.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
6.115. Image struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.116. ImageTransfer struct
This type contains information regarding an image transfer being performed.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
The current phase of the image transfer being made. |
|
|
The URL of the proxy server which the user should do I/O to. |
|
|
The signed ticket that should be attached as an |
6.116.1. phase
The current phase of the image transfer being made. Each transfer needs a managed session, which must be opened in order for the user to be able to do I/O to an image. Please refer to image transfer for further documentation.
6.116.2. proxy_url
The URL of the proxy server which the user should do I/O to. This attribute is
available only if the image transfer entity is in transferring
phase. See phase
for details.
Name | Type | Summary |
---|---|---|
|
The host which will be used to write to the image which is targeted for I/O. |
|
|
The image which is targeted for I/O. |
6.117. ImageTransferPhase enum
A list of possible phases for an image transfer entity. Each of these values defines a specific point in a transfer flow.
Please refer to image transfer for further documentation.
Name | Summary |
---|---|
|
This phase will be set as a result of the user actively cancelling the transfer, which can only be performed via the webadmin. |
|
This phase can only be set by oVirt webadmin, and states that there was some error during the transfer and it is being finalized with failure. |
|
This phase will be set when the user calls finalize. |
|
States that the targeted image failed the verification, and cannot be used. |
|
States that the transfer session was successfully closed, and the targeted image was verified and ready to be used. |
|
The initial phase of an added image transfer. |
|
This phase stands for a situation in which the session was timed out, or if some other error occurred with this transfer, e. |
|
This phase will be set as a result of an active pause call by the user, using pause. |
|
The phase where the transfer had been resumed by the client calling resume. |
|
The phase where the transfer session is open, and the client can do I/O to the desired image using its preferred tools. |
|
An unknown phase, will only be set in cases of unpredictable errors. |
6.117.1. finalizing_success
This phase will be set when the user calls finalize. Calling
finalize is essential in order to finish the transfer session and using the targeted image. After finalizing,
the phase will be changed to finished_success
or finished_failure
.
Please refer to image transfer for further documentation.
6.117.2. finished_failure
States that the targeted image failed the verification, and cannot be used. After reaching this phase, the image transfer entity will soon be deleted, and the targeted image will be set to illegal.
6.117.3. finished_success
States that the transfer session was successfully closed, and the targeted image was verified and ready to be used. After reaching this phase, the image transfer entity will soon be deleted.
6.117.4. initializing
The initial phase of an added image transfer. It is set as long as the transfer session is establishing.
Once the session is established, the phase will be changed to transferring
6.117.5. paused_system
This phase stands for a situation in which the session was timed out, or if some other error occurred
with this transfer, e.g, ovirt-imageio-daemon is not running in the selected host for transferring. For trying
to resume the session, the client should call resume. After
resuming, the phase will change to resuming
6.117.6. resuming
The phase where the transfer had been resumed by the client calling
resume. Resuming will start a new session, and after calling it,
the phase should be changed to transferring
, or paused_system
in case of a failure.
6.118. InheritableBoolean enum
Enum representing boolean value that can be either set or inherited from higher level. Usual inheritance order is VM → Cluster → engine-config.
Name | Summary |
---|---|
|
Set value to false on this level. |
|
Inherit value from higher level. |
|
Set value to true on this level. |
6.119. Initialization struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.120. InstanceType struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
The configuration of the CPU of the virtual machine. |
|
|
||
|
||
|
Virtual machine custom compatibility version. |
|
|
||
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The virtual machine’s memory, in bytes. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.120.1. cpu
The configuration of the CPU of the virtual machine.
The sockets configuration can be updated without rebooting the virtual machine. The cores and the threads require a reboot in order to take place.
For example, to change the number of sockets to 4 immediately and the number of cores and threads to 2 after reboot send a request:
PUT /ovirt-engine/api/vms/123
With a request body:
<vm>
<cpu>
<topology>
<sockets>4</sockets>
<cores>2</cores>
<threads>2</threads>
</topology>
</cpu>
</vm>
6.120.2. custom_compatibility_version
Virtual machine custom compatibility version.
This field allows to customize a virtual machine to its own compatibility version. If
custom_compatibility_version
is set, it overrides the cluster’s compatibility version
for this particular virtual machine.
The compatibility version of a virtual machine is limited by the data center the virtual machine resides in and is checked against capabilities of the host the virtual machine is planned to run on.
6.120.3. memory
The virtual machine’s memory, in bytes.
For example, in order to update a virtual machine to contain 1 GiB of memory send a request like this:
PUT /ovirt-engine/api/vms/123
With a request body like this:
<vm>
<memory>1073741824</memory>
</vm>
Note
|
Memory in the previous example is converted to bytes using the following formula: 1 GiB = 230 bytes = 1073741824 bytes. |
Note
|
Memory hot plug is supported from oVirt 3.6 onwards. You can use the example above to increase memory while the virtual machine is running. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
References to the disks attached to the template. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
6.122. Ip struct
Represents the IP configuration of a network interface.
Name | Type | Summary |
---|---|---|
|
The text representation of the IP address. |
|
|
The address of the default gateway. |
|
|
The network mask. |
|
|
The version of the IP protocol. |
6.122.1. address
The text representation of the IP address.
For example, an IPv4 address will be represented as follows:
<ip>
<address>192.168.0.1</address>
...
</ip>
An IPv6 address will be represented as follows:
<ip>
<address>2620:52:0:20f0:4216:7eff:feaa:1b50</address>
...
</ip>
6.122.2. version
The version of the IP protocol.
This attribute is optional, and when it isn’t given the value will be inferred from the value of the address
attribute. If that value is a valid IPv4 address, then it will be assumed that the value of this attribute is
v4
. If it is a valid IPv6 address, then it will be assumed that the value of this attribute is v6
.
Note
|
This inference of the IP version from the value of the address is implemented since version 4.1 of the
engine, before that this attribute was mandatory.
|
6.123. IpAddressAssignment struct
Name | Type | Summary |
---|---|---|
|
||
|
6.124. IpVersion enum
The enum defines valid values for the IP protocol version.
Name | Summary |
---|---|
|
IPv4. |
|
IPv6. |
6.125. IscsiBond struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.126. IscsiDetails struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.127. Job struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
6.128. JobStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
6.129. KatelloErratum struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
6.134. LogicalUnit struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.137. MacPool struct
Represents a MAC address pool.
Example of a XML representatian of a MAC address pool:
<mac_pool href="/ovirt-engine/api/macpools/123" id="123">
<name>Default</name>
<description>Default MAC pool</description>
<allow_duplicates>false</allow_duplicates>
<default_pool>true</default_pool>
<ranges>
<range>
<from>00:1A:4A:16:01:51</from>
<to>00:1A:4A:16:01:E6</to>
</range>
</ranges>
</mac_pool>
Name | Type | Summary |
---|---|---|
|
Defines whether duplicate MAC addresses are permitted in the pool. |
|
|
Free text containing comments about this object. |
|
|
Defines whether this is the default pool. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Defines the range of MAC addresses for the pool. |
6.139. MemoryPolicy struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.142. MigrateOnError enum
Name | Summary |
---|---|
|
|
|
|
|
6.143. MigrationBandwidth struct
Defines the bandwidth used by migration.
Name | Type | Summary |
---|---|---|
|
The way how the bandwidth is assigned. |
|
|
Custom bandwidth in Mbit/s. |
6.144. MigrationBandwidthAssignmentMethod enum
Defines the method how the migration bandwidth is assigned.
Name | Summary |
---|---|
|
Takes the bandwidth from QoS if QoS defined. |
|
Custom defined bandwidth in Mbit/s. |
|
Takes the value as configured on the hypervisor. |
6.145. MigrationOptions struct
Name | Type | Summary |
---|---|---|
|
||
|
The bandwidth which is allowed to be used by the migrations. |
|
|
Name | Type | Summary |
---|---|---|
|
Reference to the migration policy as defined using |
6.146. MigrationPolicy struct
A policy describing how the migration is going to be treated (convergence, how many parallel migrations allowed).
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
6.147. Network struct
Logical network.
An example of the JSON representation of a logical network:
{
"network" : [ {
"data_center" : {
"href" : "/ovirt-engine/api/datacenters/123",
"id" : "123"
},
"stp" : "false",
"mtu" : "0",
"usages" : {
"usage" : [ "vm" ]
},
"name" : "ovirtmgmt",
"description" : "Management Network",
"href" : "/ovirt-engine/api/networks/456",
"id" : "456",
"link" : [ {
"href" : "/ovirt-engine/api/networks/456/permissions",
"rel" : "permissions"
}, {
"href" : "/ovirt-engine/api/networks/456/vnicprofiles",
"rel" : "vnicprofiles"
}, {
"href" : "/ovirt-engine/api/networks/456/labels",
"rel" : "labels"
} ]
} ]
}
An example of the XML representation of the same logical network:
<network href="/ovirt-engine/api/networks/456" id="456">
<name>ovirtmgmt</name>
<description>Management Network</description>
<link href="/ovirt-engine/api/networks/456/permissions" rel="permissions"/>
<link href="/ovirt-engine/api/networks/456/vnicprofiles" rel="vnicprofiles"/>
<link href="/ovirt-engine/api/networks/456/labels" rel="labels"/>
<data_center href="/ovirt-engine/api/datacenters/123" id="123"/>
<stp>false</stp>
<mtu>0</mtu>
<usages>
<usage>vm</usage>
</usages>
</network>
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
Specifies the maximum transmission unit for the network. |
|
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
Specifies whether spanning tree protocol is enabled for the network. |
|
|
Defines a set of usage elements for the network. |
|
|
6.147.1. usages
Defines a set of usage elements for the network.
Users can, for example, specify that the network is to be used for virtual machine traffic and also for
display traffic with the vm
and display
values.
Name | Type | Summary |
---|---|---|
|
||
|
A reference to the data center of which the network is a member. |
|
|
A reference to the labels assigned to the network. |
|
|
A reference to the permissions of the network. |
|
|
||
|
A reference to the profiles of the network. |
6.148. NetworkAttachment struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.150. NetworkFilter struct
Network filter enables to filter packets send to/from the VM’s nic according to defined rules.
There are several types of network filters supported based on libvirt. More details about the different network filters can be found here.
In addition to libvirt’s network filters, there are two additional network filters:
The first called vdsm-no-mac-spoofing
, composed of no-mac-spoofing and no-arp-mac-spoofing.
The second called ovirt-no-filter
is used when no network filter is to be defined for the VM’s nic.
ovirt-no-filter
network filter is only used for internal implementation, and
doesn’t exist on the nics.
This is a example of the XML representation:
<network_filter id="00000019-0019-0019-0019-00000000026c">
<name>example-filter</name>
<version>
<major>4</major>
<minor>0</minor>
<build>-1</build>
<revision>-1</revision>
</version>
</network_filter>
If any part of the version is not present, it is represented by -1.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Represent the minimal supported version of the specific NetworkFilter for which it was first introduced. |
6.151. NetworkLabel struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
6.154. NetworkUsage enum
Name | Summary |
---|---|
|
|
|
The network will be used for Gluster(bricks) data traffic. |
|
|
|
|
|
6.155. NfsProfileDetail struct
Name | Type | Summary |
---|---|---|
|
||
|
6.157. Nic struct
Represents a NIC of a virtual machine.
For example, the XML representation of a NIC will look like this:
<nic href="/ovirt-engine/api/vms/123/nics/456" id="456">
<name>nic1</name>
<vm href="/ovirt-engine/api/vms/123" id="123"/>
<interface>virtio</interface>
<linked>true</linked>
<mac>
<address>02:00:00:00:00:00</address>
</mac>
<plugged>true</plugged>
<vnic_profile href="/ovirt-engine/api/vnicprofiles/789" id="789"/>
</nic>
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
The type of driver used for the NIC. |
|
|
Defines if the NIC is linked to the virtual machine. |
|
|
The MAC address of the interface. |
|
|
A human readable name in plain text. |
|
|
||
|
Defines if the NIC is plugged in to the virtual machine. |
Name | Type | Summary |
---|---|---|
|
||
|
A reference to the network which the interface should be connected to. |
|
|
||
|
||
|
||
|
A link to the statistics for the NIC. |
|
|
||
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
|
|
6.157.1. network
A reference to the network which the interface should be connected to. A blank network id is allowed.
Usage of this element for creating or updating a NIC is deprecated, use vnic_profile
instead. It is preserved
because it is still in use by the initialization
element, as a holder for IP addresses and other network
details.
6.158. NicConfiguration struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.159. NicInterface enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
6.161. NumaNode struct
Represents a physical NUMA node.
Example XML representation:
<host_numa_node href="/ovirt-engine/api/hosts/0923f1ea/numanodes/007cf1ab" id="007cf1ab">
<cpu>
<cores>
<core>
<index>0</index>
</core>
</cores>
</cpu>
<index>0</index>
<memory>65536</memory>
<node_distance>40 20 40 10</node_distance>
<host href="/ovirt-engine/api/hosts/0923f1ea" id="0923f1ea"/>
</host_numa_node>
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
Memory of the NUMA node in MB. |
|
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
||
|
6.162. NumaNodePin struct
Represents pinning of a virtual NUMA node to a physical NUMA node.
Name | Type | Summary |
---|---|---|
|
Deprecated - has no function. |
|
|
Index of a physical NUMA node to which the virtual NUMA node is pinned. |
|
|
Deprecated - should always be true. |
6.164. OpenStackImage struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.165. OpenStackImageProvider struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
6.166. OpenStackNetwork struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.167. OpenStackNetworkProvider struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
Indicates whether the provider is read only. |
|
|
||
|
||
|
The type of provider. |
|
|
||
|
6.167.1. read_only
Indicates whether the provider is read only. A read-only provider does not allow adding, modifying or deleting of networks or subnets. Port-related operations are allowed, as they are required for the provisioning of virtual nics.
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.168. OpenStackNetworkProviderType enum
The OpenStack network provider can either be implemented by OpenStack Neutron, in which case the Neutron agent is automatically installed on the hosts, or it can be an external provider implementing the OpenStack API, in which case the virtual interface driver will be a custom solution installed manually.
Name | Summary |
---|---|
|
Indicates that the provider is an external one, implementing the OpenStack Neutron API. |
|
Indicates that the provider is OpenStack Neutron. |
6.169. OpenStackProvider struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
6.170. OpenStackSubnet struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.171. OpenStackVolumeProvider struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.172. OpenStackVolumeType struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
6.173. OpenstackVolumeAuthenticationKey struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
6.174. OpenstackVolumeAuthenticationKeyUsageType enum
Name | Summary |
---|---|
|
6.175. OperatingSystem struct
Information describing the operating system. Used for virtual machines and hosts.
Name | Type | Summary |
---|---|---|
|
||
|
||
|
A custom part of the host kernel command line. |
|
|
||
|
||
|
Host kernel command line as reported by a running host. |
|
|
||
|
6.175.1. custom_kernel_cmdline
A custom part of the host kernel command line. This will be merged with the existing kernel command line.
You must re-install and then reboot the host to apply the changes implemented by this attribute.
Parameters merging: During each host deploy procedure, kernel parameters that were added
in the previous host deploy procedure are removed using
grubby --update-kernel DEFAULT --remove-args <previous_custom_params>
and the current
kernel command line customization is applied using
grubby --update-kernel DEFAULT --args <custom_params>
. The Engine internally keeps track of the
last applied kernel parameters customization.
Note
|
This attribute is currently only used for hosts. |
6.176. OperatingSystemInfo struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
6.178. OsType enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.182. Permission struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.183. Permit struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.185. PmProxyType enum
Name | Summary |
---|---|
|
Fence proxy is selected from the same cluster as fenced host. |
|
Fence proxy is selected from the same data center as fenced host. |
|
Fence proxy is selected from a different data center than fenced host. |
6.186. PolicyUnitType enum
This enum holds the types of all internal policy units types
Name | Summary |
---|---|
|
|
|
|
|
6.188. PowerManagement struct
Name | Type | Summary |
---|---|---|
|
The host name or IP address of the host. |
|
|
Specifies fence agent options when multiple fences are used. |
|
|
Toggles the automated power control of the host in order to save energy. |
|
|
Indicates whether power management configuration is enabled or disabled. |
|
|
Toggles whether to determine if kdump is running on the host before it is shut down. |
|
|
Fencing options for the selected type= specified with the option name="" and value="" strings. |
|
|
A valid, robust password for power management. |
|
|
Determines the power management proxy. |
|
|
Determines the power status of the host. |
|
|
Fencing device code. |
|
|
A valid user name for power management. |
6.188.1. agents
Specifies fence agent options when multiple fences are used.
Use the order sub-element to prioritize the fence agents. Agents are run sequentially according to their order until the fence action succeeds. When two or more fence agents have the same order, they are run concurrently. Other sub-elements include type, ip, user, password, and options.
6.188.2. automatic_pm_enabled
Toggles the automated power control of the host in order to save energy. When set to true, the host will be automatically powered down if the cluster’s load is low, and powered on again when required. This is set to true when a host is created, unless disabled by the user.
6.189. PowerManagementStatus enum
Name | Summary |
---|---|
|
Host is OFF. |
|
Host is ON. |
|
Unknown status. |
6.190. Product struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
6.191. ProductInfo struct
This type contains information about the product, including its name, the name of the vendor, and the version.
Name | Type | Summary |
---|---|---|
|
The name of the product, for example |
|
|
The name of the vendor, for example `ovirt. |
|
|
The version number of the product. |
6.192. ProfileDetail struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
6.195. Qos struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
6.197. Quota struct
Represents a quota object.
An example XML representation of a quota:
<quota href="/ovirt-engine/api/datacenters/7044934e/quotas/dcad5ddc" id="dcad5ddc">
<name>My Quota</name>
<description>A quota for my oVirt environment</description>
<cluster_hard_limit_pct>0</cluster_hard_limit_pct>
<cluster_soft_limit_pct>0</cluster_soft_limit_pct>
<data_center href="/ovirt-engine/api/datacenters/7044934e" id="7044934e"/>
<storage_hard_limit_pct>0</storage_hard_limit_pct>
<storage_soft_limit_pct>0</storage_soft_limit_pct>
</quota>
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.198. QuotaClusterLimit struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
6.200. QuotaStorageLimit struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
||
|
6.203. ReportedConfiguration struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.204. ReportedDevice struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
6.209. Role struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
6.211. SchedulingPolicy struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.212. SchedulingPolicyUnit struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
6.218. Session struct
Describes user session to a virtual machine.
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
Indicates if this is a console session. |
|
|
A human readable description in plain text. |
|
|
||
|
IP address user is connected from. |
|
|
A human readable name in plain text. |
|
|
Protocol used by the session. |
6.218.1. console_user
Indicates if this is a console session.
The value will be true
for console users: SPICE or VNC, false
for others: e.g. RDP, SSH.
6.219. SkipIfConnectivityBroken struct
Name | Type | Summary |
---|---|---|
|
||
|
6.221. Snapshot struct
Represents a snapshot object.
<snapshot id="456" href="/ovirt-engine/api/vms/123/snapshots/456">
<actions>
<link rel="restore" href="/ovirt-engine/api/vms/123/snapshots/456/restore"/>
</actions>
<vm id="123" href="/ovirt-engine/api/vms/123"/>
<description>Virtual Machine 1 - Snapshot A</description>
<type>active</type>
<date>2010-08-16T14:24:29</date>
<persist_memorystate>false</persist_memorystate>
</snapshot>
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
The configuration of the CPU of the virtual machine. |
|
|
||
|
||
|
Virtual machine custom compatibility version. |
|
|
||
|
||
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The virtual machine’s memory, in bytes. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
The configuration of the virtual machine’s placement policy. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.221.1. cpu
The configuration of the CPU of the virtual machine.
The sockets configuration can be updated without rebooting the virtual machine. The cores and the threads require a reboot in order to take place.
For example, to change the number of sockets to 4 immediately and the number of cores and threads to 2 after reboot send a request:
PUT /ovirt-engine/api/vms/123
With a request body:
<vm>
<cpu>
<topology>
<sockets>4</sockets>
<cores>2</cores>
<threads>2</threads>
</topology>
</cpu>
</vm>
6.221.2. custom_compatibility_version
Virtual machine custom compatibility version.
This field allows to customize a virtual machine to its own compatibility version. If
custom_compatibility_version
is set, it overrides the cluster’s compatibility version
for this particular virtual machine.
The compatibility version of a virtual machine is limited by the data center the virtual machine resides in and is checked against capabilities of the host the virtual machine is planned to run on.
6.221.3. memory
The virtual machine’s memory, in bytes.
For example, in order to update a virtual machine to contain 1 GiB of memory send a request like this:
PUT /ovirt-engine/api/vms/123
With a request body like this:
<vm>
<memory>1073741824</memory>
</vm>
Note
|
Memory in the previous example is converted to bytes using the following formula: 1 GiB = 230 bytes = 1073741824 bytes. |
Note
|
Memory hot plug is supported from oVirt 3.6 onwards. You can use the example above to increase memory while the virtual machine is running. |
6.221.4. placement_policy
The configuration of the virtual machine’s placement policy.
This configuration can be updated to pin a virtual machine to one or more hosts.
Note
|
Virtual machines that are pinned to multiple hosts cannot be live migrated, but in the event of a host failure, any virtual machine configured to be highly available is automatically restarted on one of the other hosts to which the virtual machine is pinned. |
For example, to pin a virtual machine to two hosts, you would send a request like the following:
PUT /api/vms/123
With a request body like this:
<vm>
<high_availability>
<enabled>true</enabled>
<priority>1</priority>
</high_availability>
<placement_policy>
<hosts>
<host>
<name>Host1</name>
</host>
<host>
<name>Host2</name>
</host>
</hosts>
<affinity>pinned</affinity>
</placement_policy>
</vm>
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
References to the disks attached to the virtual machine. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Link to the the list of network interface devices on the virtual machine. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.223. SnapshotType enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
6.224. SpecialObjects struct
This type contains references to special objects, like the blank template and the root of the hierarchy of tags.
Name | Type | Summary |
---|---|---|
|
Reference to the blank template. |
|
|
Reference to the root of the hierarchy of tags. |
6.227. Ssh struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
6.229. SshPublicKey struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
6.232. Statistic struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.234. StatisticUnit enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.235. Step struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.236. StepEnum enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
6.237. StepStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
6.238. StorageConnection struct
Represents a storage server connection.
Example:
<storage_connection id="123">
<address>mynfs.example.com</address>
<type>nfs</type>
<path>/exports/mydata</path>
</storage_connection>
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
6.239. StorageConnectionExtension struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
6.240. StorageDomain struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
Name | Type | Summary |
---|---|---|
|
This is used to link to the data center that the storage domain is attached to. |
|
|
This is a set of links to the data centers that the storage domain is attached to. |
|
|
||
|
||
|
||
|
||
|
Host is only relevant at creation time. |
|
|
||
|
||
|
||
|
||
|
6.241. StorageDomainStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.242. StorageDomainType enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
6.244. StorageType enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.245. SwitchType enum
Enumerated type describing all switch types currently supported by engine.
Name | Summary |
---|---|
|
Type representing native switch. |
|
Type representing Open vSwitch. |
6.246. Tag struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
6.247. Template struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
The configuration of the CPU of the virtual machine. |
|
|
||
|
||
|
Virtual machine custom compatibility version. |
|
|
||
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The virtual machine’s memory, in bytes. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.247.1. cpu
The configuration of the CPU of the virtual machine.
The sockets configuration can be updated without rebooting the virtual machine. The cores and the threads require a reboot in order to take place.
For example, to change the number of sockets to 4 immediately and the number of cores and threads to 2 after reboot send a request:
PUT /ovirt-engine/api/vms/123
With a request body:
<vm>
<cpu>
<topology>
<sockets>4</sockets>
<cores>2</cores>
<threads>2</threads>
</topology>
</cpu>
</vm>
6.247.2. custom_compatibility_version
Virtual machine custom compatibility version.
This field allows to customize a virtual machine to its own compatibility version. If
custom_compatibility_version
is set, it overrides the cluster’s compatibility version
for this particular virtual machine.
The compatibility version of a virtual machine is limited by the data center the virtual machine resides in and is checked against capabilities of the host the virtual machine is planned to run on.
6.247.3. memory
The virtual machine’s memory, in bytes.
For example, in order to update a virtual machine to contain 1 GiB of memory send a request like this:
PUT /ovirt-engine/api/vms/123
With a request body like this:
<vm>
<memory>1073741824</memory>
</vm>
Note
|
Memory in the previous example is converted to bytes using the following formula: 1 GiB = 230 bytes = 1073741824 bytes. |
Note
|
Memory hot plug is supported from oVirt 3.6 onwards. You can use the example above to increase memory while the virtual machine is running. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
References to the disks attached to the template. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
6.249. TemplateVersion struct
Name | Type | Summary |
---|---|---|
|
||
|
Name | Type | Summary |
---|---|---|
|
6.254. UnmanagedNetwork struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
6.257. User struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
Name space where user resides. |
|
|
||
|
Same as |
|
|
Username of the user. |
6.257.1. namespace
Name space where user resides. When using the authorization provider that stores users in the LDAP (see here for details) this attribute equals to naming context of the LDAP. When using the built-in authorization provider that stores users in the database (see here for details) this attribute is ignored.
6.257.2. principal
Same as user_name
principal has different formats based on LDAP provider. In case of most LDAP providers it is
value of the uid
LDAP attribute. In case of Active Directory it is the user principal name (UPN).
6.257.3. user_name
Username of the user. The format depends on authorization provider type. In case of most LDAP providers it is
value of the uid
LDAP attribute. In case of Active Directory it is the user principal name (UPN). UPN
or
uid
must be followed by authorization provider name. For example in case of LDAP using uid
attribute it is:
myuser@myextension-authz
. In case of Active Directory using UPN
it is:
myuser@mysubdomain.mydomain.com@myextension-authz
. This attribute is required parameter when adding new user.
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
6.261. Vendor struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
6.262. Version struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
6.264. VirtualNumaNode struct
Represents virtual NUMA node.
An example XML representation:
<vm_numa_node href="/ovirt-engine/api/vms/f1aa8209/numanodes/706cb6b0" id="706cb6b0">
<cpu>
<cores>
<core>
<index>0</index>
</core>
</cores>
</cpu>
<index>0</index>
<memory>1024</memory>
<numa_node_pins>
<numa_node_pin>
<host_numa_node id="007cf1ab"/>
<index>0</index>
<pinned>true</pinned>
</numa_node_pin>
</numa_node_pins>
<vm href="/ovirt-engine/api/vms/f1aa8209" id="f1aa8209"/>
</vm_numa_node>
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
Memory of the NUMA node in MB. |
|
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.266. Vm struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
The configuration of the CPU of the virtual machine. |
|
|
||
|
||
|
Virtual machine custom compatibility version. |
|
|
||
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The virtual machine’s memory, in bytes. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
The configuration of the virtual machine’s placement policy. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.266.1. cpu
The configuration of the CPU of the virtual machine.
The sockets configuration can be updated without rebooting the virtual machine. The cores and the threads require a reboot in order to take place.
For example, to change the number of sockets to 4 immediately and the number of cores and threads to 2 after reboot send a request:
PUT /ovirt-engine/api/vms/123
With a request body:
<vm>
<cpu>
<topology>
<sockets>4</sockets>
<cores>2</cores>
<threads>2</threads>
</topology>
</cpu>
</vm>
6.266.2. custom_compatibility_version
Virtual machine custom compatibility version.
This field allows to customize a virtual machine to its own compatibility version. If
custom_compatibility_version
is set, it overrides the cluster’s compatibility version
for this particular virtual machine.
The compatibility version of a virtual machine is limited by the data center the virtual machine resides in and is checked against capabilities of the host the virtual machine is planned to run on.
6.266.3. memory
The virtual machine’s memory, in bytes.
For example, in order to update a virtual machine to contain 1 GiB of memory send a request like this:
PUT /ovirt-engine/api/vms/123
With a request body like this:
<vm>
<memory>1073741824</memory>
</vm>
Note
|
Memory in the previous example is converted to bytes using the following formula: 1 GiB = 230 bytes = 1073741824 bytes. |
Note
|
Memory hot plug is supported from oVirt 3.6 onwards. You can use the example above to increase memory while the virtual machine is running. |
6.266.4. placement_policy
The configuration of the virtual machine’s placement policy.
This configuration can be updated to pin a virtual machine to one or more hosts.
Note
|
Virtual machines that are pinned to multiple hosts cannot be live migrated, but in the event of a host failure, any virtual machine configured to be highly available is automatically restarted on one of the other hosts to which the virtual machine is pinned. |
For example, to pin a virtual machine to two hosts, you would send a request like the following:
PUT /api/vms/123
With a request body like this:
<vm>
<high_availability>
<enabled>true</enabled>
<priority>1</priority>
</high_availability>
<placement_policy>
<hosts>
<host>
<name>Host1</name>
</host>
<host>
<name>Host2</name>
</host>
</hosts>
<affinity>pinned</affinity>
</placement_policy>
</vm>
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
||
|
||
|
References to the disks attached to the virtual machine. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Link to the the list of network interface devices on the virtual machine. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.267. VmAffinity enum
Name | Summary |
---|---|
|
|
|
|
|
6.268. VmBase struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
||
|
The configuration of the CPU of the virtual machine. |
|
|
||
|
||
|
Virtual machine custom compatibility version. |
|
|
||
|
||
|
||
|
||
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
The virtual machine’s memory, in bytes. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
6.268.1. cpu
The configuration of the CPU of the virtual machine.
The sockets configuration can be updated without rebooting the virtual machine. The cores and the threads require a reboot in order to take place.
For example, to change the number of sockets to 4 immediately and the number of cores and threads to 2 after reboot send a request:
PUT /ovirt-engine/api/vms/123
With a request body:
<vm>
<cpu>
<topology>
<sockets>4</sockets>
<cores>2</cores>
<threads>2</threads>
</topology>
</cpu>
</vm>
6.268.2. custom_compatibility_version
Virtual machine custom compatibility version.
This field allows to customize a virtual machine to its own compatibility version. If
custom_compatibility_version
is set, it overrides the cluster’s compatibility version
for this particular virtual machine.
The compatibility version of a virtual machine is limited by the data center the virtual machine resides in and is checked against capabilities of the host the virtual machine is planned to run on.
6.268.3. memory
The virtual machine’s memory, in bytes.
For example, in order to update a virtual machine to contain 1 GiB of memory send a request like this:
PUT /ovirt-engine/api/vms/123
With a request body like this:
<vm>
<memory>1073741824</memory>
</vm>
Note
|
Memory in the previous example is converted to bytes using the following formula: 1 GiB = 230 bytes = 1073741824 bytes. |
Note
|
Memory hot plug is supported from oVirt 3.6 onwards. You can use the example above to increase memory while the virtual machine is running. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
||
|
6.270. VmPlacementPolicy struct
Name | Type | Summary |
---|---|---|
|
Name | Type | Summary |
---|---|---|
|
6.271. VmPool struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
||
|
A human readable name in plain text. |
|
|
||
|
||
|
||
|
||
|
Virtual machine pool’s stateful flag. |
|
|
||
|
6.271.1. stateful
Virtual machine pool’s stateful flag.
Virtual machines from a stateful virtual machine pool are always started in stateful mode (stateless snapshot is not created). The state of the virtual machine is preserved even when the virtual machine is passed to a different user.
Name | Type | Summary |
---|---|---|
|
||
|
Reference to the instance type on which this pool is based. |
|
|
||
|
||
|
6.273. VmStatus enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6.276. VnicPassThrough struct
Name | Type | Summary |
---|---|---|
|
Defines if the vNIC to be implemented as a virtual device or as a pass-through to a host device. |
6.277. VnicPassThroughMode enum
The enum describes whether vNIC to be implemented as a pass-through device or a virtual one. Currently it supports only 2 option, but there is a plan to add more in the future.
Name | Summary |
---|---|
|
To be implemented as a virtual device |
|
To be implemented as a pass-through device |
6.278. VnicProfile struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
||
|
A human readable description in plain text. |
|
|
||
|
A human readable name in plain text. |
|
|
||
|
Name | Type | Summary |
---|---|---|
|
||
|
Network filter will enhance the admin ability to manage the network packets traffic from/to the participated VMs. |
|
|
||
|
6.279. VolumeGroup struct
Name | Type | Summary |
---|---|---|
|
||
|
||
|
6.280. Watchdog struct
Name | Type | Summary |
---|---|---|
|
||
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
||
|
Don’t use this element, use |
|
|
Rerefences to the virtual machines that are using this device (a device may be used by several virtual machines, for example a shared disk my be used by two or more virtual machines simultaneously). |
6.281. WatchdogAction enum
Name | Summary |
---|---|
|
|
|
|
|
|
|
|
|
6.283. Weight struct
Name | Type | Summary |
---|---|---|
|
Free text containing comments about this object. |
|
|
A human readable description in plain text. |
|
|
||
|
||
|
A human readable name in plain text. |
Name | Type | Summary |
---|---|---|
|
||
|
Appendix A: Primitive types
This section describes the primitive data types supported by the API.
A.1. String primitive
A finite sequence of Unicode characters.
A.2. Boolean primitive
Represents the false and true concepts used in mathematical logic.
The valid values are the strings false
and true
.
Case is ignored by the engine, so for example False
and FALSE
also
valid values. However the server will always return lower case values.
For backwards compatibility with older versions of the engine, the
values 0
and 1
are also accepted. The value 0
has the same meaning
than false
, and 1
has the same meaning than true
. Try to avoid
using these values, as support for them may be removed in the future.
A.3. Integer primitive
Represents the mathematical concept of integer number.
The valid values are finite sequences of decimal digits.
Currently the engine implements this type using a signed 32 bit integer, so the minimum value is -231 (-2147483648) and the maximum value is 231-1 (2147483647).
However, there are some attributes in the system where the range of values possible with 32 bit isn’t enough. In those exceptional cases the engine uses 64 bit integers, in particular for the following attributes:
-
Disk.actual_size
-
Disk.provisioned_size
-
GlusterClient.bytes_read
-
GlusterClient.bytes_written
-
Host.max_scheduling_memory
-
Host.memory
-
HostNic.speed
-
LogicalUnit.size
-
MemoryPolicy.guaranteed
-
NumaNode.memory
-
QuotaStorageLimit.limit
-
StorageDomain.available
-
StorageDomain.used
-
StorageDomain.committed
-
VmBase.memory
For these exception cases the minimum value is -263 (-9223372036854775808) and the maximum value is 263-1 (9223372036854775807).
Note
|
In the future the integer type will be implemented using unlimited precission integers, so the above limitations and exceptions will eventually disappear. |
A.4. Decimal primitive
Represents the mathematical concept of real number.
Currently the engine implements this type using 32 bit IEEE 754 single precission floating point numbers.
For some attributes this isn’t enough precission. In those exceptional cases the engine uses 64 bit double precission floating point numbers, in particular for the following attributes:
-
QuotaStorageLimit.usage
-
QuotaStorageLimit.memory_limit
-
QuotaStorageLimit.memory_usage
Note
|
In the future the decimal type will be implemented using unlimited precission decimal numbers, so the above limitations and exceptions will eventually disappear. |
A.5. Date primitive
Represents a date and time.
The format returned by the engine is the one described in the XML Schema specification when requesting XML. For example, if you send a request like this to retrieve the XML representation of a virtual machine:
GET /ovirt-engine/api/vms/123
Accept: application/xml
The response body will contain the following XML document:
<vm id="123" href="/ovirt-engine/api/vms/123">
...
<creation_time>2016-09-08T09:53:35.138+02:00</creation_time>
...
</vm>
When requesting the JSON representation the engine uses a different, format: an integer containg the number of seconds since Jan 1st 1970, also know as epoch time. For example, if you send a request like this to retrieve the JSON representation of a virtual machine:
GET /ovirt-engine/api/vms/123
Accept: application/json
The response body will contain the following JSON document:
{
"id": "123",
"href="/ovirt-engine/api/vms/123",
...
"creation_time": 1472564909990,
...
}
Note
|
In both cases, the dates returned by the engine use the time zone configured in the server where it is running, in the above examples it is UTC+2. |