V San Service Api APIs
This is the interface for managing the lifecycle of volumes that are consumed by containers or pods, in case of Kubernetes.
This managed interface can be accessed through MOID of cns-volume-manager, through vSAN service in vCenter.
Lifecycle of a container volume includes creation, update, query, attach, detach and delete operations. This interface and its related classes are the entry point for Cloud Native Storage (abbreviated to CNS) service.
These requests could come from different container orchestrator clusters running on same vSphere as associated with this VolumeManager. VolumeManager is not aware of presence and topology of container orchestrator clusters, except for the weak association via CnsContainerCluster. This is a weak association because it's client's responsibility to provide unique identity for this container orchestrator cluster. VolumeManager will not impose any uniqueness verification on cluster identification.
Provisioning APIs of this interface return vim.Task which is vCenter Task object to track the progress of operation. In case of either partial or complete success, the state of the task would be set to success. In case of complete failure of the task when the individual specs couldn't be scheduled, the task status would be set to error. The corresponding fault, if any, will be set in the fault field. For a successfully scheduled task, result of this operation will be a list of CnsVolumeOperationResult instances. The client needs to go through the result and check the successful and failed instances.
The Task returned by provisioning APIs is a vim.Task object. Client needs to connect to vim endpoint on vCenter using the latest VSAN VMODL version (not latest VIM version) to monitor task status. After the task is complete, clients can refer to CnsVolumeOperationResult set as result field in task's TaskInfo field.
Please refer to the required privileges in the individual API documentation and ignore the Required Privileges section which is not used.
This managed object consolidates vSAN Health APIs that operate on a single ESXi host, i.e., the APIs in this Managed Object do not correlate health among multiple nodes in a vSAN cluster.
Typically this level is not very
useful for direct user consumption, and the cluster level APIs should be used
instead. The cluster level APIs build upon the APIs in this Managed Object.
All information retrieved is as seen by this host, which under network
partitions is not the global view.
The ManagedEntity can be accessed with MOID of 'ha-vsan-health-system',
through vSAN service at at ESXi host side.
The VsanSystem managed object type exposes VSAN configuration primitives and serves as a host-level access point for relevant VSAN data objects.
VimClusterVsanVcDiskManagementSystem enhances vSAN disk management part, provides vSAN all flash disk group support, exposes more detailed information of vSAN disk group, helps on configure and manage vSAN disk group.
It deprecates APIs AddDisks_Task and
InitializeDisks_Task, exposes
VimVsanHostDiskMapInfoEx through API
QueryDiskMappings,
to present whether a disk group is all flash, and whether
deduplication and compression is enabled on this disk group,
and deprecates diskMapping
exposed by config.
The ManagedEntity can be accessed through MOID of
vsan-disk-management-system, through vSAN service at vCenter
server side.
vSAN stretched Cluster is a specific configuration implemented in environments where disaster/downtime avoidance is a key requirement.
vSAN stretched Clusters with Witness Host refers to a deployment
where a user sets up a vSAN cluster with 2 active/active sites with
numbers of ESXi hosts between the two sites. The sites are connected via a
high bandwidth/low latency link.
The third site hosting the vSAN Witness Host is connected to both of
the active/active data-sites. This connectivity can be via low bandwidth/high
latency links.
Each site is configured as a vSAN Fault Domain. The nomenclature used
to describe a vSAN stretched Cluster configuration is X+Y+Z, where X is
the number of ESXi hosts at data site A, Y is the number of ESXi hosts at data
site B, and Z is the number of witness hosts at site C. Data sites are where
virtual machines are deployed.
The maximum configuration is 15+15+1 (31 nodes).
vSAN Remote Office / Branch Office Deployment, aka ROBO cluster,
is a specific deployment of vSAN stretched cluster. A two-node
vSAN cluster, and a vSphere vSAN witness host appliance as
witness, forms a vSAN ROBO cluster. Copies of vSAN objects
that make up a virtual machine are typically stored in two physical nodes,
if one of the physical nodes is offline, it is still possible for virtual
machines to run using the files located on another physical node. In the
case where the hosts in a two-node cluster are unable to communicate across
the network, the witness serves as a "tie-breaker" to achieve a quorum and
enables the cluster to restart virtual machines impacted by an outage.
Details to deploy a vSAN stretched cluster, please reference to API
VSANVcConvertToStretchedCluster,
and for ROBO cluster, please assign
witness appliance to parameter 'witnessHost', and each physical host stands
for a Fault Domain.
VsanVcStretchedClusterSystem is used to configure and manage vSAN
stretched cluster. The ManagedEntity can be accessed through MOID of
vsan-stretched-cluster-system, through vSAN service at vCenter server
side.
The VsanCapabilitySystem exposes interfaces to retrieve the supported capabilities on the current system.
The Managed Entity can be accessed through MOID of vsan-vc-capability-system at vCenter server side or vsan-capability-system at ESXi server side.
The vSAN Cluster Health System exposes the vSAN cluster health service API and serves as an aggregator to collect the result from each of hosts in the vSAN cluster.
This system provides interfaces to remediate inconsistency of vSAN configurations at both cluster and host level.
It can be accessed through MOID vsan-cluster-mgmt-internal-system at vCenter side.
This managed object type provides the service interface for vsan cluster power action.
i.e. power off a whole cluster, query current cluster power context, power on the cluster, etc. The vSAN cluster power system will be supported in both of VC and ESXi host. When the ManagedEntity is accessed with MOID of 'vsan-cluster-power-system' through vSAN service at vCenter server, it acts as cluster-level APIs. When it accessed with MOID of 'ha-vsan-power-system' through vSAN service at ESXi host side, its scope is only limited to that host.
This managed object provides the diagnostics service that operates at cluster level.
It runs the periodical diagnostics on the vSAN related statistics, as well as the on-demand diagnostics operation, e.g., the diagnostics of the IOs for a certain virtual machine. The ManagedEntity can be accessed with MOID of 'vsan-cluster-diagnostics-system' through vSAN service at at vCenter side.
This managed object type provides the file service related configuration and query APIs.
It can be accessed through MOID of 'vsan-cluster-file-service-system', through vSAN service on vCenter at cluster level, or accessed through MOID of 'vsan-file-service-system' on ESXi host for the detailed operation.
vSAN optimized methods for assisting VDS related operations, especially migrations from VSS to VDS.
In every ESXi host there is a singleton instance of this class with the Managed Object ID of 'ha-vsan-host-vds-system'.
This managed object is designed to provide service interfaces to manage ioinsight(s) for VMs virtual disks I/O performance metrics monitor and collection on the target hosts.
It can be accessed through MOID of 'vsan-cluster-ioinsight-manager' via vSAN service on vCenter, or accessed through MOID of 'vsan-ioinsight-manager' on ESXi host.
The VsanIscsiTargetSystem exposes interfaces from vCenter to perform vSAN iSCSI target service related operations.
To access these APIs from vCenter, user should possess correct privileges of the target cluster: cluster edit privilege is required for the adding, editing and removal of target, LUN, initiator and initiator group, while system read/view privilege is required for the view of these entities. The Managed Entity can be accessed through MOID of vsan-cluster-iscsi-target-system, through vSAN service at both vCenter server and ESXi host side.
VsanMassCollector contains a collection of APIs to query vSAN management API's and values of managed object properties.
The Managed Entity can be accessed through MOID of vsan-mass-collector through vSAN service at vCenter server side.
This managed object type provides the service interface for setting the
storage policy to one vSAN object, querying the vSAN object
status information, i.e., its storage profile, its health status.
When the ManagedEntity is accessed with MOID of 'vsan-cluster-object-system'
through vSAN service at vCenter server and ESXi host side, it acts as
cluster-level APIs.
When it accessed with MOID of 'vsan-object-system' through vSAN service at ESXi host side, its scope is only limited to that host.
This managed object type provides the service interface for obtaining statistical data about various aspects of vSAN performance, as generated and maintained by the vSAN performance service of the cluster.
It also offers methods to enable/disable, configure and perform other maintenance tasks about the vSAN performance service. It is available on both vCenter as well as ESXi under the vSAN extension endpoint. On both systems a singleton object is registered under the Managed Object ID 'vsan-performance-manager'.
All the vSAN hosts belongs to one of the following two type in performance service perspective.
Stats Master node: see VsanPerfNodeInformation
Agent node: all other nodes except the master node, which collect its performance statistics when receive the request from master then send it back.
VsanPhoneHomeSystem contains a collection of APIs to perform online health checks.
The Managed Entity can be accessed through MOID of vsan-phonehome-system through vSAN service at vCenter server side.
The managed object provides support for vSAN remote datastore management operations.
It can be accessed with MOID of 'vsan-remote-datastore-system', through vSAN service at vCenter server side.
This managed object type provides interfaces to perform resource check and query for various operations, e.g.
host enter maintenance mode, disk upgrade. It can be accessed through MOID of 'vsan-cluster-resource-check-system', via vSAN service on vCenter at cluster level, or accessed through MOID of 'vsan-resource-check-system' on ESXi host.
This managed object type provides the service interface to report the
vSAN cluster space usage information including the space overview, the
space usage breakdown to various vSAN object types and the vSAN data
efficiency info after enabling vSAN deduplication.
The ManagedEntity can be accessed with MOID of 'vsan-cluster-space-report-system',
through vSAN service at vCenter server side.
This managed object provides extended APIs to enrich HostVsanSystem's functionality, operating at a single ESXi host level.
HostVsanSystem is still valid and provided by vSphere Management SDK. HostVsanSystem and VsanSystemEx should be used in combination for different operations to vSAN. It can be accessed with MOID of 'vsanSystemEx' through vSAN service at ESXi host side. It can be also accessed with MOID of 'vsanSystemEx-<hostId>' through vSAN service at vCenter server side, where <hostId> is the ID at the end of the host's MOID: 'host-<hostId>'. For example, if a host's MOID is 'host-5', then 'vsanSystemEx-5' should be used to access this host's VsanSystemEx MO.
Generic engine that can install VIBs onto ESX (optimized for vSAN clusters) using either rolling installs or one-shot.
In addition to VIBs, it can also install firmware updates for select hardware. The Managed Entity can be accessed through MOID of vsan-update-manager, through vSAN service at ESXi host side.
It deprecates vim.VsanUpgradeSystem, to take care of vSAN upgrade process.
It has capability to support additional advanced disk format conversion specification, to help on configuration of latest vSAN advanced features. It supports following vSAN on-disk format versions:
- version 1, released by vSAN 1.0, vSphere ESXi 5.5U1;
- version 2, released by vSAN 6.0, which supports Virsto file system;
- version 3, released by vSAN 6.2, which supports vSAN deduplication and compression.
It can be accessed with MOID vsan-upgrade-systemex through vSAN service at vCenter server side.
This managed object type provides a comprehensive way to manage vSAN cluster configuration in below areas:
- Enable or disable vSAN
- Enable or disable Autoclaim mode for disk group
- Enable or disable data efficiency feature
- Configure vSAN iSCSI target feature
- Manage disk groups
- Manage fault domains
- Retrieve vSAN generic configuration
- Retrieve data efficiency configuration
In this class, ReconfigureEx enhances the legacy API ReconfigureComputeResource_Task.
Legacy API
ReconfigureComputeResource_Task is deprecated.
The ManagedEntity can be accessed with MOID of 'vsan-cluster-config-system',
through vSAN service at vCenter server side.
This managed object provides access to vSAN Health related configuration and query APIs, operating at a vSAN cluster level.
It can be accessed through MOID of 'vsan-cluster-health-system', through vSAN service at vCenter server side.
Deployment engine that allows the deploy of VCSA (Virtual Center Service Appliance) onto a vSAN datastore.
The Managed Entity can be accessed through MOID of vsan-vcsa-deployer-system at vCenter server and ESXi host side.
vSAN optimized methods for performing VDS related operations, especially migrations from VSS to VDS.
In every vCenter server there is a singleton instance of this class with the Managed Object ID of 'vsan-vds-system'.
As vSAN VUM integration feature is mostly an automatic backend feature, so currently only get and set config methods are available in its control path.
The Managed Entity can be accessed through MOID of vsan-vum-system at vCenter server side.