-
-
-
Citrix Hypervisor 8.2 Cumulative Update 1
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Citrix Hypervisor 8.2 Management API
This document defines the Citrix Hypervisor Management API - an interface for remotely configuring and controlling virtualised guests running on a Xen-enabled host.
The API is presented here as a set of Remote Procedure Calls (RPCs). There are two supported wire formats, one based upon XML-RPC and one based upon JSON-RPC (v1.0 and v2.0 are both recognised). No specific language bindings are prescribed, although examples are given in the Python programming language.
Although we adopt some terminology from object-oriented programming, future client language bindings may or may not be object oriented. The API reference uses the terminology classes and objects. For our purposes a class is simply a hierarchical namespace; an object is an instance of a class with its fields set to specific values. Objects are persistent and exist on the server-side. Clients may obtain opaque references to these server-side objects and then access their fields via get/set RPCs.
For each class we specify a list of fields along with their types and qualifiers. A qualifier is one of:
-
RO/runtime
: the field is Read Only. Furthermore, its value is automatically computed at runtime. For example, current CPU load and disk IO throughput. -
RO/constructor
: the field must be manually set when a new object is created, but is then Read Only for the duration of the object’s life. For example, the maximum memory addressable by a guest is set before the guest boots. -
RW
: the field is Read/Write. For example, the name of a VM.
Types
The following types are used to specify methods and fields in the API Reference:
-
string
: Text strings. -
int
: 64-bit integers. -
float
: IEEE double-precision floating-point numbers. -
bool
: Boolean. -
datetime
: Date and timestamp. -
c ref
: Reference to an object of classc
. -
t set
: Arbitrary-length set of values of typet
. -
(k -> v) map
: Mapping from values of typek
to values of typev
. -
e enum
: Enumeration type with namee
. Enums are defined in the API reference together with classes that use them.
Note that there are a number of cases where ref
s are doubly linked.
For example, a VM
has a field called VIFs
of type VIF ref set
;
this field lists the network interfaces attached to a particular VM.
Similarly, the VIF
class has a field called VM
of type VM ref
which references the VM to which the interface is connected.
These two fields are bound together, in the sense that
creating a new VIF causes the VIFs
field of the corresponding
VM object to be updated automatically.
The API reference lists explicitly the fields that are bound together in this way. It also contains a diagram that shows relationships between classes. In this diagram an edge signifies the existence of a pair of fields that are bound together, using standard crows-foot notation to signify the type of relationship (e.g. one-many, many-many).
RPCs associated with fields
Each field, f
, has an RPC accessor associated with it that returns f
’s value:
-
get_f (r)
: takes aref
,r
that refers to an object and returns the value off
.
Each field, f
, with qualifier RW
and whose outermost type is set
has the
following additional RPCs associated with it:
-
add_f(r, v)
: adds a new elementv
to the set. Note that sets cannot contain duplicate values, hence this operation has no action in the case thatv
is already in the set. -
remove_f(r, v)
: removes elementv
from the set.
Each field, f
, with qualifier RW
and whose outermost type is map
has the
following additional RPCs associated with it:
-
add_to_f(r, k, v)
: adds new pairk -> v
to the mapping stored inf
in objectr
. Attempting to add a new pair for duplicate key,k
, fails with aMAP_DUPLICATE_KEY
error. -
remove_from_f(r, k)
: removes the pair with keyk
from the mapping stored inf
in objectr
.
Each field whose outermost type is neither set
nor map
, but whose
qualifier is RW
has an RPC accessor associated with it that sets its value:
-
set_f(r, v)
: sets the fieldf
on objectr
to valuev
.
RPCs associated with classes
-
Most classes have a constructor RPC named
create
that takes as parameters all fields markedRW
andRO/constructor
. The result of this RPC is that a new persistent object is created on the server-side with the specified field values. -
Each class has a
get_by_uuid(uuid)
RPC that returns the object of that class that has the specifieduuid
. -
Each class that has a
name_label
field has aget_by_name_label(name_label)
RPC that returns a set of objects of that class that have the specifiedname_label
. -
Most classes have a
destroy(r)
RPC that explicitly deletes the persistent object specified byr
from the system. This is a non-cascading delete - if the object being removed is referenced by another object then thedestroy
call will fail.
Apart from the RPCs enumerated above, some classes have additional RPCs
associated with them. For example, the VM
class has RPCs for cloning,
suspending, starting, and so on. Such additional RPCs are described explicitly
in the API reference.
Share
Share
In this article
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.