vsphere C# client

Heads Up: OVF/OVA always deployed as Thick on VSAN when using vSphere Web Client

06/03/2016 by William Lam 23 Comments

Just wanted to give folks a heads up on an issue that a colleague of mines recently identified when provisioning Virtual Appliances (OVF/OVA) onto a VSAN datastore when using the vSphere Web Client. He found that regardless of the VSAN Storage Policy that was selected, whether it is the default VSAN Storage Policy or a custom one, the Virtual Appliance will always be Thick provisioned.

This behavior only occurs when using the vSphere Web Client and is not observed when using either the vSphere C# Client or the ovftool CLI. My understanding of the issue is that there are two ways in which a VM can get provisioned as Thin. The "old" method which was to explicitly specify the disk allocation type (Thin vs Thick) and the "new" method which uses VM Storage Policies. To ensure that we maintain backwards compatibility for older clients, if a client specifies Thick provisioned, it would actually override the VM Storage Policy even if the Object Space Reservation capability was set to 0 (Thin provisioned). Since you can no longer specify the disk allocation type in the vSphere Web Client, the default behavior is to not Thin provision and hence the current Thick provisioning result even though the default VSAN Storage Policy has OSR set to 0.

Note: When referring to Thick provisioned in VSAN (proportionalCapacity = 100), It is defined as provisioned Thin with a reservation so there is a guarantee that space is available for the object. It is not accurate to compare this to Zeroed Thick or Eager Zeroed Thick in the VMFS/NFS world as VSAN is an Object Store.

Engineering has already been engaged and is currently investigating the issue. We have also asked for a VMware KB to be published, so hopefully once that goes up, folks can subscribe to that for more details and updates.

In the meantime, since it is actually pretty difficult to see if you have been affected by issue, I have created a simple PowerCLI script called Get-VSANPolicy.ps1 which will allow you to quickly scan through your VM(s) to identify whether you have any VMs that have been Thick provision residing on a VSAN Datastore. You can either get all VMs by piping Get-VM * or a specific set of VMs into the script.

The following example retrieves all VMs that start with "Photon-Deployed-From-*" and extracts their current VSAN VM Storage Policy for both VM Home and individual VMDKs. Here, we can see that both VMs are using the default VSAN VM Storage Policy.

Get-VM "Photon-Deployed-From-*" | Get-VSANPolicy -datastore "vsanDatastore"

Lets now only search for VMs that have been Thick provisioned by using the -thick option and setting that to true. Here we can see that the OVF we provisioned through the vSphere Web Client is the only VM listed.

Get-VM "Photon-Deployed-From-*" | Get-VSANPolicy -datastore "vsanDatastore" -thick $true

If we want to get more details on the underlying VM Storage Policy that was applied, we can also specify the -details option to true. Here we can clearly see that the 2nd VM has proportionalCapacity=100 which means Thick provision.

Get-VM "Photon-Deployed-From-*" | Get-VSANPolicy -datastore "vsanDatastore" -thick $true -details $true

Luckily, the fix is quite easy thanks to Paudie O'Riordan who found out that it was as simple as just re-applying the VSAN VM Storage Policy! (Policy Based Management FTW!) This means there is no need to perform unnecessary Storage vMotions to be able to convert the VM from Thick to Thin, it is literally a couple of clicks in the UI.

UPDATE (07/15/16) - Thanks to reader Jose, it looks like using the vSphere Web Client to re-apply the VSAN VM Storage Policy will correctly apply the policy to the VM/VMDKs, but does not reclaim the underlying storage. It is recommended that you use the PowerCLI script below to re-apply the policy which will then properly reclaim the underlying storage and will properly reflect the storage utilization.

As with anything, I still prefer Automation and with that, I have created a secondary script to help with the remediation. This is also a PowerCLI script called Set-VSANPolicy.ps1 which accepts a list of VMs and the name of the VSAN VM Storage Policy that you wish to re-apply.

Here is an example of running the script and remediating two VMs that contains multiple VMDKs:

Set-VSANPolicy -listofvms $listofvms -policy $vsanpolicy

If you now re-run the first script, you should see that you no longer have VMs that are provisioned Thick anymore (this may take some time depending on the size of your VMs).

Edit Virtual Hardware 10 VMs using vSphere 5.5 Update 2 C# Client

09/09/2014 by William Lam 13 Comments

