ESXi – Page 88

ESXi Thunderbolt Driver to Fibre Channel Storage from ATTO

09.12.2016 by William Lam // 6 Comments

One of the things I always enjoy doing at VMworld, when I am not running around and I have a few minutes to myself, is to check out the VMware Solutions Exchange. This is where you can learn and interact with hundreds of our VMware Certified Partners showcasing their new solutions and innovations that they have built on top of VMware's products.

UPDATE (08/22/17) - ATTO's ESXi Thunderbolt Driver is now officially on the VMware HCL, please see this blog post here for more details.

While walking through the show floor, I had stopped by the ATTO Technology booth who has been a long time partner of VMware in the storage and networking connectivity space. What caught my eye was that they had just released a Beta of an ESXi Thunderbolt Driver in the form of an ESXi VIB that would allow customers to connect their Apple Mac Pro 6,1 using the Thunderbolt 2 interface to an external Fibre Channel storage array. I believe ATTO might be the first vendor ever to produce a Thunderbolt Driver for ESXi. This is really exciting news if you ask me, especially as more and more of our customers are looking to virtualize Mac OS X guests in their Datacenters using vSphere.

Historically, the only option to connect a Mac Pro 6,1 to an external Fibre Channel array was to use something like a Sonnet Chassis. Now, you can potentially connect up to 6 of the built-in Thunderbolt 2 interfaces on the Mac Pro's to your external storage array using this new solution from ATTO. Before I go into some of the details, ATTO did want me to mention that this solution is currently not officially supported by VMware nor is it on VMware's HCL. ATTO will be providing full support on their software as well as VMware's software stack during the duration of the beta program. In terms of official certification on VMware's HCL, I suspect that it will most likely depend on customer demand which would influence whether ATTO applies for an official certification, which again, would be the first of its kind for Thunderbolt.

The way in which this solution works is that you install the ATTO Thunderbolt Driver on your ESXi host and this will allow it to communicate with an ATTO ThunderLink device which provides the Thunderbolt 2 to Fibre Channel connectivity. You have the option of using either the FC2082 which provides 20Gb/s Thunderbolt 2 (2-port) to 8Gb/s FC (2-Port) Device or the FC2182 which provides 20Gb/s Thunderbolt 2 (2-port) to 16Gb/s FC (2-Port) Device. Below is a diagram from the ATTO digital solution brief on Thunderbolt Driver for ESXi which outlines the configuration.

If you are interested in taking part in ATTO's ESXi Thunderbolt Driver Beta program or would like to learn more about the solution, you can reach out directly to Carllene Mowry (*protected email*) who is running the program. For more information be sure to check out the ATTO digital brief on Thunderbolt Driver for ESXi.

Lastly, I was also fortunate to have a quick chat with Carllene and team to get a few additional exclusive tidbits on some of the things the ATTO team is working on next. The first of which is support for the Thunderbolt 3 (aka USB-C) interface to Fibre Channel which will be quite nice for newer platforms that include that interface, including home lab setups such as the Intel NUC. Speaking of Intel NUC, this is just one of the many other platforms that include either Thunderbolt 2 or 3 interfaces. Although the solution today is specifically supporting the Mac Pro, I know ATTO folks are interested to hear from customers on other systems with Thunderbolt interface and providing similiar capabilities.

The other really exciting development that is currently being investigated is support for Thunderbolt 2 or 3 to 10GbE connectivity on ESXi. As you can imagine, this is really going to open up some really cool new use cases, especially around things like VSAN which can easily benefit from this. It is still in early development but from my understanding, ATTO is already seeing a lot of interest in this area as well as how this might work with VSAN. I am hoping I will be able to share more details as this further develops. If any of these updates sounds interesting, do leave a comment to let the ATTO folks know and I will make sure they monitor the thread.

Quick Tip - How to retrieve the ESXi Update Level using the vSphere API?

08.17.2016 by William Lam // Leave a Comment

