virtuallyGhetto

vSphere

Supermicro E300-9D (SYS-E300-9D-8CN8TP) is a nice ESXi & vSAN kit

by 12 Comments

Supermicro kits such as the E200-8D is a very popular platform amongst the VMware community and with powerful Xeon-based CPUs and support for up to 128GB of memory, it is perfect for running a killer vSphere/vSAN setup!

Earlier this Fall, Supermicro released a "big daddy" version to the E200-8D, dubbed E300-9D and specifically, I want to focus on the 8-Core model (SYS-E300-9D-8CNTP) as this system actually listed on the VMware HCL for ESXi! The E300-9D can support up to half a terabyte of memory and with the 8-Core model, you have access to 16 threads. The E200-8D is also a supported platform by VMware, you can find the VMware HCL listing here.


I was very fortunate to get my hands on a loaner E300-9D (8-Core) unit, thanks to Eric and his team at MITXPC, a local bay area shop specializing in embedded solutions. In fact, they even provided a nice vGhetto promo discount code for my readers awhile back, so definitely check it out if you are in the market for a new lab. As an aside, when doing a quick search online, they also seem to be the only ones actually selling the E300-9D (8-Core) system which you can find here and in general, they seem to be priced fairly competitively. This is not an endorsement for MITXPC, but recommend folks to compare all prices when shopping online, especially as today is Black Friday in the US and Cyber Monday is just a few days away.

[Read more...] about Supermicro E300-9D (SYS-E300-9D-8CN8TP) is a nice ESXi & vSAN kit

Is vCenter Server & ESXi hosts using VMware Certificate Authority (VMCA) or custom CA certificates?

by Leave a Comment

Customers have two primary methods of managing TLS certificates for their ESXi hosts, they can either use the built-in VMware Certificate Authority (VMCA) which is part of vCenter Server or Custom CA Certificates. I will not go into the gory details, but you can read more about the options here in our documentation.

A question that I had received recently was whether you can determine the type of certificate an ESXi host was provisioned with and whether this could be programmatically retrieved using the vSphere API? The answer is yes. In vSphere 6.0, we introduced a CertificateInfo property which contains a number of fields including status, issuer, expiry and subject details and by inspecting either the issuer or subject property, you can determine the type of certificate on the ESXi host.

Here is a screenshot of the data using the vSphere MOB for an ESXi host that has VMCA-based certificate:


Here is a screenshot of the data using the vSphere MOB for an ESXi host that has custom CA certificate:


As you can see, for VMCA-based certificate the issuer's OU will have value of "VMware Engineering" and subject's emailAddress will have value of "vmca@vmware.com".

[Read more...] about Is vCenter Server & ESXi hosts using VMware Certificate Authority (VMCA) or custom CA certificates?

New VMware Configuration Maximum Tool

by 1 Comment

VMware has just released a new web-based tool that will enable customers to easily view and compare product configuration maximums across different VMware product versions. You can access the easy to remember URL by going to: https://configmax.vmware.com

In this first release of this tool, customers will have the ability to look up configuration maximums for vSphere (includes VSAN) which will initially support vSphere 6.0, vSphere 6.5, vSphere 6.5 Update 1 & the recently released vSphere 6.7 as well as comparing across versions. To view the existing vSphere configuration maximum, simply click on the "Get Started" button.


As you can see from the screenshot below, you now have a single place where you can view the vSphere configuration maximums across different versions. Once you have selected the target version, you can either view all maximums or you can selectively choose the sections you are interested in.


The other really neat feature is the ability to compare the configuration maximums across different vSphere versions. This is really useful for customers to be able to quickly tell what improvements and enhancements have been made, especially as customers plan for vSphere upgrades. To begin, simply click on the "Compare Limits" button at the top. Next, select  the target vSphere version and then you can add one or more versions to compare against.


Once you click on the Compare button, a new window will popup providing you the comparison between the target and selected vSphere versions. You can quickly see how the maximums have changed across these vSphere versions. You can even export the results to Excel by click on export option on the upper right hand corner and you be prompted to save a CSV file.


I can tell you, this definitely beats having to manually Google for the correct vSphere configuration maximum document since I can never remember the long URL to the static PDF documents! I am excited to see the improved user experience when consuming our product maximums and I know the team will be working on adding more products and features in the future. Definitely keep an eye on this site and also be sure to update your bookmarks. If you have any feedback or things you would like to see, feel free to leave a comment and I will make sure it reaches the Product and Development teams.

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:

to

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

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

by 9 Comments

I can still remember when I was a VI Admin and how annoying it was to try to correlate the build numbers for my ESX(i) hosts and vCenter Servers that I have deployed with the versions listed on VMware's website. This especially gets challenging when there are multiple patch releases (a, b, c or 01, 02, 03) in between major releases (5.5, 6.0, 6.0u1, 6.0u2, 6.5, etc.). Historically, most customers including myself would retrieve the respective build numbers and then manually comparing them to either the release notes and/or download website which was very tedious.

