이 콘텐츠는 선택한 언어로 제공되지 않습니다.

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.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동