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 -2 31 (-2147483648) and the maximum value is 2 31 -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 -2 63 (-9223372036854775808) and the maximum value is 2 63 -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: 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 1 st 1970, also know as epoch time . For example, if you send a request like this to retrieve the JSON representation of a virtual machine: 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.

Commands:
GET /ovirt-engine/api/vms/123 Accept: application/xml
<vm id="123" href="/ovirt-engine/api/vms/123"> <creation_time>2016-09-08T09:53:35.138+02:00</creation_time> </vm>
GET /ovirt-engine/api/vms/123 Accept: application/json
{ "id": "123", "href="/ovirt-engine/api/vms/123", "creation_time": 1472564909990, }