Using the vSphere API, it is very easy to extract the version and build of all your ESXi hosts. This information is exposed in the Product property of an ESXi host. For example, Product.Version will return something like 6.0.0 and Product.Build will return something like 3029758. However, one thing that is not available in this property is the Update Level information for an ESXi host such as Update 1 or Update 2.

Historically, customers would have to rely on ESXCLI to pull the Update level information using the following command: esxcli system version get and though this can be run remotely or integrated into PowerCLI as shown in the example below, it would be ideal if this information was just available using the vSphere API.

	$esxcli = Get-EsxCli

	### To retrieve Major/Update version number of ESXi via ESXCLI

	PS C:\Users\lamw\Desktop> $esxcli.system.version.get().version + " Update" + $esxcli.system.version.get().update
	6.0.0 Update1

	### To retrieve all version information from ESXi via ESXCLI

	PS C:\Users\lamw\Desktop> $esxcli.system.version.get()

	Build : Releasebuild-3029758
	Patch : 17
	Product : VMware ESXi
	Update : 1
	Version : 6.0.0

view raw

gistfile1.txt

hosted with ❤ by GitHub

This exact same question was brought up internally again today and Etienne Le Sueur actually shared an awesome tidbit on how to retrieve this information using the vSphere API. You can find the ESXi Update Level information in an ESXi Advanced Setting called Misc.HostAgentUpdateLevel

Below is a quick PowerCLI example which exercises this vSphere API to retrieve the Version, Build and Update Level information:

$vmhost = Get-VMHost -Name nuc.primp-industries.com

$esxi_version = $vmhost.ExtensionData.Config.Product.Version
$esxi_build = $vmhost.ExtensionData.Config.Product.Build
$esxi_update_level = (Get-AdvancedSetting -Entity $vmhost -Name Misc.HostAgentUpdateLevel).value

Write-Host "$vmhost" 
Write-Host "`tVersion: $esxi_version"
Write-Host "`tUpdate: $esxi_update_level"
Write-Host "`tBuild: $esxi_build"

Here is a screenshot of the output for my ESXi host which is running latest vSphere 6.0 Update 2 (including the recent patch release).

Its great to hear that the ESXi Update Level information is available through the vSphere API, although I would have liked to have seen it exposed within the Product property. Perhaps its time to file an internal Feature Request? 🙂

Remotely query an ESXi host without adding it to vCenter Server

07.19.2016 by William Lam // Leave a Comment

I was browsing through the vSphere API Reference the other day and I came across an interesting vSphere API called QueryConnectionInfoViaSpec() which was introduced in vSphere 6.0. This new API is similiar to the existing QueryConnectionInfo() method which also allows you to remotely query an ESXi host without requiring you to add it to your vCenter Server Inventory, which I did not know about before. Some of the information that you can retrieve is whether it is currently being managed by an existing vCenter Server and if so, what is its IP Address, any registered Virtual Machines, networks and datastores that may be configured along with underlying host capabilities.

The main difference between this new API is that instead of accepting a list of arguments to the method, it accepts a HostConnectSpec. It is a minor difference, but what this allows you to do is to be able to re-use that exact same spec in the AddHost_Task() API if you determine that you would like to add the ESXi host to your vCenter Server Inventory after inspecting the remote ESXi host. I think this is a useful API if you want to validate that you are not stealing an ESXi host from another managed vCenter Server and if you are, at least you know which vCenter Server it was being managed by. To demonstrate this vSphere API, I have created a simple PowerCLI script called Get-RemoteESXi.ps1 which requires a vCenter Server login as well as the Hostname/IP Address and credentials of the remote ESXi host you wish to query.

Here is an example output of running the script which stores the returned output to the $results variable.

If you want to check whether the ESXi host is being managed by an existing vCenter Server, you can check the following property which will hold the IP Address of the vCenter Server if it is currently being managed:

$result.Host.ManagementServerIp

If you want to check if there are running VMs already on the ESXi host, you can check the following property:

$result.vm

As mentioned earlier, there is a ton of other information returned from the remote ESXi host and I will leave it as an exercise for the reader to explore further.