vSphere Command-Line Interface 6.7 Release Notes

Released 17 Apr 2018

Build 8156551 is the 6.7 release of the vSphere Command-Line Interface (vCLI).

Release notes last updated on 19 Apr 2018.

Check frequently for additions and updates to these release notes.

vCLI 6.7 Release Notes

Welcome to the vCLI 6.7 release notes. Version numbers referenced in this document are placeholders and do not represent any commitment by VMware to have any features included in specific software versions.

This document contains the following information:

About vCLI

The vCLI command set allows you to run common system administration commands from any machine with network access to those systems. vCLI includes a set of host management commands and DCLI commands for managing vCenter services that are new in vSphere 6 and later. You can run most host management commands against a vCenter Server system and target any ESXi system that the vCenter Server system manages.

Many vCLI commands run on top of the vSphere SDK for Perl. Both vCLI and the vSphere SDK for Perl are included in the same installation package.

What's New in vSphere CLI 6.7

OS support — This release adds support for Red Hat Enterprise Linux (RHEL) 7.3 (Server) 64-bit.

Linux installation — This release consolidates the Linux installation process. There is no separate installation process for RHEL platforms.

Updated libraries — This release includes updated libraries that add support for ESXi 6.7 and vCenter Server 6.7. If you have an earlier version installed on your system, you must replace the existing libraries with the new libraries.

ESXCLI — New commands that cover device, hardware, iSCSI, network, NVMe, RDMA, storage, system, and vSAN operations have been added to the ESXCLI command set. ESXCLI elxnet commands are not included in this release.

DCLI — New commands that cover vAPI metadata, appliance management, appliance recovery, appliance health, appliance networking, appliance update, content library, virtual machine management, virtual machine hardware, storage policy, inventory, and deployment operations have been added to the DCLI command set.

Feature and Support Notice

The vicfg- command set is now fully deprecated and will be removed in a future release. You can use ESXCLI equivalents of vicfg- commands.

Future DCLI versions will be distributed through the PyPI repository. The DCLI command set will not be included in future vCLI releases.

Caveats and Limitations

The DCLI command set includes the following commands that have known issues and might be removed in a future version. It is advised that these commands are not invoked:

  • vcenter systemconfig deploymenttype reconfigure
  • vcenter systemconfig pscregistration repoint
  • vcenter deployment upgrade cancel
  • vcenter deployment rollback

Supported Platforms

For this release, vCLI is supported on the following Linux platforms:

  • Red Hat Enterprise Linux (RHEL) 6.6 (Server) — 64-bit
  • Red Hat Enterprise Linux (RHEL) 7.1 (Server) — 64-bit
  • Red Hat Enterprise Linux (RHEL) 7.3 (Server) — 64-bit
  • Ubuntu 12.04 (LTS) — 64-bit
  • Ubuntu 14.04 (LTS) — 64-bit
  • Ubuntu 15.10 (LTS) — 64-bit
  • Ubuntu 16.04 (LTS) — 64-bit
  • SLES 11 SP3 — 64-bit
  • SLES 12 — 64-bit

For this release, vCLI is supported on the following Windows platforms:

  • Windows 8 (64-bit)
  • Windows 10 (64-bit)
  • Windows 2008 (64-bit)
  • Windows 2012 R2 (64-bit)

Resolved Issues

  • Running VMware vSphere Automation SDK for Perl 6.5 samples on Windows fails with an error
    If you try to run VMware vSphere Automation SDK for Perl 6.5 samples on Windows, you receive an error message of type (pythondll) failed. The specified module could not be found.

