# Types

# appliance

# appliance access

## shell

`shell` service provides operations Get/Set enabled state of BASH.

Type | Description
--- | ---
appliance.access.shell.shell_config | `shell_config` structure Structure that defines shell configuration.

## monitoring

`monitoring` service provides operations Get and list monitoring data for requested item.

Type | Description
--- | ---
appliance.monitoring.monitored_item | `monitored_item` structure Structure representing requested monitored item data.
appliance.monitoring.monitored_item_data | `monitored_item_data` structure Structure representing monitored item data.
appliance.monitoring.monitored_item_data_request | `monitored_item_data_request` structure Structure representing requested monitored item data.

# appliance networking

# appliance networking dns

## hostname

`hostname` service provides operations Performs operations on Fully Qualified Doman Name.

Type | Description
--- | ---
appliance.networking.dns.hostname.message | `message` structure Test result and message
appliance.networking.dns.hostname.test_status_info | `test_status_info` structure Overall test result

## servers

`servers` service provides operations DNS server configuration.

Type | Description
--- | ---
appliance.networking.dns.servers.DNS_server_config | `DNS_server_config` structure This structure represents the configuration state used to determine DNS servers.
appliance.networking.dns.servers.message | `message` structure Test result and message
appliance.networking.dns.servers.test_status_info | `test_status_info` structure Overall test result

## interfaces

`interfaces` service provides operations Provides information about network interface.

Type | Description
--- | ---
appliance.networking.interfaces.interface_info | `interface_info` structure Structure that defines properties and status of a network interface.

# appliance recovery

# appliance recovery backup

Type | Description
--- | ---
appliance.recovery.backup.backup_request | `backup_request` structure Structure representing requested backup piece
appliance.recovery.backup.localizable_message | `localizable_message` structure Structure representing message
appliance.recovery.backup.return_result | `return_result` structure Structure representing precheck result

## job

`job` service provides operations Performs backup restore operations

Type | Description
--- | ---
appliance.recovery.backup.job.backup_job_status | `backup_job_status` structure Structure representing backup restore status
appliance.recovery.backup.job.backup_request | `backup_request` structure Structure representing requested backup piece
appliance.recovery.backup.job.localizable_message | `localizable_message` structure Structure representing message
appliance.recovery.backup.job.return_result | `return_result` structure Structure representing precheck result

## parts

`parts` service provides operations Provides list of parts optional for the backup

Type | Description
--- | ---
appliance.recovery.backup.parts.localizable_message | `localizable_message` structure Structure representing message
appliance.recovery.backup.parts.part | `part` structure Structure representing backup restore part

# appliance recovery restore

Type | Description
--- | ---
appliance.recovery.restore.localizable_message | `localizable_message` structure Structure representing message
appliance.recovery.restore.metadata | `metadata` structure Structure representing metadata
appliance.recovery.restore.restore_request | `restore_request` structure Structure representing requested restore piece

## job

`job` service provides operations Performs restore operations

Type | Description
--- | ---
appliance.recovery.restore.job.localizable_message | `localizable_message` structure Structure representing message
appliance.recovery.restore.job.restore_job_status | `restore_job_status` structure Structure representing backup restore status
appliance.recovery.restore.job.restore_request | `restore_request` structure Structure representing requested restore piece
appliance.recovery.restore.job.return_result | `return_result` structure Structure representing precheck result

# appliance system

## storage

`storage` service provides operations Appliance storage configuration

Type | Description
--- | ---
appliance.system.storage.storage_mapping | `storage_mapping` structure FIXME: no docstring

## time

`time` service provides operations Gets system time.

Type | Description
--- | ---
appliance.system.time.system_time_struct | `system_time_struct` structure Structure representing the system time.

## version

`version` service provides operations Get the appliance version.

Type | Description
--- | ---
appliance.system.version.version_struct | `version_struct` structure Structure representing appliance version information.

# appliance techpreview

# appliance techpreview localaccounts

## user

`user` service provides operations Perform operations on local user account.

Type | Description
--- | ---
appliance.techpreview.localaccounts.user.new_user_config | `new_user_config` structure Structure that defines a new user configuration.
appliance.techpreview.localaccounts.user.user_config | `user_config` structure Structure that defines a new user configuration for CLI.
appliance.techpreview.localaccounts.user.user_config_get | `user_config_get` structure Structure defines a user configuration for user.get API.

# appliance techpreview monitoring

## snmp

`snmp` service provides operations SNMP agent operations.