Although VMware has exposed the version number within our vSphere products since day 1 which can also be retrieved programmatically using the vSphere API (here), it unfortunately does not provide more details than simply the major/minor version (e.g. 5,5, 6.0, 6.5, etc) of the software. Recently, VMware had released a series of VMware KBs which provides a mapping between the build numbers for vCenter Server, ESXi and vSAN to their respective versions which can be found in the links below:

These are definitely a great set of resources that I know many customers including myself have been using since its release. Having said that, the process today is still pretty manual since you need to manually retrieve the build numbers for either a VC, ESXi or vSAN Host (can be automated using vSphere APIs) and then comparing that to the KBs to get the correct versions. How cool would it be if you could *easily* just point to YOUR environment and retrieve the version information for either a vCenter Server (Windows or VCSA), ESXi host(s) or vSAN host(s) without needing to manually perform this lookup each time? Well, I have just done that! I have taken all three KBs and converted that information into a simple PowerCLI script called VCESXivSANBuildVersion.ps1 leveraging our vSphere API and it provides three functions:

  • Get-VCVersion - Retrieves the vCenter Server version given a VC connection
  • Get-ESXiVersion - Retrieves the ESXi version for all hosts given a vSphere Cluster
  • Get-VSANVersion - Retrieves the vSAN version for all hosts given a vSAN Cluster

Here is an example output using the first two functions:


For the vCenter Server version output, you will notice that I am also including the OS platform of your vCenter Server, so you can distinguish between a Windows vCenter Server and a vCenter Server Appliance (VCSA) which can be useful to see if you have been #migrate2vcsa ;). For the ESXi version output, you will notice the "OriginalInstallDate" value, this is actually new API property that was introduced in vSphere 6.5 and it provides you with the original installation date of your ESXi host (more details can be found here) which is pretty neat.

Here is an example output using last function:


If you wanted to take this a step further, you could even take this output and dynamically update the vSphere UI using either Custom Attributes or vSphere Tags so you know what version the software is at any given moment. Its easy enough to set this up as a scheduled task that could run periodically so you always have the latest information provided in the vSphere UIs.

Although this is a significant improvement over the existing manual methods, I think most of you will agree that it would be ideal if this information was natively available within the product which means BOTH UI and APIs. I think we all appreciate versioning of software is not always easy and it can change from release to release for a variety of reasons, most of which may not be technical. If the vSphere platform could dynamically pull this information in either real time and/or through an offline mechanism and provide this association by default, it would greatly improve the experience when needing to troubleshoot or perform maintenance of the vSphere platform. If this is something you would like to see, please leave a comment below providing your feedback. I know I have already pinged our PMs about this and I am sure they would love to hear form you as well!

Additional Information:

Note1: Update levels can be found using the vSphere API, take a look at this article here for more details.

Note2: As of ESXi 6.5 Update 1, the Update levels are also included by default in the Embedded Host Client as shown in the screenshot below:

Note3: As of vSAN 6.2, the vSAN Management API already includes vSAN version information that can be queried. Take a look at this script here which exercises this new API. For example above, I decided to not use this new API since customers may be running older releases of vSAN which is not covered by the vSAN Mgmt API.

Note4: VMware has also published simliar build to version mapping for other VMware products which can find the complete list here.

How to split vCenter Servers configured in an Enhanced Linked Mode (ELM)?

by 12 Comments

An interesting question that came up on the VMTN forum the other day (thanks to Andreas Peetz for sharing via Twitter) was how to split two vCenter Servers configured in an Enhanced Linked Mode (ELM)? Due to an organization changes in the customers environment, they needed to separate out their two vCenter Servers and run them independently of each other. Although this may sound like an rare event, I have actually seen this use case come up several times now which maybe from a business unit restructuring, spinning out or selling off company assets which then requires the customer to split their existing vCenter Servers that is configured with ELM.

Below is a diagram depicting an example where the original source environment (left) which is composed of two vCenter Servers and two external Platform Services Controller (PSC) configured in an ELM and the desired destination environment (right) which are two separate vCenter Server instances no longer configured in ELM.


The solution to this problem is actually pretty straight forward and leverages the existing vCenter Server and/or Platform Services Controller (PSC) "decommission" workflow. Rather than decommissioning the nodes, we are just simply keeping them around. Below are the instructions on how to achieve this outcome.

Disclaimer: Although this solution uses an existing supported workflow, this particular use case has not been tested by VMware. As such, this would not be officially supported by VMware until the appropriate testing has been done by our Engineering teams. One potential option in the short term if you are looking for support from VMware is to file an RPQ request through your VMware account team.

[Read more...] about How to split vCenter Servers configured in an Enhanced Linked Mode (ELM)?