vSphere 5.5 Update 2 has just released and among the various bug fixes, one that stands out the most to me and I am sure everyone will be quite happy about (including myself) is the ability to now edit a Virtual Hardware 10 Virtual Machine using the legacy vSphere C# Client. Previously, if you tried to edit a Virtual Machine running the latest Virtual Hardware (version 10), you would get a warning message prompting you to use the vSphere Web Client and the operation would be blocked.

The feedback has been loud and clear from customers/partners and I am glad to see that VMware has re-instated this functionality in the latest vSphere 5.5 Update 2 C# Client. You will still be prompted with a dialog noting that only Virtual Hardware Version 8 features will be editable using the vSphere C# Client and that all newer Virtual Hardware features, you should still leverage the vSphere Web Client and/or vSphere API. This will at least allow you to edit basic functionality of a VM when vCenter Server is unavailable or if you are not running vCenter Server but wish to use the new Virtual Hardware version.

Here is the direct download link for the vSphere 5.5 Update 2 C# Client: http://vsphereclient.vmware.com/vsphereclient/1/9/9/3/0/7/2/VMware-viclient-all-5.5.0-1993072.exe

Note: You do not need to install vSphere 5.5 Update 2 to be able to use this new functionality, you just need to upgrade your vSphere C# Client to the vSphere 5.5 Update 2 release and you will be able to connect to previous versions of vSphere 5.5 (vCenter Server & ESXi).

Quick Tip – Using the CLI to upgrade to a specific VM virtual hardware version in vSphere 5.5

10/30/2013 by William Lam 4 Comments

For those of you who usually use the "legacy" vSphere C# Client to perform virtual machine virtual hardware upgrade (also known as Virtual Machine Compatibility) should know that the default behavior is to automatically upgrade to the latest supported version. This is usually not an issue, however with vSphere 5.5 if you do perform this upgrade, one caveat to be aware of that you will NOT be able to edit the virtual machine configurations using the vSphere C# Client afterwards. A confirmation dialog is even presented to warn the user before performing this operation and that the virtual machine can only be manage through the vSphere Web Client.

Note: Even though the virtual machine settings can not be managed/configured using the vSphere C# Client, you can still use the various vSphere API/CLIs to manage the virtual machine and those are fully supported.

I had noticed a couple of comments on Twitter the other day and even at VMworld Barcelona that this was not ideal that the vSphere C# Client automatically upgraded to the latest version. I know there are some folks that would have liked to upgrade to a specific version of virtual hardware. Luckily, you can easily do so by using the vSphere API/CLI such as PowerCLI for example if you have paid vSphere license.

You can use the Set-VM cmdlet and specify the -Version property, here is the syntax for the command:

Set-Vm -VM (Get-VM -Name [VM-NAME]) -Version v[HW-VERSION]

Here is a screenshot of upgrading a VM called "Duncan" from vHW8 to vHW9:

Now this is great for customers who have a vSphere license that allows for both read/write access to the APIs which PowerCLI and other CLIs leverage. For customers using Free ESXi or just want a quick and simple way of upgrading to a specific virtual hardware version, you can leverage vim-cmd utility which is found in the ESXi Shell.

You can use the following command to upgrade to a specific virtual hardware version (you will need to specify the VM-ID by using vim-cmd vmsvc/getallvms):

vim-cmd vmsvc/upgrade [VM-ID] vmx-[HW-VERSION]

Here is a screenshot of upgrading a VM called "Cormac" from vHW7 to vHW9:

You no longer can install vSphere C# Client on Windows Domain Controller in vSphere 5.5

09/25/2013 by William Lam 2 Comments

In the last couple of days I have noticed several folks comment on a new check that has been put in place in vSphere 5.5 which prevents a user from installing the vSphere C# Client onto a Windows Domain Controller system. If you try to install the vSphere C# Client on a Domain Controller system, you will get the following error message:

It is generally not recommended to install additional software on a Windows Domain Controller and I suspect this check was put in place to deter users from installing additional software, including VMware software onto a Domain Controller system. However, for a development environment or home lab, you may want to consolidate multiple applications onto a single system and help reduce the number of Windows systems that you may need to deploy. Luckily there is a way to by-pass this check and I am actually glad one exists as this is something I will need while building out some of internal labs.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

To by-pass the check, you will need to launch the vSphere C# Client install from the command-line and pass in the following arguments:

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

Now the installer should allow you to proceed with the vSphere C# Client installation.

Handy Keyboard Shortcuts for the vSphere Web Client

