Red Hat Training

A Red Hat training course is available for Red Hat Virtualization

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 precision floating point numbers.

For some attributes this isn’t enough precision. In those exceptional cases the engine uses 64 bit double precision 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 precision 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 containing 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.