Type | Description
--- | ---
appliance.techpreview.monitoring.snmp.SNM_pv1_trap_target | `SNM_pv1_trap_target` structure Structure that defines an SNMP v1/v2c trap target.
appliance.techpreview.monitoring.snmp.SNM_pv3_target | `SNM_pv3_target` structure Structure that defines an SNMP v3 inform or trap target.
appliance.techpreview.monitoring.snmp.SNMP_config | `SNMP_config` structure Structure that defines the SNMP configuration, provided as input to set(), and never the result of get(). See SNMPConfigReadOnly. This structure is used to configure SNMP v1, v2c, and v3.
appliance.techpreview.monitoring.snmp.SNMP_config_read_only | `SNMP_config_read_only` structure Structure that defines the SNMP configuration, the result of get(), and never provided as input to set(). This structure differs from SNMPConfig because it contains localized keys (as defined in http://tools.ietf.org/html/rfc3826#section-1.2), instead of raw secret strings. This structure can be used to configure SNMP v1, v2c, and v3. Keep this structure in sync with vmw_snmp.py:_default_config(). Note that if a field if left empty, it is considered unset and will be ignored. Existing array elements below can be unset by sending an element with the string 'reset'.
appliance.techpreview.monitoring.snmp.SNMP_hash_config | `SNMP_hash_config` structure Structure to provide up to two secrets to combine with the SNMPv3 engine ID and authentication or privacy protocol to form a localized hash. auth_hash is always required, priv_hash can be empty. By default arguments are paths on the local filesystem, raw_secret takes path to be the actual raw secret. First implementation was in ESXi: esxcli system snmp hash --help
appliance.techpreview.monitoring.snmp.SNMP_hash_results | `SNMP_hash_results` structure Structure to provide operators diagnostics test results.
appliance.techpreview.monitoring.snmp.SNMP_limits | `SNMP_limits` structure Structure that provides various limits of the SNMP agent.
appliance.techpreview.monitoring.snmp.SNMP_remote_user | `SNMP_remote_user` structure Structure that defines a user at particular remote SNMPv3 entity needed when using informs. auth_key and priv_key contained localized keys as defined in http://tools.ietf.org/html/rfc3826#section-1.2.
appliance.techpreview.monitoring.snmp.SNMP_stats | `SNMP_stats` structure Structure to provide operators diagnostics on snmp agent itself.
appliance.techpreview.monitoring.snmp.SNMP_test_results | `SNMP_test_results` structure Structure to provide operators diagnostics test results.
appliance.techpreview.monitoring.snmp.SNMP_user | `SNMP_user` structure Structure that defines information associated with an SNMP user. authKey and privKey are localized keys defined in http://tools.ietf.org/html/rfc3826#section-1.2.

# appliance techpreview networking

####

# appliance techpreview networking firewall addr

## inbound

`inbound` service provides operations Operations for Firewall rules.

Type | Description
--- | ---
appliance.techpreview.networking.firewall.addr.inbound.delete_firewall_rule | `delete_firewall_rule` structure Structure that defines networking.firewall.addr.inbound.delete api input argument
appliance.techpreview.networking.firewall.addr.inbound.firewall_address_rule | `firewall_address_rule` structure Structure that defines a single address-based firewall rule.

## ipv4

`ipv4` service provides operations Performs IPV4 network configuration for interfaces.

Type | Description
--- | ---
appliance.techpreview.networking.ipv4.I_pv4_config | `I_pv4_config` structure Structure that defines the IPv4 configuration state of a network interface.
appliance.techpreview.networking.ipv4.I_pv4_config_read_only | `I_pv4_config_read_only` structure Structure that defines the IPv4 configuration state of a network interface.

## ipv6

`ipv6` service provides operations Performs IPV4 network configuration for interfaces.

Type | Description
--- | ---
appliance.techpreview.networking.ipv6.I_pv6_address | `I_pv6_address` structure Structure used to name an IPv6 address.
appliance.techpreview.networking.ipv6.I_pv6_address_read_only | `I_pv6_address_read_only` structure Structure that you can use to get information about an IPv6 address along with its origin and status.
appliance.techpreview.networking.ipv6.I_pv6_config | `I_pv6_config` structure Structure that you can use to configure IPv6 on a particular interface. Because IPv6 permits multiple addresses per interface, addresses can be assigned by DHCP, SLAAC, and can also be statically assigned.
appliance.techpreview.networking.ipv6.I_pv6_config_read_only | `I_pv6_config_read_only` structure Structure that defines an existing IPv6 configuration on a particular interface. This structure is read only.

## proxy

`proxy` service provides operations Proxy configuration.

Type | Description
--- | ---
appliance.techpreview.networking.proxy.message | `message` structure Test result and message
appliance.techpreview.networking.proxy.proxy_config | `proxy_config` structure Structure that defines proxy configuration.
appliance.techpreview.networking.proxy.proxy_config_multiple | `proxy_config_multiple` structure Structure representing multiple proxy configuration.
appliance.techpreview.networking.proxy.proxy_config_test | `proxy_config_test` structure Structure that defines proxy configuration.
appliance.techpreview.networking.proxy.test_status_info | `test_status_info` structure Overall test result

## routes

`routes` service provides operations Performs networking routes operations.

Type | Description
--- | ---
appliance.techpreview.networking.routes.message | `message` structure Test result and message
appliance.techpreview.networking.routes.route | `route` structure Structure that describes how routing is performed for a particular destination and prefix. A destination/prefix of 0.0.0.0/0 ( for IPv4) or ::/0 (for IPv6) refers to the default gateway.
appliance.techpreview.networking.routes.route_read_only | `route_read_only` structure Structure that describes how routing is performed for a particular destination and prefix. A destination/prefix of 0.0.0.0/0 ( for IPv4) or ::/0 (for IPv6) refers to the default gateway.
appliance.techpreview.networking.routes.test_status_info | `test_status_info` structure Overall test result

## ntp

`ntp` service provides operations Gets NTP configuration status and tests connection to ntp servers.

Type | Description
--- | ---
appliance.techpreview.ntp.message | `message` structure Test result and message
appliance.techpreview.ntp.NTP_config | `NTP_config` structure Structure defining the NTP configuration.
appliance.techpreview.ntp.test_status_info | `test_status_info` structure Overall test result

## services

`services` service provides operations Manages services.

Type | Description
--- | ---
appliance.techpreview.services.service_info | `service_info` structure Structure that describes a service and the operations you can perform on a service.

## shutdown

`shutdown` service provides operations Performs reboot/shutdow operations on appliance.

Type | Description
--- | ---
appliance.techpreview.shutdown.shutdown_config | `shutdown_config` structure Structure that defines shutdown configuration.
appliance.techpreview.shutdown.shutdown_get_config | `shutdown_get_config` structure Structure that defines shutdown configuration returned by Shutdown.get operation

# appliance techpreview system

## update

`update` service provides operations Performs update repository configuration.

Type | Description
--- | ---
appliance.techpreview.system.update.update_struct_get | `update_struct_get` structure Structure to get url update repository.
appliance.techpreview.system.update.update_struct_set | `update_struct_set` structure Structure to set url update repository.

## timesync

`timesync` service provides operations Performs time synchronization configuration.

Type | Description
--- | ---
appliance.techpreview.timesync.time_sync_config | `time_sync_config` structure Structure defining time synchronization configuration.

# appliance vmon

The `appliance.vmon` API provides services to manage a set of services that are part of the vCenter Server.

## service

The `service` service provides operations to manage a single/set of services that are managed by vMon.

Type | Description
--- | ---
appliance.vmon.service.info | The `info` structure contains information about a service.
appliance.vmon.service.update_spec | The `update_spec` structure describes the changes to be made to the configuration of the service.

# cis

The `cis` component provides operations and structures for session management.

####

# cis data legacy

Copyright 2015 VMware, Inc. All rights reserved. -- VMware Confidential

## resource model

Represents a uniform query interface for search and retrieval of arbitrary projections onto given resource model data. Provides a convenient API for search and navigation through the CIS inventory using filtering by various resource model property criteria, including on properties of related resources.

Type | Description
--- | ---
cis.data.legacy.resource_model.composite_filter | Defines a composition of multiple resource filter criteria. The results set is filtered by evaluating the constituent filters and using the specified composite operator.
cis.data.legacy.resource_model.property_filter | Defines a filter criteria that matches all resources that have a certain property whose value satisfies a specified comparison predicate. If needed, the property filter predicate may also be defined on a property of a related resource.
cis.data.legacy.resource_model.property_value | Contains the value of a specific resource model property.
cis.data.legacy.resource_model.query_spec | A query specification that describes a request for resource model data from a specific set of resources. It supports filtering the resources to return by various conditions on their own or related resources properties and retrieval of arbitrary number of properties or sub-properties of the resources that satisfy the filter criteria. It also allows for sorting and paging the final result set. The query specification has the following main constituents: Resource Filter: restricts (filters) the set of resources to be returned for the query. Corresponds to the `WHERE` clause in SQL. Provides abilities to specify comparison predicates on the properties of the resources to search for or even on properties of their related resources as well as arbitrary compositions of such predicates. Property Specification: specifies the properties of the filtered set of resources to be included in the result set for the query. Each property specification begins with the fully-qualified name of the resource model that declares the property, followed by the name of the property. The property name could be either a single property name, in case of an immediate property of the resource model or a property path, i.e. chain of property names, separated with `/` symbol to indicate a child property, e.g. `com.acme.PersonModel/relatives/father`. Sort Criteria: defines how the final result set should be sorted by comparing the values of one or more properties of the items in the result set. Page Specification: specifies what portion of the final sorted result set should be returned to the client. Defined by a combination of two fields: cis.data.legacy.resource_model.query_spec.offset and cis.data.legacy.resource_model.query_spec.limit.
cis.data.legacy.resource_model.resource_filter | Specifies the filter criteria that each resource should satisfy in order to qualify for the final result set for a given query.
cis.data.legacy.resource_model.resource_item | Contains the data returned for a single resource, which corresponds to a single item in the result set. Represents a projection onto the public state of the resource model data of the given resource.
cis.data.legacy.resource_model.result_set | Contains the data returned in response to a particular query instance.
cis.data.legacy.resource_model.sort_spec | Determines how a list of result items should be sorted by the values of one or more properties that belong to the models associated with the resources that the result items represent.
cis.data.legacy.resource_model.typed_ID | Represents a typed resource identifier which uniquely identifies the resource within the scope of the service.

## session

The `session` service allows API clients to manage session tokens including creating, deleting and obtaining information about sessions.

- The create operation creates session token in exchange for another authentication token.
- The delete operation invalidates a session token.
- The get retrieves information about a session token.

The call to the create operation is part of the overall authentication process for API clients. For example, the sequence of steps for establishing a session with SAML token is:

- Connect to lookup service.
- Discover the secure token service (STS) endpoint URL.
- Connect to the secure token service to obtain a SAML token.
- Authenticate to the lookup service using the obtained SAML token.
- Discover the API endpoint URL from lookup service.
- Call the create operation. The create call must include the SAML token.

See the programming guide and samples for additional information about establishing API sessions.

Execution Context and Security Context

To use session based authentication a client should supply the session token obtained through the create operation. The client should add the session token in the security context when using SDK classes. Clients using the REST API should supply the session token as a HTTP header.

Session Lifetime

A session begins with call to the create operation to exchange a SAML token for a API session token. A session ends under the following circumstances:

- Call to the delete operation.
- The session expires. Session expiration may be caused by one of the following situations:
  - Client inactivity - For a particular session identified by client requests that specify the associated session ID, the lapsed time since the last request exceeds the maximum interval between requests.
  - Unconditional or absolute session expiration time: At the beginning of the session, the session logic uses the SAML token and the system configuration to calculate absolute expiration time.

When a session ends, the authentication logic will reject any subsequent client requests that specify that session. Any operations in progress will continue to completion.

Error Handling

The cis.session returns the following errors:

- vapi.std.errors.unauthenticated error for any errors related to the request.
- vapi.std.errors.service_unavailable error for all errors caused by internal service failure.

Type | Description
--- | ---
cis.session.info | Represents data associated with an API session.

# cis tagging

Copyright 2013-2014 VMware, Inc. All rights reserved. -- VMware Confidential Copyright 2013-2014 VMware, Inc. All rights reserved. -- VMware Confidential Copyright 2013-2014 VMware, Inc. All rights reserved. -- VMware Confidential Copyright 2013-2015 VMware, Inc. All rights reserved. -- VMware Confidential Copyright 2013-2014 VMware, Inc. All rights reserved. -- VMware Confidential The `cis.tagging` component provides operations and structures to attach metadata, by means of tags, to vSphere objects to make these objects more sortable and searchable. You can use it to create, manage, and enumerate tags and their categories (the group a tag belongs to). You can also query the attached tags and attached objects.

Type | Description
--- | ---
cis.tagging.category_model | The `category_model` structure defines a category that is used to group one or more tags.
cis.tagging.tag_model | The `tag_model` structure defines a tag that can be attached to vSphere objects.

## category

The `category` service provides operations to create, read, update, delete, and enumerate categories.

Type | Description
--- | ---
cis.tagging.category.create_spec | The `create_spec` structure is used to create a category. Use the create operation to create a category defined by the create specification.
cis.tagging.category.update_spec | The `update_spec` structure describes the updates to be made to an existing category. Use the update operation to modify a category. When you call the operation, specify the category identifier. You obtain the category identifier when you call the create operation. You can also retrieve an identifier by using the list operation.

## tag

The `tag` service provides operations to create, read, update, delete, and enumerate tags.

Type | Description
--- | ---
cis.tagging.tag.create_spec | The `create_spec` structure describes a tag. Use the create operation to create a tag defined by the create specification.
cis.tagging.tag.update_spec | The `update_spec` structure describes the updates to be made to an existing tag. Use the update operation to modify a tag. When you call the operation, you specify the tag identifier. You obtain the tag identifier when you call the create operation. You can also retrieve an identifier by using the list operation.

## tag association

The `tag_association` service provides operations to attach, detach, and query tags.

Type | Description
--- | ---
cis.tagging.tag_association.batch_result | The `batch_result` structure describes the result of performing the same operation on several tags or objects in a single invocation.
cis.tagging.tag_association.object_to_tags | The `object_to_tags` structure describes an object and its related tags. Use the list_attached_tags_on_objects operation to retrieve a array with each element containing an object and the tags attached to it.
cis.tagging.tag_association.tag_to_objects | The `tag_to_objects` structure describes a tag and its related objects. Use the list_attached_objects_on_tags operation to retrieve a array with each element containing a tag and the objects to which it is attached.

# content

The Content API provides structures and services for configuring global settings and permissions, and for managing libraries in the Content Library Service.

Type | Description
--- | ---
content.configuration_model | The `configuration_model` structure defines the global settings of the Content Library Service.
content.library_model | The content.library_model structure represents a Content Library resource model. A `library_model` is a container for a set of items which represent a usable set of files. The Content Library Service allows for multiple libraries to be created with separate authorization and sharing policies. Each `library_model` is a container for a set of content.library.item_model instances. Each item is a logical object in a library, which may have multiple files. A `library_model` may be local or subscribed. A local library has its source of truth about items within this Content Library Service. Items may be added to or removed from the library. A local library may also be private or published. When published, the library is exposed by a network endpoint and can be used by another Content Library Service for synchronization. A private local library cannot be used for synchronization. A subscribed library is a library which gets its source of truth from another library that may be across a network in another Content Library Service. A subscribed library may have a different name and metadata from the library to which it subscribes, but the set of library items is always the same as those in the source library. Library items cannot be manually added to a subscribed library -- they can only be added by adding new items to the source library.

# content library

The Content Library API provides structures and services for defining and managing the library's items, subscription, publication, and storage.

Type | Description
--- | ---
content.library.find_spec | Specifies the properties that can be used as a filter to find libraries. When multiple fields are specified, all properties of the library must match the specification.
content.library.item_model | The `item_model` structure represents a library item that has been stored in a library. A `item_model` represents a single logical unit to be managed within a content.library_model. Items contain the actual content of a library, and their placement within a library determines policies that affect that content such as publishing. A library item can have a specified type, indicated with the content.library.item_model.type field. This property is associated with a Content Library Service plugin that supports specific types and provides additional services. The types available in a specific Content Library Service can be queried using the content.type service. Items of an unknown or unspecified type are treated generically. Because subscribed library catalogs are synchronized as is, subscribing to a remote Content Library Service effectively gives you a library with the functionality of the remote service's type adapter plugins, even if they are not installed locally. Items can be managed using the content.library.item service and, for items in subscribed libraries, the content.library.subscribed_item service.
content.library.optimization_info | The `optimization_info` structure defines different optimizations and optimization parameters applied to particular library.
content.library.publish_info | The `publish_info` structure defines how a local library is published publicly for synchronization to other libraries.
content.library.storage_backing | The `storage_backing` structure defines a storage location where content in a library will be stored. The storage location can either be a Datastore or Other type.
content.library.subscription_info | The `subscription_info` structure defines the subscription behavior for a subscribed library.

# content library item

The Content Library Item API provides structures and services for managing files in a library item.

Type | Description
--- | ---
content.library.item.download_session_model | The `download_session_model` structure provides information on an active content.library.item.download_session resource.
content.library.item.find_spec | The `find_spec` structure specifies the properties that can be used as a filter to find library items. When multiple fields are specified, all properties of the item must match the specification.
content.library.item.transfer_endpoint | The `transfer_endpoint` structure encapsulates a URI along with extra information about it.
content.library.item.update_session_model | The `update_session_model` structure provides information on an active content.library.item.update_session resource.

# content library item downloadsession

The Content Library Item Download Session API provides structures and services for downloading files in a session.

## file

The `file` service provides operations for accessing files within a download session.

After a download session is created against a library item, the `file` service can be used to retrieve all downloadable content within the library item. Since the content may not be available immediately in a downloadable form on the server side, the client will have to prepare the file and wait for the file status to become PREPARED.

See content.library.item.download_session.

Type | Description
--- | ---
content.library.item.downloadsession.file.info | The `info` structure defines the downloaded file.

## file

The `file` service can be used to query for information on the files within a library item. Files are objects which are added to a library item through the content.library.item.update_session and content.library.item.updatesession.file services.

Type | Description
--- | ---
content.library.item.file.checksum_info | Provides checksums for a content.library.item.file.info object.
content.library.item.file.info | The `info` structure provides information about a file in Content Library Service storage. A file is an actual stored object for a library item. An item will have zero files initially, but one or more can be uploaded to the item.

## storage

`storage` is a resource that represents a specific instance of a file stored on a storage backing. Unlike content.library.item.file, which is abstract, storage represents concrete files on the various storage backings. A file is only represented once in content.library.item.file, but will be represented multiple times (once for each storage backing) in `storage`. The `storage` service provides information on the storage backing and the specific location of the file in that backing to privileged users who want direct access to the file on the storage medium.

Type | Description
--- | ---
content.library.item.storage.info | The `info` structure is the expanded form of content.library.item.file.info that includes details about the storage backing for a file in a library item.

# content library item updatesession

The Content Library Item Update Session API provides structures and services for updating files in a session.

## file

The `file` service provides operations for accessing files within an update session.

After an update session is created against a library item, the `file` service can be used to make changes to the underlying library item metadata as well as the content of the files. The following changes can be made:

- deleting an existing file within the library item. This deletes both the metadata and the content.
- updating an existing file with new content.
- adding a new file to the library item.

The above changes are not applied or visible until the session is completed. See content.library.item.update_session.

Type | Description
--- | ---
content.library.item.updatesession.file.add_spec | The `add_spec` structure describes the properties of the file to be uploaded.
content.library.item.updatesession.file.info | The `info` structure defines the uploaded file.
content.library.item.updatesession.file.validation_error | The `validation_error` structure defines the validation error of a file in the session.
content.library.item.updatesession.file.validation_result | The `validation_result` structure defines the result of validating the files in the session.

## subscribed library

Type | Description
--- | ---
content.subscribed_library.probe_result | The `probe_result` structure defines the subscription information probe result. This describes whether using a given subscription URL is successful or if there are access problems, such as SSL errors.

## type

The `type` service exposes the content.library.item_model types that this Content Library Service supports.

A library item has an optional type which can be specified with the content.library.item_model.type field. For items with a type that is supported by a plugin, the Content Library Service may understand the files which are part of the library item and can produce metadata for the item.

In other cases, uploads may require a process in which one upload implies subsequent uploads. For example, an Open Virtualization Format (OVF) package is composed of an OVF descriptor file and the associated virtual disk files. Uploading an OVF descriptor can enable the Content Library Service to understand that the complete OVF package requires additional disk files, and it can set up the transfers for the disks automatically by adding the file entries for the disks when the OVF descriptor is uploaded.

When a type is not supported by a plugin, or the type is not specified, the Content Library Service can handle a library item in a default way, without adding metadata to the item or guiding the upload process.

Type | Description
--- | ---
content.type.info | The `info` structure describes support for a specific type of data in an content.library.item_model. The `info` can be queried through the content.type service. Type support describes plugins in the Content Library which can provide metadata on library items and help manage the transfer process by adding dependent files when a current file is added.

####

# vapi metadata

The vapi.metadata API provides metadata services. These are services that provide different facets of API information. Clients can use these services to:

- Discover APIs available in the infrastructure.
- Fetch metadata that can be used to build presentation layers like CLI, REST, etc.
- Fetch authentication and authorization metadata.

Type | Description
--- | ---
vapi.metadata.source_create_spec | The `source_create_spec` structure contains the registration information for a metadata source.
vapi.metadata.source_info | Metadata source info

# vapi metadata authentication

The `vapi.metadata.authentication` API provides services that expose authentication information for operation elements across all the service elements.

To calculate the effective authentication information for an operation element, you should first see if there is an authentication scheme specified for the operation element. If it is not specified, then authentication scheme for the service element that contains this operation element is used. If it is not specified for the service element as well, then the authentication scheme for the package element that contains this service element is used.

Type | Description
--- | ---
vapi.metadata.authentication.authentication_info | The `authentication_info` structure describes the authentication information. Authentication information could be specified for a package element, service elenent or an operation element. Using the authentication scheme information, a client invoking an API call from any service can figure out what kind of credentials are needed for that API call.
vapi.metadata.authentication.component_data | The `component_data` structure contains the authentication information of the component along with its fingerprint.
vapi.metadata.authentication.component_info | The `component_info` structure contains authentication information of a component element. For an explanation of authentication information contained within component elements, see vapi.metadata.authentication.component.
vapi.metadata.authentication.operation_info | The `operation_info` structure contains authentication information of an operation element.
vapi.metadata.authentication.package_info | The `package_info` structure contains authentication information of a package element. For an explanation of authentication information contained within package elements, see vapi.metadata.authentication.package.
vapi.metadata.authentication.service_info | The `service_info` structure contains authentication information of a service element. For an explanation of authentication information contained within service elements, see vapi.metadata.authentication.service.

## source

The `source` service provides operations to manage the sources of authentication metadata information.

The interface definition language infrastructure provides tools to generate various kinds of metadata in JSON format from the interface definition files and additional properties files. One of the generated files contains authentication information. The generated file can be registered as a source of metadata.

The authentication file contains all the data present in the interface definition files. Each authentication file contains data about one component element. When a authentication file is added as a source, each source contributes only one component element's metadata.

Authentication metadata can also be discovered from a remote server that supports the authentication metadata services (see vapi.metadata.authentication). Since multiple components can be registered with a single metadata server, when a remote server is registered as a source, that source can contribute more than one component.

Type | Description
--- | ---
vapi.metadata.authentication.source.create_spec | The `create_spec` structure contains the registration information of a authentication source.
vapi.metadata.authentication.source.info | The `info` structure contains the metadata source information.

# vapi metadata cli

The `vapi.metadata.cli` API provides services that expose all the information required to display namespace or command help, execute a command and display it's result.

## command

The `command` service provides operations to get information about command line interface (CLI) commands.

Type | Description
--- | ---
vapi.metadata.cli.command.identity | The `identity` structure uniquely identifies a command in the CLI commands tree.
vapi.metadata.cli.command.info | The `info` structure contains information about a command. It includes the identity of the command, a description, information about the service and operation that implement the command, and CLI-specific information for the command.
vapi.metadata.cli.command.option_info | The `option_info` structure describes information about a specific input option of a command.
vapi.metadata.cli.command.output_field_info | The `output_field_info` structure describes the name used by the CLI to display a single field of a structure element in the interface definition language.
vapi.metadata.cli.command.output_info | The `output_info` structure describes the names used by the CLI to display the fields of a structure element in the interface definition language as well as the order in which the fields will be displayed.

## namespace

The `namespace` service provides operations to get information about command line interface (CLI) namespaces.

Type | Description
--- | ---
vapi.metadata.cli.namespace.identity | The `identity` structure uniquely identifies a namespace in the CLI namespace tree.
vapi.metadata.cli.namespace.info | The `info` structure contains information about a namespace. It includes the identity of the namespace, a description, information children namespaces.

## source

The `source` service provides operations to manage the sources of command line interface (CLI) metadata information.

The interface definition language infrastructure provides tools to generate various kinds of metadata in JSON format from the interface definition files and additional properties files. One of the generated files contains CLI information.

A CLI metadata file contains information about one component element. When a CLI metadata file is added as a source, each source contributes only one component element's metadata.

CLI metadata can also be discovered from a remote server that supports the CLI metadata services (see vapi.metadata.cli) API. Since multiple components can be registered with a single metadata server, when a remote server is registered as a source, that source can contribute more than one component.

Type | Description
--- | ---
vapi.metadata.cli.source.create_spec | The `create_spec` structure contains the registration information of a CLI source.
vapi.metadata.cli.source.info | The `info` structure contains the metadata source information.

# vapi metadata metamodel

The `vapi.metadata.metamodel` API provides services that expose all the information present in the interface definition language (IDL) specification.

Metamodel metadata is organized into an hierarchy of elements. The main elements are:

- Enumeration: An enumeration element that has a list of enumeration value elements.
- Constant: A constant element has a name and a value.
- Structure: A structure element can have field elements, constant elements and enumeration elements.
- Operation: An operation has a list of parameter elements, result element and error elements.
- Service: A service is a collection of operation elements, structure elements, enumerated elements and constant elements.
- Package: A package is a collection of service elements, structure elements and enumeration elements.
- Component: A component is a collection of package elements.

The `vapi.metadata.metamodel` API has services that enables two styles of client applications:

- A client can retrieve the exact pieces of information it requires using the various granularities the API supports (that is vapi.metadata.metamodel.component, vapi.metadata.metamodel.package, vapi.metadata.metamodel.service, vapi.metadata.metamodel.structure, vapi.metadata.metamodel.enumeration and vapi.metadata.metamodel.service.operation). In this case, it doesn't cache any information locally and always invokes operations to get the metamodel information it requires.
- A client can retrieve all the metamodel information in fewer operation invocations using the vapi.metadata.metamodel.component service and cache the output locally. It can then poll on the fingerprint information exposed by the vapi.metadata.metamodel.component service to monitor changes in API definition.

Type | Description
--- | ---
vapi.metadata.metamodel.component_data | The `component_data` structure contains the metamodel metadata information of a component element along with its fingerprint.
vapi.metadata.metamodel.component_info | The `component_info` structure contains metamodel metadata information about a component element.
vapi.metadata.metamodel.constant_info | The `constant_info` structure contains metamodel information of the constant elements.
vapi.metadata.metamodel.constant_value | The `constant_value` structure contains the metamodel information of the constant element.
vapi.metadata.metamodel.element_map | The `element_map` structure contains the metadata elements. One of the sources for metadata is the annotations present in the interface definition language. When an annotation is represented in the `element_map`, `element_map` describes the data specified in the arguments for the annotation. For example, in `@UnionCase(tag="tag", value="SELECT")`, ElementMap describes the keyword arguments tag and value.
vapi.metadata.metamodel.element_value | The `element_value` structure describes the value of the metadata element.
vapi.metadata.metamodel.enumeration_info | The `enumeration_info` structure contains the metamodel information of an enumeration element.
vapi.metadata.metamodel.enumeration_value_info | The `enumeration_value_info` structure describes the enumeration value in the enumerated type.
vapi.metadata.metamodel.error_info | The `error_info` structure contains the metadata information about the error elements contained in an operation element.
vapi.metadata.metamodel.field_info | The `field_info` structure contains metamodel information of a field element contained in a structure element.
vapi.metadata.metamodel.generic_instantiation | The `generic_instantiation` structure describes the type information of a typed element when the type is an instantiation of one of the generic types provided by the infrastructure.
vapi.metadata.metamodel.operation_info | The `operation_info` structure contains metamodel information of an operation element.
vapi.metadata.metamodel.operation_result_info | The `operation_result_info` structure contains the metamodel information of an operation result element. An operation accepts a list of parameters and returns a result or an error. The `operation_result_info` describes the result element of an operation.
vapi.metadata.metamodel.package_info | The `package_info` structure contains the metamodel information of all the service elements, structure elements and enumeration elements contained in the package element.
vapi.metadata.metamodel.primitive_value | The `primitive_value` structure contains value of the constant element.
vapi.metadata.metamodel.service_info | The `service_info` structure contains the metamodel information of all the operation elements, structure elements and enumeration elements containted in a service element.
vapi.metadata.metamodel.structure_info | The `structure_info` structure contains the metamodel information of all the field elements, constant elements and enumeration elements contained in the structure element. In the interface definition language, API designers have the ability to include all the fields from one structure to another structure. This is done by using an annotation `@Include` on the structure in which we want to add the fields. If this annotation is present, the list of fields in the `structure_info` will also contain the fields that are being included. The annotation information is also retained in the vapi.metadata.metamodel.structure_info.metadata element as well.
vapi.metadata.metamodel.type | The `type` structure describes the type information of a typed element in the interface definiton language. The following elements in the metamodel are typed: Field element in a structure element. See vapi.metadata.metamodel.structure_info.fields Parameter element in an operation element. See vapi.metadata.metamodel.operation_info.params Result element in an operation element. See vapi.metadata.metamodel.operation_info.output The type could be one of the three following categories: Built-in types: These are types present in the interface definition language type system. They are provided by the infrastructure. User defined named type: API designers can create custom types and use them for the typed elements. These types have a unique identifier. Generic type instantiation: The language infrastructure also provides generic types such as list, map, set and so on. An instantiation of one of these generic types could also be used for the typed elements.
vapi.metadata.metamodel.user_defined_type | The `user_defined_type` structure contains the metamodel type information of a typed element whose type is a user defined named type.

## source

The `source` service provides operations to manage the sources of metamodel metadata information.

The interface definition language infrastructure provides tools to generate various kinds of metadata in JSON format from the interface definition files and additional properties files. One of the generated files contains metamodel information. The generated file can be registered as a source of metadata.

The metamodel file contains all the data present in the interface definition files. Each metamodel file contains data about one component element. When a metamodel file is added as a source, each source contributes only one component element's metadata.

Metamodel metadata can also be discovered from a remote server that supports the metamodel metadata services (see vapi.metadata.metamodel). Since multiple components can be registered with a single metadata server, when a remote server is registered as a source, that source can contribute more than one component.

Type | Description
--- | ---
vapi.metadata.metamodel.source.create_spec | The `create_spec` structure contains the registration information of a metamodel source.
vapi.metadata.metamodel.source.info | The `info` structure contains the metadata source information.

# vapi metadata privilege

The `vapi.metadata.privilege` API provides services that expose privilege information for operation elements across all the service elements.

An entity has a unique identifier and a resource type. An entity can either be present in one of the parameter elements or if a parameter is a structure element, it could also be present in one of the field elements.

Privileges can be assigned to either operation elements or entities used in the operation element. A list of privileges can also be applied on a package element. This list of privileges would be used as a default for all the operation elements and the entities that do not have any defined privileges.

Type | Description
--- | ---
vapi.metadata.privilege.component_data | The `component_data` structure contains the privilege information of the component along with its fingerprint.
vapi.metadata.privilege.component_info | The `component_info` structure contains the privilege information of a component element. For an explanation of privilege information contained within component elements, see vapi.metadata.privilege.component.
vapi.metadata.privilege.operation_info | The `operation_info` structure contains privilege information of an operation element. For an explanation of containment within operation elements, see vapi.metadata.privilege.service.operation.
vapi.metadata.privilege.package_info | The `package_info` structure contains the privilege information of a package element. For an explanation of privilege information contained within package elements, see vapi.metadata.privilege.package.
vapi.metadata.privilege.privilege_info | The `privilege_info` structure contains the privilege information for a parameter element in an operation element.
vapi.metadata.privilege.service_info | The `service_info` structure contains privilege information of a service element. For an explanation of privilege information contained within service elements, see vapi.metadata.privilege.service.

## source

The `source` service provides operations to manage the sources of privilege metadata information.

The interface definition language infrastructure provides tools to generate various kinds of metadata in JSON format from the interface definition files and additional properties files. One of the generated files contains privilege information. The generated file can be registered as a source of metadata.

The privilege file contains all the data present in the interface definition files. Each privilege file contains data about one component element. When a privilege file is added as a source, each source contributes only one component element's metadata.

Privilege metadata can also be discovered from a remote server that supports the privilege metadata services (see vapi.metadata.privilege). Since multiple components can be registered with a single metadata server, when a remote server is registered as a source, that source can contribute more than one component.

Type | Description
--- | ---
vapi.metadata.privilege.source.create_spec | The `create_spec` structure contains the registration information of a privilege source.
vapi.metadata.privilege.source.info | The `info` structure contains the metadata source information.

# vapi std

The `vapi.std` API provides standard types that can be used in the interface specification of any service.

Type | Description
--- | ---
vapi.std.authentication_scheme | The vapi.std.authentication_scheme class defines constants for authentication scheme identifiers for authentication mechanisms present in the vAPI infrastructure shipped by VMware. A third party extension can define and implements it's own authentication mechanism and define a constant in a different IDL file.
vapi.std.dynamic_ID | The `dynamic_ID` structure represents an identifier for a resource of an arbitrary type.
vapi.std.localizable_message | The `localizable_message` structure represents a localizable string or message template. Services include one or more localizable message templates in the errors they report so that clients can display diagnostic messages in the native language of the user. Services can include localizable strings in the data returned from operations to allow clients to display localized status information in the native language of the user.

# vapi std errors

The `vapi.std.errors` API provides the standard errors that can be included in the list of errors in the specification of operations to indicate that the operation might report those errors. It also provides some structures intended to be used as payload to provide additional information about those errors.

Type | Description
--- | ---
vapi.std.errors.already_exists | The `already_exists` error indicates that an attempt was made to create an entity but the entity already exists. Typically the entity has a name or identifier that is required to be unique in some context, but there is already an entity with that name or identifier in that context. Examples: Trying to create a new tag category when a tag category with the specified name already exists. Trying to create a new tag in tag category when a tag with the specified name already exists the tag category. Trying to create a LUN with a specific UUID on a node (for replication purposes) when a LUN with that UUID already exists on the node. Trying to create a file in a directory or move or copy a file to a directory when a file with that name already exists in the directory.
vapi.std.errors.already_in_desired_state | The `already_in_desired_state` error indicates that an attempt to change the state of a resource or service had no effect because the resource or service is already in the desired state. Examples: Trying to power on a virtual machine that is already powered on.
vapi.std.errors.argument_locations | The `argument_locations` structure describes which part(s) of the input to the operation caused the error. Some types of errors are caused by the value of one of the inputs to the operation, possibly due to an interaction with other inputs to the operation. This structure is intended to be used as the payload to identify those inputs when the operation reports errors like vapi.std.errors.invalid_argument or vapi.std.errors.not_found. See vapi.std.errors.error.data.
vapi.std.errors.canceled | The `canceled` error indicates that the operation canceled itself in response to an explicit request to do so. Operations being "canceled" for other reasons (for example the client connection was closed, a time out occured, or due to excessive resource consumption) should not report this error. Examples: A user is monitoring the progress of the operation in a GUI and sees that it is likely to take longer than he is willing to wait and clicks the cancel button. A user invokes the operation using a command-line tool and decides that she didn't really want to invoke that operation, and presses CTRL-c. Counterexamples: The client's connection to the server was closed. Reporting an error is pointless since the client will not receive the error response because the connection has been closed. The request is taking longer than some amount of time. The vapi.std.errors.timed_out error would be reported if the time was specified as part of the input or is documented in the API contract.
vapi.std.errors.concurrent_change | The `concurrent_change` error indicates that a data structure, entity, or resource has been modified since some earlier point in time. Typically this happens when the client is doing the write portion of a read-modify-write sequence and indicates that it wants the server to notify it if the data in the server has changed after it did the read, so that it can avoid overwriting that change inadvertantly.
vapi.std.errors.error | The `error` error describes thefields common to all standard errors. This error serves two purposes: It is the error that clients in many programming languages can catch to handle all standard errors. Typically those clients will display one or more of the localizable messages from vapi.std.errors.error.messages to a human. It is the error that operations can report when they need to report some error, but the error doesn't fit into any other standard error, and in fact the only reasonable way for a client to react to the error is to display the message(s) to a human.
vapi.std.errors.feature_in_use | The `feature_in_use` error indicates that an action cannot be completed because a feature is in use. Examples: Trying to disable snapshots on a virtual machine which has a snapshot. Trying to downgrade a license that has licensed features that are in use.
vapi.std.errors.file_locations | The `file_locations` structure identifies the file(s) that caused the operation to report the error. Some types of errors are caused by a problem with one or more files. This structure is intended to be used as the payload to identify those files when the operation reports errors like vapi.std.errors.not_found. See vapi.std.errors.error.data.
vapi.std.errors.internal_server_error | The `internal_server_error` error indicates that the server encounters an unexpected condition that prevented it from fulfilling the request. This error is reported by the API infrastructure, so it could occur in response to the invocation of any operation. Examples: The operation returns a value whose type doesn't match the type type the operation says it should return. The operation reports an error that is not included in the list of errors the operation says that it can report.
vapi.std.errors.invalid_argument | The `invalid_argument` error indicates that the values received for one or more parameters are not acceptable. This error is reported by the API infrastructure, so it could occur in response to the invocation of any operation. It may also be reported as the result of operation-specific validation. Examples: A parameter has a value that is not of the expected type. A parameter has a value that is not in the required range. A parameter has a value that is not one of the specifically allowed strings. One field of a structure is the tag for a tagged union, and has a specific value but another field of the structure that is required to be specified when the tag has that value is not specified, or another field of the structure that is required to be unspecified when the tag has that value is specified. Counterexamples: Trying to create a new tag in tag category when a tag with the specified name already exists the tag category. The vapi.std.errors.already_exists error would be used instead. Invoke the operation to retrieve information about a virtual machine, passing an id that does not identify an existing virtual machine. The vapi.std.errors.not_found error would be used instead. Attempt to put a virtual machine into a folder that can only contain hosts. The vapi.std.errors.invalid_element_type error would be used instead. Attempt to attach a SCSI virtual disk to an IDE port. The vapi.std.errors.invalid_element_type error would be used instead.
vapi.std.errors.invalid_element_configuration | The `invalid_element_configuration` error indicates that an attempt to modify the configuration of an element or a group containing the element failed due to the configuraton of the element. A typical case is when the operation is am attempt to change the group membership of the element fails, in which case a configuration change on the element may allow the group membership change to succeed. Examples: Attempt to move a host with a fault tolerant virtual machine out of a cluster (i.e. make the host a standalone host). Attempt to remove a host from a DRS cluster without putting the host into maintenance mode.
vapi.std.errors.invalid_element_type | The `invalid_element_type` error indicates that the server was unable to fulfil the request because an element of a specific type cannot be a member of particular group. This error could be reported, for example, if an attempt is made to put an element into the wrong type of container. Examples: Attempt to put a virtual machine into a folder that can only contain hosts. Attempt to attach a SCSI virtual disk to an IDE port. Counterexamples: A parameter has a value that is not of the expected type. The vapi.std.errors.invalid_argument error would be used instead.
vapi.std.errors.invalid_request | The `invalid_request` error indicates that the request is malformed in such a way that the server is unable to process it. Examples: The XML in a SOAP request is not well-formed so the server cannot parse the request. The XML in a SOAP request is well-formed but does not match the structure required by the SOAP specification. A JSON-RPC request is not valid JSON. The JSON sent in a JSON-RPC request is not a valid JSON-RPC Request object. The Request object from a JSON-RPC request does not match the structure required by the API infrastructure. Counterexamples: The parameter has a value that is not with the required range. The vapi.std.errors.invalid_argument error would be used instead. The name of the operation specified in the request doesn't not match any known operation. The vapi.std.errors.not_found error would be used instead. Some transport protocols (for example JSON-RPC) include their own mechanism for reporting these kinds of errors, and the API infrastructure for a programming language may expose the errors using a language specific mechanism, so this error might not be used.
vapi.std.errors.not_allowed_in_current_state | The `not_allowed_in_current_state` error indicates that the requested operation is not allowed with a resource or service in its current state. This could be because the operation is performing a configuration change that is not allowed in the current state or because operation itself is not allowed in the current state. Examples: Trying to add a virtual device that cannot be hot plugged to a running virtual machine. Trying to upgrade the virtual hardware version for a suspended virtual machine. Trying to power off, reset, or suspend a virtual machine that is not powered on. Counterexamples: Trying to power off a virtual machine that is in the process of being powered on. The vapi.std.errors.resource_busy error would be used instead.
vapi.std.errors.not_found | The `not_found` error indicates that a specified element could not be found. Examples: Invoke the operation to retrieve information about a virtual machine, passing an id that does not identify an existing virtual machine. Invoke the operation to modify the configuration of a virtual nic, passing an id that does not identify an existing virtual nic in the specified virtual machine. Invoke the operation to remove a vswitch, passing an id that does not identify an existing vswitch.
vapi.std.errors.operation_not_found | The `operation_not_found` error indicates that the operation specified in the request could not be found. Every API request specifies a service identifier and an operation identifier along with the parameters. If the API infrastructure is unable to find the requested service or operation it reports this error. This error can be reported by the API infrastructure for any operation, but it is specific to the API infrastructure, and should never be reported by the implementation of any operation. Examples: A client provides an invalid service or operation identifier when invoking the operation using a dynamic interface (for example REST). A client invokes the operation from a service, but that service has not been installed. Counterexamples: A client invokes a task scheduling operation, but provides an invalid service identifier or operation identifier. The vapi.std.errors.not_found error would be used instead.
vapi.std.errors.resource_busy | The `resource_busy` error indicates that the operation could not be completed because a resource it needs is busy. Examples: Trying to power off a virtual machine that is in the process of being powered on. Counterexamples: Trying to remove a VMFS datastore when there is a virtual machine registered on any host attached to the datastore. The vapi.std.errors.resource_in_use error would be used instead.
vapi.std.errors.resource_in_use | The `resource_in_use` error indicates that the operation could not be completed because a resource is in use. Examples: Trying to remove a VMFS datastore when the is a virtual machine registered on any host attached to the datastore. Trying to add a virtual switch if the physical network adapter being bridged is already in use. Counterexamples: Trying to power off a virtual machine that is in the process of being powered on. The vapi.std.errors.resource_busy error would be used instead.
vapi.std.errors.resource_inaccessible | The `resource_inaccessible` error indicates that the operation could not be completed because an entity is not accessible. Examples: Attempt to invoke some operation on a virtual machine when the virtual machine's configuration file is not accessible (for example due to a storage APD condition). Counterexamples: Attempt to invoke some operation when the server is too busy. The vapi.std.errors.service_unavailable error would be used instead. Attempt to invoke some operation when the server is undergoing maintenance. The vapi.std.errors.service_unavailable error would be used instead. Some operation fails to contact VMware Tools running inside the virtual machine. The vapi.std.errors.service_unavailable error would be used instead.
vapi.std.errors.service_unavailable | The `service_unavailable` error indicates that the service is unavailable. Examples: Attempt to invoke a operation when the server is too busy. Attempt to invoke a operation when the server is undergoing maintenance. An operation fails to contact VMware Tools running inside the virtual machine. Counterexamples: A client provides an invalid service or operation identifier when invoking the operation using a dynamic interface (for example REST). The vapi.std.errors.operation_not_found error would be used instead. A client invokes the operation from the service, but that service has not been installed. The vapi.std.errors.operation_not_found error would be used instead.
vapi.std.errors.timed_out | The `timed_out` error indicates that the operation did not complete within the allowed amount of time. The allowed amount of time might be: provided by the client as an input parameter. a fixed limit of the service implementation that is a documented part of the contract of the service. a configurable limit used by the implementation of the service. a dynamic limit computed by the implementation of the service. The operation may or may not complete after the `timed_out` error was reported. Examples: The operation was unable to complete within the timeout duration specified by a parameter of the operation. Counterexamples: A server implementation that puts requests into a queue before dispatching them might delete a request from the queue if it doesn't get dispatched within n minutes. The vapi.std.errors.service_unavailable error would be used instead.
vapi.std.errors.transient_indication | The `transient_indication` structure indicates whether or not the error is transient. Some types of errors are transient in certain situtations and not transient in other situtations. This error payload can be used to indicate to clients whether a particular error is transient. See vapi.std.errors.error.data.
vapi.std.errors.unable_to_allocate_resource | The `unable_to_allocate_resource` error indicates that the operation failed because it was unable to allocate or acquire a required resource. Examples: Trying to power on a virtual machine when there are not enough licenses to do so. Trying to power on a virtual machine that would violate a resource usage policy. Counterexamples: Trying to power off a virtual machine that is in the process of being powered on. A vapi.std.errors.resource_busy error would be used instead. Trying to remove a VMFS datastore when the is a virtual machine registered on any host attached to the datastore. The vapi.std.errors.resource_in_use error would be used instead. Trying to add a virtual switch if the physical network adapter being bridged is already in use. The vapi.std.errors.resource_in_use error would be used instead. Attempt to invoke some operation on a virtual machine when the virtual machine's configuration file is not accessible (for example due to a storage APD condition). The vapi.std.errors.resource_inaccessible error would be used instead.
vapi.std.errors.unauthenticated | The `unauthenticated` error indicates that the operation requires authentication and the user is not authenticated. API requests may include a security context containing user credentials. For example, the user credentials could be a SAML token, a user name and password, or the session identifier for a previously established session. Examples: The SAML token in the request's security context has expired. The user name and password in the request's security context are invalid. The session identifier in the request's security context identifies a session that has expired. Counterexamples: The user is authenticated but isn't authorized to perform the requested operation. The vapi.std.errors.unauthorized error would be used instead. For security reasons, the vapi.std.errors.error.data field in this error is unset, and the vapi.std.errors.error.messages field in this error does not disclose which part of the security context is correct or incorrect. For example the messages would not disclose whether a username or a password is valid or invalid, but only that a combination of username and password is invalid.
vapi.std.errors.unauthorized | The `unauthorized` error indicates that the user is not authorized to perform the operation. API requests may include a security context containing user credentials. For example, the user credentials could be a SAML token, a user name and password, or the session identifier for a previously established session. Invoking the operation may require that the user identified by those credentials has particular privileges on the operation or on one or more resource identifiers passed to the operation. Examples: The operation requires that the user have one or more privileges on the operation, but the user identified by the credentials in the security context does not have the required privileges. The operation requires that the user have one or more privileges on a resource identifier passed to the operation, but the user identified by the credentials in the security context does not have the required privileges. Counterexamples: The SAML token in the request's security context has expired. A vapi.std.errors.unauthenticated error would be used instead. The user name and password in the request's security context are invalid. The vapi.std.errors.unauthenticated error would be used instead. The session identifier in the request's security context identifies a session that has expired. The vapi.std.errors.unauthenticated error would be used instead. For security reasons, the vapi.std.errors.error.data field in this error is unset, and the vapi.std.errors.error.messages field in this error does not disclose why the user is not authorized to perform the operation. For example the messages would not disclose which privilege the user did not have or which resource identifier the user did not have the required privilege to access. The API documentation should indicate what privileges are required.
vapi.std.errors.unexpected_input | The `unexpected_input` error indicates that the request contained a parameter or field whose name is not known by the server. Every operation expects parameters with known names. Some of those parameters may be (or contain) structures, and the operation expects those structures to contain fields with known names. If the operation receives parameters or fields with names that is does not expect, this error may be reported. This error can be reported by the API infrastructure for any operation, but it is specific to the API infrastructure, and should never be reported by the implementation of any operation. Examples: A client using stubs generated from the interface specification for version2 of a service invokes the operation passing one or more parameters that were added in version2, but they are communicating with a server that only supports version1 of the service. A client provides an unexpected parameter or field name when invoking the operation using a dynamic interface (for example REST).
vapi.std.errors.unsupported | The `unsupported` error indicates that the operation is not supported by the service. Examples: Trying to hot-plug a CPU when the current configuration of the VM does not support hot-plugging of CPUs. Trying to change the memory size to a value that is not within the acceptable guest memory bounds supported by the virtual machine's host.

# vcenter

The `vcenter` API provides services for managing VMware vSphere environments. The API is available starting in vSphere 6.5.

## cluster

The `cluster` service provides operations to manage clusters in the vCenter Server.

Type | Description
--- | ---
vcenter.cluster.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing clusters (see list). If multiple fields are specified, only clusters matching all of the fields match the filter.
vcenter.cluster.info | The `info` structure contains information about a cluster in vCenter Server.
vcenter.cluster.summary | The `summary` structure contains commonly used information about a cluster in vCenter Server.

## datacenter

The `datacenter` service provides operations to manage datacenters in the vCenter Server.

Type | Description
--- | ---
vcenter.datacenter.create_spec | The `create_spec` structure defines the information used to create a datacenter.
vcenter.datacenter.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing datacenters (see list). If multiple fields are specified, only datacenters matching all of the fields match the filter.
vcenter.datacenter.info | The `info` structure contains information about a datacenter in vCenter Server.
vcenter.datacenter.summary | The `summary` structure contains commonly used information about a datacenter in vCenter Server.

## datastore

The Datastore service provides operations for manipulating a datastore.

Type | Description
--- | ---
vcenter.datastore.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing datastores (see list). If multiple fields are specified, only datastores matching all of the fields match the filter.
vcenter.datastore.info | The `info` structure contains information about a datastore.
vcenter.datastore.summary | The `summary` structure contains commonly used information about a datastore.

## folder

The Folder service provides operations for manipulating a vCenter Server folder.

Type | Description
--- | ---
vcenter.folder.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing folders (see list). If multiple fields are specified, only folders matching all of the fields match the filter.
vcenter.folder.summary | The `summary` structure contains commonly used information about a folder.

## host

The `host` service provides operations to manage hosts in the vCenter Server.

Type | Description
--- | ---
vcenter.host.create_spec | The `create_spec` structure defines the information used to create a host.
vcenter.host.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing hosts (see list). If multiple fields are specified, only hosts matching all of the fields match the filter.
vcenter.host.summary | The `summary` structure contains commonly used information about a host in vCenter Server.

# vcenter inventory

The `vcenter.inventory` component provides operations and structures for retrieving vCenter datastore and network information for a given array of identifiers.

## datastore

The `datastore` service provides operations to retrieve information about datastores.

Type | Description
--- | ---
vcenter.inventory.datastore.info | The `info` structure contains information about a datastore.

## network

The `network` service provides operations to retrieve information about vCenter Server networks.

Type | Description
--- | ---
vcenter.inventory.network.info | The `info` structure contains information about a vCenter Server network.

## network

The Network service provides operations for manipulating a vCenter Server network.

Type | Description
--- | ---
vcenter.network.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing networks (see list). If multiple fields are specified, only networks matching all of the fields match the filter.
vcenter.network.summary | The `summary` structure contains commonly used information about a network.

# vcenter ovf

The `vcenter.ovf` API provides services to capture and deploy Open Virtualization Format (OVF) packages to and from the content library.

It provides the ability to deploy OVF packages from the content library with support for advanced network topologies, network services, creating virtual appliances and virtual machines in hosts, resource pools or clusters. It also provides the ability to export virtual appliances and virtual machines from hosts, resource pools or clusters as OVF packages to the content library.

Type | Description
--- | ---
vcenter.ovf.certificate_params | The `certificate_params` structure contains information about the public key certificate used to sign the OVF package. This structure will only be returned if the OVF package is signed. See deploy and filter.
vcenter.ovf.deployment_option | The `deployment_option` structure contains the information about a deployment option as defined in the OVF specification. This corresponds to the ovf:Configuration element of the ovf:DeploymentOptionSection in the specification. The ovf:DeploymentOptionSection specifies a discrete set of intended resource allocation configurations. This structure represents one item from that set. See deploy and filter.
vcenter.ovf.deployment_option_params | The `deployment_option_params` structure describes the possible deployment options as well as the choice provided by the user. This information based on the ovf:DeploymentOptionSection. See deploy and filter.
vcenter.ovf.extra_config | The `extra_config` structure contains the information about a vmw:ExtraConfig element which can be used to specify configuration settings that are transferred directly to the `.vmx` file. The behavior of the vmw:ExtraConfig element is similar to the `extraConfig` property of the `VirtualMachineConfigSpec` object in the VMware vSphere API. Thus, the same restrictions apply, such as you cannot set values that could otherwise be set with other properties in the `VirtualMachineConfigSpec` object. See the VMware vSphere API reference for details on this. vmw:ExtraConfig elements may occur as direct child elements of a VirtualHardwareSection, or as child elements of individual virtual hardware items. See deploy and filter.
vcenter.ovf.extra_config_params | The `extra_config_params` structure contains the parameters with information about the vmw:ExtraConfig elements in an OVF package. vmw:ExtraConfig elements can be used to specify configuration settings that are transferred directly to the `.vmx` file. The behavior of the vmw:ExtraConfig element is similar to the `extraConfig` property of the `VirtualMachineConfigSpec` object in the VMware vSphere API. Thus, the same restrictions apply, such as you cannot set values that could otherwise be set with other properties in the `VirtualMachineConfigSpec` object. See the VMware vSphere API reference for details on this. See deploy and filter.
vcenter.ovf.ip_allocation_params | The `ip_allocation_params` structure specifies how IP addresses are allocated to OVF properties. In particular, it informs the deployment platform whether the guest supports IPv4, IPv6, or both. It also specifies whether the IP addresses can be obtained through DHCP or through the properties provided in the OVF environment. Ovf Property elements are exposed to the guest software through the OVF environment. Each Property element exposed in the OVF environment shall be constructed from the value of the ovf:key attribute. A Property element contains a key/value pair, it may optionally specify type qualifiers using the ovf:qualifiers attribute with multiple qualifiers separated by commas. The settings in `ip_allocation_params` structure are global to a deployment. Thus, if a virtual machine is part of a virtual appliance, then its settings are ignored and the settings for the virtual appliance is used. This information is based on the vmw:IpAssignmentSection in OVF package. See deploy and filter.
vcenter.ovf.ovf_error | The `ovf_error` structure describes an error related to accessing, validating, deploying, or exporting an OVF package.
vcenter.ovf.ovf_info | The `ovf_info` structure contains informational messages related to accessing, validating, deploying, or exporting an OVF package.
vcenter.ovf.ovf_message | The `ovf_message` structure describes a base OVF handling error message related to accessing, validating, deploying, or exporting an OVF package. These messages fall into different categories defined in vcenter.ovf.ovf_message.category:
vcenter.ovf.ovf_params | The `ovf_params` structure defines the common fields for all OVF deployment parameters. OVF parameters serve several purposes: Describe information about a given OVF package. Describe default deployment configuration. Describe possible deployment values based on the deployment environment. Provide deployment-specific configuration. Each OVF parameters structure specifies a particular configurable aspect of OVF deployment. An aspect has both a query-model and a deploy-model. The query-model is used when the OVF package is queried, and the deploy-model is used when deploying an OVF package. Most OVF parameter structures provide both informational and deployment parameters. However, some are purely informational (for example, download size) and some are purely deployment parameters (for example, the flag to indicate whether registration as a vCenter extension is accepted). See deploy and filter.
vcenter.ovf.ovf_warning | The `ovf_warning` structure describes a warning related to accessing, validating, deploying, or exporting an OVF package.
vcenter.ovf.parse_issue | The `parse_issue` structure contains the information about the issue found when parsing an OVF package during deployment or exporting an OVF package including: Parsing and validation error on OVF descriptor (which is an XML document), manifest and certificate files. OVF descriptor generating and device error. Unexpected server error.
vcenter.ovf.property | The `property` structure contains the information about a property in an OVF package. A property is uniquely identified by its [classid.]id[.instanceid] fully-qualified name (see vcenter.ovf.property.class_id, vcenter.ovf.property.id, and vcenter.ovf.property.instance_id). If multiple properties in an OVF package have the same fully-qualified name, then the property is excluded and cannot be set. We do warn about this during import. See deploy and filter.
vcenter.ovf.property_params | The `property_params` structure contains a array of OVF properties that can be configured when the OVF package is deployed. This is based on the ovf:ProductSection. See deploy and filter.
vcenter.ovf.scale_out_group | The `scale_out_group` structure contains information about a scale-out group. It allows a virtual system collection to contain a set of children that are homogeneous with respect to a prototypical virtual system or virtual system collection. It shall cause the deployment function to replicate the prototype a number of times, thus allowing the number of instantiated virtual systems to be configured dynamically at deployment time. This is based on the ovf2:ScaleOutSection. See deploy and filter.
vcenter.ovf.scale_out_params | The `scale_out_params` structure contains information about the scale-out groups described in the OVF package. When deploying an OVF package, a deployment specific instance count can be specified (see vcenter.ovf.scale_out_group.instance_count. This is based on the ovf2:ScaleOutSection. See deploy and filter.
vcenter.ovf.size_params | The `size_params` structure contains estimates of the download and deployment sizes. This information is based on the file references and the ovf:DiskSection in the OVF descriptor. See deploy and filter.
vcenter.ovf.unknown_section | The `unknown_section` structure contains information about an unknown section in an OVF package.
vcenter.ovf.unknown_section_params | The `unknown_section_params` structure contains a array of unknown, non-required sections. See deploy and filter.
vcenter.ovf.vcenter_extension_params | The `vcenter_extension_params` structure specifies that the OVF package should be registered as a vCenter extension. The virtual machine or virtual appliance will gain unrestricted access to the vCenter Server APIs. It must be connected to a network with connectivity to the vCenter server. See deploy and filter.

## export flag

The `export_flag` service provides operations for retrieving information about the export flags supported by the server. Export flags can be specified in a vcenter.ovf.library_item.create_spec to customize an OVF export.

Type | Description
--- | ---
vcenter.ovf.export_flag.info | The `info` structure describes an export flag supported by the server.

## import flag

The `import_flag` service provides operations for retrieving information about the import flags supported by the deployment platform. Import flags can be specified in a vcenter.ovf.library_item.resource_pool_deployment_spec to customize an OVF deployment.

Type | Description
--- | ---
vcenter.ovf.import_flag.info | The `info` structure describes an import flag supported by the deployment platform.

## library item

The `library_item` service provides operations to deploy virtual machines and virtual appliances from library items containing Open Virtualization Format (OVF) packages in content library, as well as operations to create library items in content library from virtual machines and virtual appliances.

To deploy a virtual machine or a virtual appliance from a library item:

1. Create a vcenter.ovf.library_item.deployment_target to specify the target deployment type and target deployment designation.
2. Create a vcenter.ovf.library_item.resource_pool_deployment_spec to specify the parameters for the target deployment.
3. Use the `deploy` operation with the created target and parameter specifications, along with the identifier of the specified source content library item. See deploy.

To create a library item in content library from a virtual machine or virtual appliance:

1. Create a vcenter.ovf.library_item.deployable_identity to specify the source virtual machine or virtual appliance to be used as the OVF template source.
2. Create a vcenter.ovf.library_item.create_target to specify the target library and library item.
3. Create a vcenter.ovf.library_item.create_spec to specify the settings for the OVF package to be created.
4. Use the `create` operation with the created target and parameter specifications, along with the specified source entity. See create.

Type | Description
--- | ---
vcenter.ovf.library_item.create_result | The `create_result` structure defines the result of the `create` operation. See create.
vcenter.ovf.library_item.create_spec | The `create_spec` structure defines the information used to create or update a library item containing an OVF package.
vcenter.ovf.library_item.create_target | The `create_target` structure specifies the target library item when capturing a virtual machine or virtual appliance as an OVF package in a library item in a content library. The target can be an existing library item, which will be updated, creating a new version, or it can be a newly created library item in a specified library. See create.
vcenter.ovf.library_item.deployable_identity | The `deployable_identity` structure describes the resource created by a deployment, or the source resource from which library item can be created, by specifying its resource type and resource identifier.
vcenter.ovf.library_item.deployment_result | The `deployment_result` structure defines the result of the `deploy` operation. See deploy.
vcenter.ovf.library_item.deployment_target | The `deployment_target` structure describes the location (target) where a virtual machine or virtual appliance should be deployed. It is used in the `deploy` and `filter` operations. See deploy and filter.
vcenter.ovf.library_item.ovf_summary | The `ovf_summary` structure defines the result of the `filter` operation. See filter. The fields in the structure describe parameterizable information in the OVF descriptor, with respect to a deployment target, for the `deploy` operation. See deploy.
vcenter.ovf.library_item.resource_pool_deployment_spec | The `resource_pool_deployment_spec` structure defines the deployment parameters that can be specified for the `deploy` operation where the deployment target is a resource pool. See deploy.
vcenter.ovf.library_item.result_info | The `result_info` structure defines the information returned along with the result of a `create` or `deploy` operation to describe errors, warnings, and informational messages produced by the server.
vcenter.ovf.library_item.storage_group_mapping | The `storage_group_mapping` structure defines the storage deployment target and storage provisioning type for a section of type vmw:StorageGroupSection in the OVF descriptor.

## resource pool

The ResourcePool service provides operations for manipulating a vCenter Server resource pool.

This service does not include virtual appliances in the inventory of resource pools even though part of the behavior of a virtual appliance is to act like a resource pool.

Type | Description
--- | ---
vcenter.resource_pool.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing resource pools (see list). If multiple fields are specified, only resource pools matching all of the fields match the filter.
vcenter.resource_pool.info | The `info` structure contains information about a resource pool.
vcenter.resource_pool.summary | The `summary` structure contains commonly used information about a resource pool in vCenter Server.

# vcenter vm

The `vcenter.vm` API provides services for managing virtual machines.

## VM

The `VM` service provides operations for managing the lifecycle of a virtual machine.

Type | Description
--- | ---
vcenter.VM.create_spec | Document-based creation spec.
vcenter.VM.filter_spec | The `filter_spec` structure contains fields used to filter the results when listing virtual machines (see list). If multiple fields are specified, only virtual machines matching all of the fields match the filter.
vcenter.VM.info | Document-based info.
vcenter.VM.placement_spec | The `placement_spec` structure contains information used to place a virtual machine onto resources within the vCenter inventory.
vcenter.VM.summary | The `summary` structure contains commonly used information about a virtual machine.

# vcenter vm hardware

The `vcenter.vm.hardware` API provides services for managing the virtual hardware configuration and state of a virtual machine. This includes operations for reading and manipulating virtual device configuration and for querying the runtime state of the devices.

Type | Description
--- | ---
vcenter.vm.hardware.connection_create_spec | The `connection_create_spec` structure provides a specification for the configuration of a newly-created removable device.
vcenter.vm.hardware.connection_info | The `connection_info` structure provides information about the state and configuration of a removable virtual device.
vcenter.vm.hardware.connection_update_spec | The `connection_update_spec` structure describes the updates to be made to the configuration of a removable virtual device.
vcenter.vm.hardware.ide_address_info | The `ide_address_info` structure contains information about the address of a virtual device that is attached to a virtual IDE adapter of a virtual machine.
vcenter.vm.hardware.ide_address_spec | The `ide_address_spec` structure contains information for specifying the address of a virtual device that is attached to a virtual IDE adapter of a virtual machine.
vcenter.vm.hardware.info | The `info` structure contains information related to the virtual hardware of a virtual machine.
vcenter.vm.hardware.sata_address_info | The `sata_address_info` structure contains information about the address of a virtual device that is attached to a virtual SATA adapter of a virtual machine.
vcenter.vm.hardware.sata_address_spec | The `sata_address_spec` structure contains information for specifying the address of a virtual device that is attached to a virtual SATA adapter of a virtual machine.
vcenter.vm.hardware.scsi_address_info | The `scsi_address_info` structure contains information about the address of a virtual device that is attached to a virtual SCSI adapter of a virtual machine.
vcenter.vm.hardware.scsi_address_spec | The `scsi_address_spec` structure contains information for specifying the address of a virtual device that is attached to a virtual SCSI adapter of a virtual machine.
vcenter.vm.hardware.update_spec | The `update_spec` structure describes the updates to virtual hardware settings of a virtual machine.

# vcenter vm hardware adapter

The `vcenter.vm.hardware.adapter` API provides services for managing the configuration and state of the virtual adapters belonging to a virtual machine. This includes operations for reading and manipulating the conifguration of USB adapters and host bus adapters.

Note that services for adapters with no configurable properties or runtime state, such as IDE and PCI adapters, are omitted.

## sata

The `sata` service provides operations for configuring the virtual SATA adapters of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.adapter.sata.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual SATA adapter.
vcenter.vm.hardware.adapter.sata.info | The `info` structure contains information about a virtual SATA adapter.
vcenter.vm.hardware.adapter.sata.summary | The `summary` structure contains commonly used information about a Virtual SATA adapter.

## scsi

The `scsi` service provides operations for configuring the virtual SCSI adapters of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.adapter.scsi.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual SCSI adapter.
vcenter.vm.hardware.adapter.scsi.info | The `info` structure contains information about a virtual SCSI adapter.
vcenter.vm.hardware.adapter.scsi.summary | The `summary` structure contains commonly used information about a Virtual SCSI adapter.
vcenter.vm.hardware.adapter.scsi.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual SCSI adapter.

# vcenter vm hardware boot

The `vcenter.vm.hardware.boot` API provides services for managing the virtual devices used to boot a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.boot.create_spec | The `create_spec` structure describes settings used when booting a virtual machine.
vcenter.vm.hardware.boot.info | The `info` structure contains information about the virtual machine boot process.
vcenter.vm.hardware.boot.update_spec | The `update_spec` structure describes the updates to the settings used when booting a virtual machine.

## device

The `device` service provides operations for configuring the device order used when booting a virtual machine.

The boot order may be specified using a mixture of device classes and device instances, chosen from among the following:

- CDROM: Boot from a virtual CD-ROM drive; the device instance(s) will be chosen by the BIOS subsystem.
- FLOPPY: Boot from a virtual floppy drive; the device instance(s) will be chosen by the BIOS subsystem.
- DISK: Boot from a virtual disk device; the device instance is specified explicitly in vcenter.vm.hardware.boot.device.entry.disks list, and multiple instances may be specified in the list.
- ETHERNET: Boot from a virtual Ethernet adapter; the device instance is specified explicitly as vcenter.vm.hardware.boot.device.entry.nic, and multiple adapters may be specified in the boot order list.

Type | Description
--- | ---
vcenter.vm.hardware.boot.device.entry | The `entry` structure specifies a bootable virtual device class or specific bootable virtual device(s).
vcenter.vm.hardware.boot.device.entry_create_spec | The structure `entry_create_spec` specifies a list of bootable virtual device classes. When a VM is being created and a array of `entry_create_spec` is specified, the boot order of the specific device instances are not specified in this structure. The boot order of the specific device instance will be the order in which the Ethernet and Disk devices appear in the `nics` and `disks` respectively.

## cdrom

The `cdrom` service provides operations for configuring the virtual CD-ROM devices of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.cdrom.backing_info | The `backing_info` structure contains information about the physical resource backing a virtual CD-ROM device.
vcenter.vm.hardware.cdrom.backing_spec | The `backing_spec` structure provides a specification of the physical resource backing a virtual CD-ROM device.
vcenter.vm.hardware.cdrom.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual CD-ROM device.
vcenter.vm.hardware.cdrom.info | The `info` structure contains information about a virtual CD-ROM device.
vcenter.vm.hardware.cdrom.summary | The `summary` structure contains commonly used information about a virtual CD-ROM device.
vcenter.vm.hardware.cdrom.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual CD-ROM device.

## cpu

The `cpu` service provides operations for configuring the CPU settings of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.cpu.info | The `info` structure contains CPU-related information about a virtual machine.
vcenter.vm.hardware.cpu.update_spec | The `update_spec` structure describes the updates to be made to the CPU-related settings of a virtual machine.

## disk

The `disk` service provides operations for configuring the virtual disks of a virtual machine. A virtual disk has a backing such as a VMDK file. The backing has an independent lifecycle from the virtual machine when it is detached from the virtual machine. The create operation provides the ability to create a new virtual disk. When creating a virtual disk, a new VMDK file may be created or an existing VMDK file may used as a backing. Once a VMDK file is associated with a virtual machine, its lifecycle will be bound to the virtual machine. In other words, it will be deleted when the virtual machine is deleted. The delete operation provides the ability to detach a VMDK file from the virtual machine. The delete operation does not delete the VMDK file that backs the virtual disk. Once detached, the VMDK file will not be destroyed when the virtual machine to which it was associated is deleted.

Type | Description
--- | ---
vcenter.vm.hardware.disk.backing_info | The `backing_info` structure contains information about the physical resource backing a virtual disk.
vcenter.vm.hardware.disk.backing_spec | The `backing_spec` structure provides a specification of the physical resource backing a virtual disk.
vcenter.vm.hardware.disk.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual disk.
vcenter.vm.hardware.disk.info | The `info` structure contains information about a virtual disk.
vcenter.vm.hardware.disk.summary | The `summary` structure contains commonly used information about a virtual disk.
vcenter.vm.hardware.disk.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual disk.
vcenter.vm.hardware.disk.vmdk_create_spec | The `vmdk_create_spec` structure provides a specification for creating a new VMDK file to be used as a backing for a virtual disk. The virtual disk will be stored in the same directory as the virtual machine's configuration file.

## ethernet

The `ethernet` service provides operations for configuring the virtual Ethernet adapters of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.ethernet.backing_info | The `backing_info` structure contains information about the physical resource backing a virtual Ethernet adapter.
vcenter.vm.hardware.ethernet.backing_spec | The `backing_spec` structure provides a specification of the physical resource that backs a virtual Ethernet adapter.
vcenter.vm.hardware.ethernet.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual Ethernet adapter.
vcenter.vm.hardware.ethernet.info | The `info` structure contains information about a virtual Ethernet adapter.
vcenter.vm.hardware.ethernet.summary | The `summary` structure contains commonly used information about a virtual Ethernet adapter.
vcenter.vm.hardware.ethernet.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual Ethernet adapter.

## floppy

The `floppy` service provides operations for configuring the virtual floppy drives of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.floppy.backing_info | The `backing_info` structure contains information about the physical resource backing a virtual floppy drive.
vcenter.vm.hardware.floppy.backing_spec | The `backing_spec` structure provides a specification of the physical resource backing a virtual floppy drive.
vcenter.vm.hardware.floppy.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual floppy drive.
vcenter.vm.hardware.floppy.info | The `info` structure contains information about a virtual floppy drive.
vcenter.vm.hardware.floppy.summary | The `summary` structure contains commonly used information about a virtual floppy drive.
vcenter.vm.hardware.floppy.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual floppy drive.

## memory

The `memory` service provides operations for configuring the memory settings of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.memory.info | The `info` structure contains memory-related information about a virtual machine.
vcenter.vm.hardware.memory.update_spec | The `update_spec` structure describes the updates to be made to the memory-related settings of a virtual machine.

## parallel

The `parallel` service provides operations for configuring the virtual parallel ports of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.parallel.backing_info | The `backing_info` structure contains information about the physical resource backing a virtual parallel port.
vcenter.vm.hardware.parallel.backing_spec | The `backing_spec` structure provides a specification of the physical resource backing a virtual parallel port.
vcenter.vm.hardware.parallel.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual parallel port.
vcenter.vm.hardware.parallel.info | The `info` structure contains information about a virtual parallel port.
vcenter.vm.hardware.parallel.summary | The `summary` structure contains commonly used information about a virtual parallel port.
vcenter.vm.hardware.parallel.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual parallel port.

## serial

The `serial` service provides operations for configuring the virtual serial ports of a virtual machine.

Type | Description
--- | ---
vcenter.vm.hardware.serial.backing_info | The `backing_info` structure contains information about the physical resource backing a virtual serial port.
vcenter.vm.hardware.serial.backing_spec | The `backing_spec` structure provides a specification of the physical resource backing a virtual serial port.
vcenter.vm.hardware.serial.create_spec | The `create_spec` structure provides a specification for the configuration of a newly-created virtual serial port.
vcenter.vm.hardware.serial.info | The `info` structure contains information about a virtual serial port.
vcenter.vm.hardware.serial.summary | The `summary` structure contains commonly used information about a virtual serial port.
vcenter.vm.hardware.serial.update_spec | The `update_spec` structure describes the updates to be made to the configuration of a virtual serial port.

## power

The `power` service provides operations for managing the power state of a virtual machine.

Type | Description
--- | ---
vcenter.vm.power.info | The `info` structure contains information about the power state of a virtual machine.