07/30/2013 by William Lam 7 Comments

After publishing an article about the vSphere Web Client Recent History Feature, I received question from a reader asking about the keyboard shortcuts that were available as part of the legacy vSphere C# Client. The reader really enjoyed these shortcuts as a way to quickly navigate between the various inventories and was wondering if similar keyboard shortcuts existed for the new vSphere Web Client? I was not able to find anything in our documentation and decided to reach out to our UE (User Experience) folks to see if they could assist.

Though we do not have every single keyboard shortcut that was available from the legacy vSphere C# Client, we actually do have quite a few and this somehow must have gotten missed during documentation (I have filed documentation bug on this). In talking to our UE folks, some of the challenges in adding the keyboard shortcuts was to find shortcuts that have not already been taken by either a web browser (vSphere Web Client is a browser application) or the Operating System used to connect to the vSphere Web Client. It was also very important if new shortcuts were added, that it would be easy to understand. As you can see this was not a trivial task at all.

The screenshot below provides a quick overview of the available keyboard shortcuts for the vSphere Web Client. Take a look at the table below for a more detailed break down of each keyboard shortcut.

Keyboard Shortcuts

Keyboard Combination	Action
Ctrl+Alt+s	Quick Search
Ctrl+Alt+Home OR Ctrl+Alt+1	Home Screen
Ctrl+Alt+2	Virtual Infrastructure Inventory
Ctrl+Alt+3	Hosts and Clusters Inventory
Ctrl+Alt+4	VMs and Templates Inventory
Ctrl+Alt+5	Datastores and Datastore Clusters Inventory
Ctrl+Alt+6	Networking Inventory

I was able to verify these shortcuts on both a Mac OS X system as well as a on Windows. This is something I definitely will be bookmark as a useful reference. If there are other keyboard shortcuts that you have grown to rely on in the legacy vSphere C# Client and would like to see in the new vSphere Web Client, feel free to leave a comment and I will make sure it gets to our UE folks.

Blocking vSphere C# Client Logins

12/10/2012 by William Lam 5 Comments

I recently picked up on this neat little tidbit from Mr. Not Supported aka Randy Keener, where you can block a user from logging into the vCenter Server using the vSphere C# Client. Other than playing a prank on your co-workers, you might be wondering is there a use case for this? Surprisingly, this is a request I have heard from a few customers in the past where they would like to block their users from using the vSphere C# Client in favor of leveraging only the vSphere APIs for routine tasks.

Since the vSphere C# Client also uses the vSphere API itself, a user with proper credentials to the vSphere environment can easily download the client from an alternative source and still login. Of course, there are ways of preventing this such as restricting application installation on end users desktop but there is some amount of management overhead of identifying those existing and new users, especially if access is delegated out to other teams.

There is a very simple solution if you choose to block ALL users from using the vSphere C# Client which requires a tiny modification on the vCenter Server itself and it takes effect immediately with no service restarts.

Disclaimer: This is probably not officially supported by VMware, use at your own risk.

Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
VCSA: /etc/vmware-vpx/docRoot/client

There is parameter called exactVersion which will be set to current supported version of the vSphere C# Client which should also match the version of your vCenter Server. You just need to change this to some other value that you know will not exist in your environment such as 9.0.0. Once you have made this change, now when a user tries to connect and there is a miss-match in the version, the vCenter Server will provide you with a download to the vSphere C# Client located on the server as it normally would if you did not have the latest client.

What the user will find out shortly, is that this will continue in an infinite loop even after installing the proper vSphere C# Client. The reason for this is that the number in version.txt will never match the vSphere C# Client and vCenter Server will just continue serving the installer in an infinite loop. I also looked into this trick for a standalone ESXi host and you can do the same by editing a file called clients.xml which is located in /usr/lib/vmware/hostd/docroot/client and users will not be able to login to the ESXi host using the vSphere C# Client.

Now, even though this prevents users from logging into the vSphere C# Client, users will still be able to connect using the vSphere API which includes the use of vCLI/ESXCLI, PowerCLI, vCO, SDKs, etc. and the use of the vSphere Web Client for either vSphere 5.0 or 5.1 will continue to work. Ideally, it would be nice to be able to control this access on a per user/group basis and perhaps even specify how a user can connect whether that is through the use of the APIs or UI only. Is this even useful to have at all? Would love to hear your comments.

For now, if you want users to get familiar with the new vSphere Web Client 5.1 ... this is one way of "encouraging" them 😉