WilliamLam.com

Identifying ESXi boot method & boot device

by // 16 Comments

There was an interesting discussion on our internal Socialcast platform last week on figuring out how an ESXi host is booted up whether it is from local device like a disk or USB device, Auto Deploy or even boot from SAN along with its respective boot device? Although I had answered the question, I was not confident that we actually had a reliable and programmatic method for identifying all the different ESXi boot methods, which of course piqued my interest.

With a bit of trial and error in the lab, I believe I have found a method in which we can identify the ESXi boot type (Local, Stateless, Stateless Caching, Stateful or Boot from SAN) along with some additional details pertaining to the boot device. To demonstrate this, I have created the following PowerCLI script ESXiBootDevice.ps1 which contains a function called Get-ESXiBootDevice.

The function can be called without any parameters, in which it will query all ESXi hosts for a given vCenter Server and/or standalone ESXi host. You can also specify a specific ESXi host by simply passing in the -VMHostname option.

Here is an example output for one of my lab environments which shows several ESXi hosts and their different boot methods from local disk to Auto Deploy which can include stateless, stateless caching and stateful deployments. Depending on the BootType, the boot device shown in the Device column will either be the MAC Address of the NIC used to network boot the ESXi host or the identifier of a disk device. I have also included some additional details such as vendor/model along with the media type (SAS, SSD or USB) which is available as part of ESXCLI.


This script also supports ESXi environments that boot from SAN (FC, FCoE or iSCSI) and you can easily identify that with the word "remote" for the BootType. I would like to give a huge thanks to David Stamen who helped me out with the boot from SAN testing.

Workarounds for deploying PhotonOS 2.0 on vSphere, Fusion & Workstation

by // 2 Comments

PhotonOS 2.0 was just released last week and it includes a number of exciting new enhancements which you can read more about here. Over the last few days, I had noticed quite a few folks having issues deploying the latest PhotonOS OVA, including myself. I figure I would share the current workarounds after reaching out to the PhotonOS team and seeing the number of questions both internally and externally.

Deploying PhotonOS 2.0 on vSphere

If you are deploying the latest OVA using either the vSphere Web (Flex/H5) Client on vCenter Server or the ESXi Embedded Host Client on ESXi, you will notice that the import fails with the following error message:

The specified object /photon-custom-hw13-2.0-304b817/nvram could not be found.


This apparently is a known issue with the vSphere Web/H5 Client bug with exported vHW13 Virtual Machines. As I understand it, the actual fix did not make it in the latest vSphere 6.5 Update 1 release, but it should be available in a future update. After reporting this issue to the PhotonOS team as I ran into this myself, the team quickly re-spun the vHW11 OVA (since that image also had a different issue) which can now be imported into a vSphere environment using any of the UI-based Clients and/or CLIs. For now, the workaround is to download PhotonOS 2.0 "OVA with virtual hardware v11" if you are using vSphere OR you can install PhotonOS using the ISO.

Deploying PhotonOS 2.0 to Fusion/Workstation

UPDATE (11/08/17) - The PhotonOS team just published an additional OVA specifically for Fusion/Workstation which uses LSI Logic storage adapter as PVSCSI is currently not supported today. You can easily import latest PhotonOS 2.0 without needing to tweak the OVF as mentioned in the steps below, simply download the OVA with virtual hardware v11(Workstation and Fusion) and import normally via UI or CLI.

If you are deploying either of the vHW11 or vHW13 OVA to Fusion/Workstation, you see the following error message:

Invalid target disk adapter type: pvscsi


The reason for this issue is that neither Fusion/Workstation currently support the PVSCSI storage adapter type which the latest PhotonOS OVA uses. In the meantime, a workaround is to edit the OVA to use the LSI Logic adapter instead of the PVSCSI. Below are the steps to convert the OVA to OVF and then apply the single line change.

Step 1 - Use OVFTool (included with both Fusion/Workstation) to convert the OVA to an OVF which will allow us to edit the file. To do so, run the following command:

ovftool --allowExtraConfig photon-custom-hw13-2.0-304b817.ova photon-custom-hw13-2.0-304b817.ovf

Step 2 - Open the photon-custom-hw13-2.0-304b817.ovf using a text editor like Visual Studio Code or VI and update the following line from:

<rasd:ResourceSubType>VirtualSCSI</rasd:ResourceSubType>

to

<rasd:ResourceSubType>lsilogic</rasd:ResourceSubType>

and save the change.

Step 3 - Delete the OVF manifest file named photon-custom-hw13-2.0-304b817.mf since the contents of the file has been updated

Step 4 - You can now import the modified OVF. If you wish to get back the OVA, you can just re-run Step 1 and use the .ova extension to get back a single file

Upgrading from Photon 1.x to 2.0

I also noticed several folks were asking about upgrading from Photon 1.0 to 2.0, you can find the instructions below:

Step 1 - You may need to run the following if you have not done so in awhile:

tdnf distro-sync

Step 2 - Install the PhotonOS upgrade package by running the following command:

tdnf install photon-upgrade

Step 3 - Run the PhotonOS upgrade script and answer 'Y' to start the upgrade:

photon-upgrade.sh

ATTO's ESXi Thunderbolt Driver is now officially on VMware HCL

by // 1 Comment

Last week I had received some great news from our friends over at ATTO Technology that their ESXi Thunderbolt to Fibre Channel Driver has passed the VMware Certification process and is now officially listed on VMware's HCL. I had known the team was planning to certify their driver but was not aware of their timelines and whether it would actually get accepted given the fact that this was for a Thunderbolt-based device, which is the first of its kind for the VMware HCL.

Funny enough, it was roughly around this time last year that ATTO released a Beta of their ESXi Thunderbolt to Fibre Channel Driver which I had shared with my readers here. I was not surprised by the demand given the fact that no official solutions exists for customers who would like to take advantage of their existing SAN-based storage infrastructure when virtualizing Apple macOS (iOS development, etc) on vSphere. ATTO has certified two of their ThunderLink devices, customers have the option of using either the TLFC2082 which provides 20Gb/s Thunderbolt 2 (2-port) to 8Gb/s FC (2-Port) Device or the TLFC2182 which provides 20Gb/s Thunderbolt 2 (2-port) to 16Gb/s FC (2-Port) Device which is supported from ESXi 5.5u3 all the way up to latest 6.5u1 release.


Click here for the direct link to VMware HCL.

Huge congrats to the ATTO team for getting this on the VMware HCL and partnering up with VMware to provide a solution for our customers who virtualize Apple macOS using vSphere!

Lastly, if you are going to be at VMworld and you are interested in learning more about this solution, be sure to drop by the ATTO booth.