HP BL680c XenServer Software Development Kit Guide 4.1.0 - Page 13

\, 3.2. Object Model Overview, 1.6. Install and start example: summary

Page 13 highlights

Overview of the XenServer API Although inactive sessions will timeout eventually, the server has a hardcoded limit of 200 concurrent sessions. Once this limit has been reached fresh logins will evict the oldest session objects, causing their associated session references to become invalid. So if you want your applications to play nice with others accessing the server concurrently, then the best policy is to create a single session at start-of-day, use this throughout the applications (note that sessions can be used across multiple separate client-server network connections) and then explicitly logout when possible. 3.1.6. "Install and start example": summary We have seen how the API can be used to install a VM from a XenServer template and perform a number of lifecycle operations on it. You will note that the number of calls we had to make in order to affect these operations was small: • One call to acquire a session: Session.login_with_password(...) • One call to query the VM (and template) objects present on the XenServer installation: VM.get_all_records(...). Recall that we used the information returned from this call to select a suitable template to install from. • Two calls to install a VM from our chosen template: VM.clone(...), followed by VM.provision(...). • One call to start the resultant VM: VM.start(...) (and similarly other single calls to suspend, resume and shutdown accordingly) • And then one call to logout Session.logout(...) The take-home message here is that, although the API as a whole is complex and fully featured, common tasks (such as creating and performing lifecycle operations on VMs) are very straightforward to perform, requiring only a small number of simple API calls. Keep this in mind while you study the next section which may, on first reading, appear a little daunting! 3.2. Object Model Overview This section gives a high-level overview of the object model of the API. A more detailed description of the parameters and methods of each class outlined here can be found in the XenEnterprise Management API document. Python, C and C# sample programs that demonstrate how the API can be used practice to accomplish a variety of tasks are available in the SDK VM and described in the following Chapter. We start by giving a brief outline of some of the core classes that make up the API. (Don't worry if these definitions seem somewhat abstract in their initial presentation; the textual description in subsequent sections, and the code-sample walk through in the next Chapter will help make these concepts concrete.) VM Host VDI A VM object represents a particular virtual machine instance on a XenServer Host or Resource Pool. Example methods include "start", "suspend", "pool_migrate"; example fields include "power_state", "memory_static_max", "name_label". (In the previous section we saw how the VM class is used to represent both templates and regular VMs) A host object represents a physical host in a XenServer pool. Example methods include "reboot" and "shutdown". Example fields include "software_version", "hostname" and [IP] "address". A VDI object represents a Virtual Disk Image. Virtual Disk Images can be attached to VMs, in which case a block device appears inside the VM through which the bits encapsulated by the Virtual Disk Image can be read and written. Example methods of the VDI class include "resize" and "clone". Example 7

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37

Overview of the XenServer API
7
Although inactive sessions will timeout eventually, the server has a hardcoded limit of 200 concurrent ses-
sions. Once this limit has been reached fresh logins will evict the oldest session objects, causing their as-
sociated session references to become invalid. So if you want your applications to play nice with others
accessing the server concurrently, then the best policy is to create a single session at start-of-day, use this
throughout the applications (note that sessions can be used across multiple separate client-server
network
connections
) and then explicitly logout when possible.
3.1.6. "Install and start example": summary
We have seen how the API can be used to install a VM from a XenServer template and perform a number
of lifecycle operations on it. You will note that the number of calls we had to make in order to affect these
operations was small:
One call to acquire a session:
Session.login_with_password(...)
One call to query the VM (and template) objects present on the XenServer installation:
VM.get_all_records(...)
. Recall that we used the information returned from this call to select a suitable
template to install from.
Two calls to install a VM from our chosen template:
VM.clone(...)
, followed by
VM.provision(...)
.
One call to start the resultant VM:
VM.start(...)
(and similarly other single calls to suspend, resume and
shutdown accordingly)
And then one call to logout
Session.logout(...)
The take-home message here is that, although the API as a whole is complex and fully featured, common
tasks (such as creating and performing lifecycle operations on VMs) are very straightforward to perform,
requiring only a small number of simple API calls. Keep this in mind while you study the next section which
may, on first reading, appear a little daunting!
3.2. Object Model Overview
This section gives a high-level overview of the object model of the API. A more detailed description of the
parameters and methods of each class outlined here can be found in the
XenEnterprise Management API
document. Python, C and C# sample programs that demonstrate how the API can be used practice to
accomplish a variety of tasks are available in the SDK VM and described in the following Chapter.
We start by giving a brief outline of some of the core classes that make up the API. (Don't worry if these
definitions seem somewhat abstract in their initial presentation; the textual description in subsequent sec-
tions, and the code-sample walk through in the next Chapter will help make these concepts concrete.)
VM
A VM object represents a particular virtual machine instance on a XenServer
Host or Resource Pool. Example methods include "start", "suspend",
"pool_migrate"; example fields include "power_state", "memory_static_max",
"name_label". (In the previous section we saw how the VM class is used to
represent both templates and regular VMs)
Host
A host object represents a physical host in a XenServer pool. Example
methods include "reboot" and "shutdown". Example fields include
"software_version", "hostname" and [IP] "address".
VDI
A VDI object represents a
Virtual Disk Image
. Virtual Disk Images can be
attached to VMs, in which case a block device appears inside the VM through
which the bits encapsulated by the Virtual Disk Image can be read and written.
Example methods of the VDI class include "resize" and "clone". Example