Known Issues

  • Using DCLI_HISTFILE without read and write permissions in DCLI interactive mode results in an error
    If the DCLI_HISTFILE environment variable is set to a file for which you do not have read and write permissions, DCLI interactive mode fails and you receive a Permission denied error message.

    Workaround: Either unset DCLI_HISTFILE to let DCLI use the default history file in your home directory, or give read and write permissions to DCLI_HISTFILE to allow DCLI interactive mode to work.

  • In interactive mode, DCLI uses previously entered credentials even if authorization failed with those
    If you run DCLI in interactive mode and invoke a command that requires authentication, DCLI prompts for credentials. If you enter credentials for a user who does not have permissions to perform the operation, you receive an Unauthorized error message. If you try to invoke the same command again, DCLI does not prompt you to enter new credentials and uses the credentials that you previously entered instead.

    Workaround: Either pass +username to specify different credentials, or save the correct credentials in the credential store.

  • The resxtop command runs in batch mode by default
    When you run the resxtop command on an RHEL 6.6 64-bit platform, it runs in batch mode by default. The command must run in interactive mode.

    Workaround: To run the command in interactive mode, set the TERMINFO environment variable.
    Run the command: export TERMINFO=/usr/share/terminfo
    The output of the resxtop command should be returned in interactive mode.

  • DCLI not included in default path in vSphere Management Assistant
    DCLI is not part of the path in vSphere Management Assistant. Unless you are in the DCLI directory, an error results if you run a DCLI command.

    Workaround: You have the following options.

    • Navigate to the dcli directory and then run the /usr/lib/vmware-vcli/bin/vmware-dcli/dcli command.
    • Add DCLI to the vSphere Management Assistant PATH as follows: export PATH=$PATH:/usr/lib/vmware-vcli/bin/vmware-dcli/.
  • vmkfstools reports the same volume twice.
    If a VMFS (Virtual Machine File System) volume and its snapshot are both mounted, vmkfstools reports the volume twice.

    Workaround: No workaround needed.

  • Parameter values with spaces result in error for esxcli image command.
    When you run esxcli image with --vib|-v, --depot|-d, or --meta|-m and supply a parameter value that contains spaces, the second part of that parameter value is treated as a separate argument. An error results.

    Workaround: Surround the parameter value with double quotes.

  • Cannot clone VMDK files from a non-VMFS directory using the vmkfstools vCLI
    When you attempt to run the vmkfstools vCLI to clone a VMDK file that is not located in a VMFS directory, the command fails with a message Invalid datastore path. The operation does not fail if you use the vmkfstools service console command.

    Workaround: Move the VMDK file into the VMFS datastore and repeat the clone operation.

  • Users with read-only role cannot display some information on target servers
    You create a user running the vicfg-user vCLI, and you assign the read-only role to the user. When that user attempts to retrieve information from an ESX/ESXi host, the information is not always available. For example, when the user runs vicfg-module <conn_options> --list, no modules are displayed even if those modules actually exist. When the user runs vicfg-dumppart <conn_options> --list, no diagnostic partitions are displayed.

    Workaround: No workaround for this issue. You can log in as a user with read and write permissions to display the information.

  • Problems using vmkfstools to create VMFS3 volume when using VML name of LUN
    When you run vmkfstools -C vmfs3 to create a VMFS3 volume, and you use the VML name for the LUN, the command might fail even if the VML name is a soft link to a device name (naa.xxx name). The command might fail, for example, if a VMFS3 volume already exists on the LUN.

    Workaround: Use the device name (naa.xxx or eui.xx) to refer to the LUN.

  • Running vmkfstools -C does not prompt for confirmation
    When you run vmkfstools -C to create a VMFS on a partition that already has a VMFS on it, the command erases the existing VMFS and creates the new VMFS without prompting for confirmation.

    Workaround: No workaround. Check the command carefully before running it.

  • Diagnostic partition change is not persistent under certain conditions
    If you call esxcfg-dumppart or vicfg-dumppart to change the diagnostic partition, and if your ESX/ESXi system experiences a failure within an hour after this change is made and before the host is rebooted, the diagnostic partition reverts to the original setting.

    Workaround: Use the esxcli system coredump commands instead. If using vicfg-dumppart, reboot the ESXi system immediately after changing the partition.

  • When using svmotion in interactive mode, cannot specify non-ASCII characters as input
    When you use svmotion in interactive mode, you cannot specify non-ASCII input, for example, a German datacenter name.

    Workaround: Run svmotion in non-interactive mode and use quotes around the datacenter name.

  • Error when using vicfg-iscsi to set up IP, subnet, and gateway separately
    You perform a factory reset on a QLogic hardware iSCSI card that results in an error. If you then use the vicfg-iscsi vCLI command to set IP address, subnet mask, and gateway separately, an error status results in which the addresses for IP, subnet mask, default gateway, and DNS are set to NULL (0.0.0.0). This is also a problem if the address is 0.0.0.0 for other reasons.

    Workaround: Use the following command to reset the IP address, subnet mask, and gateway at the same time.

    vicfg-iscsi --network --ip <ip_addr> --subnetmask <subnet_mask> --gateway <default_gateway> <adapter_name>
  • Cannot modify hardware iSCSI adapter MTU using vicfg-iscsi
    When you call vicfg-iscsi <conn_params> --pnp --mtu <number> <vmhba> to modify the MTU for a hardware iSCSI adapter, the MTU does not actually changed and an error indicates the property cannot be set.

  • vicfg-vmknic completes successfully but displays error
    When you set up an ESXi Installable system with a DHCP IP address, and then set an explicit IP address by running vicfg-vmknic -i -n -p, the IP address is set successfully. However, a SOAP error is displayed. This problem has been found on ESXi Installable only.

    Workaround: No workaround needed, the IP address is set successfully.

  • vicfg-volume does not maintain global data center information in a distributed environment
    In a distributed environment you mounted (persistent/no persistent) an unresolved volume from one ESX/ESXi system using vicfg-volume -M. From another ESX/ESXi system, you run vicfg-volume -r to resignature that unresolved volume. If the mounted volume is not active, running the volume resignature command unmounts the volume. The volume appears as a resignatures volume to all hosts in the environment.

    In contrast, if you use vSphere Client to mount an unresolved volume from one host and issue resignature from another host, the vSphere Client generates a warning to let users know that volume has been mounted on another host and resignature does not succeed.

    Workaround: Use esxcli storage filesystem commands or the vSphere Web Client instead of the vicfg-volume command to resignature volumes in a distributed environment.