virtuallyGhetto

HTML5

Five of my favorite enhancements in vSphere 7

by 2 Comments

It is very easy to focus on the speeds and feeds of a new major vSphere release such as vSphere 7 which also includes a TON of new and exciting capabilities. However, often times it is the tiny improvements that has the most significant impact to our end users, especially when it comes to usability and operations. In fact, this was further reinforced by Frank Denneman's post on the Reddit with similiar observations.

I have been using vSphere 7 since it was released back in April and I have been discovering a number of new vSphere UI enhancements that has really delighted my overall user experience. I had been sharing these enhancements on Twitter, but figured it was worth a blog post given most of these features were not well known.

Do you have a favorite new feature in vSphere 7 that might not be well known? If so, share by leaving a comment below.

1. Enhanced VM Summary

2. Update and Patch Notifications

3. ESXi Firmware and Driver View

4. ESXi Installation Date + Software Package Details

5. Terminate "stuck" VM

Here are two additional non-UI features that I came to learn about in vSphere 7 that you might also be interested in: Support for HTTPS using wget on ESXi and Guest Customization support for Instant Clones.

vYetti – Fun animated vSphere Login UI customization

by 10 Comments

For those that have been asking about how to customize the vSphere Client Login UI to include this fun little animated login screen as shown below, you can find the complete instructions on my github repo: https://github.com/lamw/vyetti-vsphere-client-customization

I wanted to take a moment and give thanks and credit to the original author (Darin S) who created the animated login, which he referred to as an "Animated SVG Avatar". I remember seeing this on my Twitter stream a few months back where it was shared on codepen.io, which is a platform for web developers to easily show off their demos. From what I could gather, the original demo had used MorphSVGPlugin.min.js which is a Javascript library that provided the animation. Apparently, the use of this library required a membership which prevented anyone from consuming this outside of codepen.io for demo purposes. While searching online, I accidentally stumbled across another similiar project by Balram Chavan who developed an alternative solution simply using Angular 5. With Balram's solution, I was able to make the necessary minor modifications (thanks to Jeeyun from the Clairty team on helping me with some of my Anuglar questions) to get this fully incorporated into the vSphere Client UI. I am sure there are other improvements that can be made to the customization such as a more "clarity" look/feel as the old the old "blue marge" theme background is pretty dated but I will leave that to someone more creative than me 🙂

Changing “Password will expire in X days” notification for Active Directory users in vSphere Web/H5 Client

by 1 Comment

When logging into the vCenter Server using either the vSphere Web (Flex) or H5 Client, one of the validation checks that is automatically performed by the server is to check the current users password expiry. If you account expiry is less than the current password expiry configuration, then you will see the yellow notification pop up at the top stating:

Password will expire in X days

This is definitely a helpful feature to have automatically built into the vSphere UI and the default expiry actually depends on the type of user logging into the system. This last part is sometimes confusing as folks mix up the default Single Sign-On User Expiry with the Active Directory user expiry which is completely different.

Single Sign-On Users

For SSO Domain (vsphere.local by default) users, the password expiry AND notification by default is 90 days. This can be configured in the vSphere Web Client under Administration->Single Sign-On->Configuration->Password Policy as shown in the screenshot below. For those wanting to automate this configuration, there is currently not an SSO Admin API, but there are some options, have a look at this blog post here.

Active Directory Users

If you are logging in as an Active Directory user, the password expiry notification by default is 30 days but the actual password expiry will obviously depend on your Active Directory system. If you want to change the expiry notification in case your expiry is not 30 days or you wish to notify sooner or later, this is actually controlled by the vSphere Web and H5 Client.

[Read more...] about Changing “Password will expire in X days” notification for Active Directory users in vSphere Web/H5 Client

How to audit vSphere Standalone VMRC or HTML5 VMRC connections?

by Leave a Comment

An interesting question that came in last week from one of our TAMs was how to identify and audit Virtual Machine Remote Console (VMRC) logins from vSphere? The TAM was specifically interested in being able to correlate that a particular user had logged into the VMRC of a VM during a specific period of time. Luckily, this is easily retrievable through vCenter Servers's Event sub-system that stores information about everything that happens in your vSphere environment. The Events can be accessed using either the vSphere Web Client shown below or programmatically using the vSphere API which the UI is built on top of.

audit-standalone-vmrc-and-html5-vmrc-logins-1
You can obviously filter your search in the UI and focus on a particular VM, but often times there can be dozens if not hundreds of "Events" generated for a given VM. I personally prefer to leverage Automation when needing to look for a specific type of Event and more importantly, you can further process the results to either send out reports or hook into other third party systems. Now that we know, "where" to find our data, the next thing is identifying the type of Event that is generated for a VMRC connection.

As of vSphere 5.5 Update 2b, the VMRC in the vSphere Web Client can be accessed in one of two ways: The new HTML5 VMRC by clicking onto the VM screenshot thumbnail or the Standalone VMRC by clicking on the link directly beneath the VM screenshot.

audit-standalone-vmrc-and-html5-vmrc-logins-0
Each VMRC connection method will generate a unique vCenter Server Event. For HTML5 VMRC connections, the Event is called VmAcquiredMksTicketEvent and for Standalone VMRC connections, the Event is called VmAcquiredTicketEvent. As I mentioned earlier, the vCenter Server Event sub-system can be accessed using the vSphere API and you can find the complete list of Events documented here. To demonstrate the use of this particular vSphere API, below is a PowerCLI example using the Get-VIEvent cmdlet. My fellow colleague Alan Renouf has actually blogged about working with Events using PowerCLI which I will be adapting one of his examples for our use case.

We first retrieve the VM that we are interested in by running the following command (specify the name of your VM):

$vm = Get-VM -Name "VCSA-60u2"

To retrieve HTML5 VMRC connections, run the following PowerCLI command:

Get-VIEvent -Entity $vm | Where { $_.Gettype().Name -eq "VmAcquiredMksTicketEvent"} | Select CreatedTime, UserName, FullFormattedMessage | ft -wrap -AutoSize

Here is an example of what the output would look like

audit-standalone-vmrc-and-html5-vmrc-logins-2
To retrieve Standalone VMRC connections, run the following PowerCLI command:

Get-VIEvent -Entity $vm | Where { $_.Gettype().Name -eq "VmAcquiredTicketEvent"} | Select CreatedTime, UserName, UserAgent, FullFormattedMessage | ft -wrap -AutoSize

Here is an example of what the output would look like:

audit-standalone-vmrc-and-html5-vmrc-logins-3

How to bootstrap the VCSA using the ESXi Embedded Host Client?

by 5 Comments

In the past, I have written about various ways of "bootstrapping" vCenter Server (here and here) which can be useful for setting up greenfield vSphere deployments. This topic has always been of interest to me because it can be the most challenging to solve, especially when you only start out with a single ESXi host. Historically, these "bootstrapping" options have mostly been driven from a CLI standpoint which is not a bad thing when you think about it from an Automation standpoint and needing to replicate this a few dozen times. However, from a user experience point of view, it may not be as ideal, especially if this is an infrequent task. One of the other cool features of the ESXi Embedded Host Client (EHC) which recently had its v4 release is that it can be used to deploy Virtual Appliances stored in the OVF format.

OVF deployment had been around since v2 of EHC if I recall correctly, but it did not support all the different types of OVF capabilities such as Deployment Option as one example until most recently. One of the difficulties with OVF support on ESXi is not just supporting the ability to import/export but it is also supporting the full OVF specification which ESXi does not currently support today. This means, to provide full OVF support through EHC, it would have to implement a similar capability to what ovftool does today with the --injectOvfEnv option. Luckily, this was something that was added very early on based on my feedback which in my opinion is critical when it comes to greenfield deployments and one of the core use cases that I see for EHC.

Without further ado, below are the instructions on how to bootstrap the vCenter Server Appliance (VCSA) using the Embedded Host Client.

Step 1 - Download the VCSA OVA and then convert it to an OVF using either 7zip or ovftool. The reason you need to convert it to an OVF is that there is currently a known issue when trying to extract larger OVAs within the EHC. By doing this, you also speed up the time it takes to perform the upload and not have to wait for UI to extract it into the actual consumable format which is the OVF and VMDKs.

Step 2 - Click on the "Create/Register VM" option and then choose "Deploy a virtual machine from an OVF or OVA file" option. You will need to specify the name for your VCSA along with the OVF and the 3 VMDKs that is included if you are using vSphere 6.0/6.0 Update 1.

deploy-vcsa-using-embedded-host-client-1
Step 3 - Next you will configure the VM Network and the disk provisioning option. You will also be asked to select the "Deployment Type" which is an option in vSphere 6.0/6.0 Update 1 that allows you to specify whether you are deploying an Embedded VCSA, External vCenter Server or External Platform Services Controller (PSC). You may notice the drop down includes duplicate entries and the reason for this is how the VCSA OVA was built which re-uses the same description in each of the labels but they actually have different meanings. Below is a quick table of the correct mappings to the current ordering parsed by EHC to the different VCSA Deployment Types:

Label Actual Deployment Type
Tiny (up to 10 hosts 100 VMs) Embedded VCSA Node
Small (up to 100 hosts 1K VMs) Embedded VCSA Node
Medium (up to 400 hosts 4K VMs) Embedded VCSA Node
Large (up to 1K hosts 10K VMs) Embedded VCSA Node
Tiny (up to 10 hosts 100 VMs) External vCenter Server Node
Small (up to 100 hosts 1K VMs) External vCenter Server Node
Medium (up to 400 hosts 4K VMs) External vCenter Server Node
Large (up to 1K hosts 10K VMs) External vCenter Server Node

deploy-vcsa-using-embedded-host-client-2
Step 4 - You will need to fill out the OVF properties which are required to properly configure the VCSA. The following 3 sections are the ONLY ones you need to modify for install:

  • Networking Configuration
  • SSO Configuration
  • System Configuration

Step 4a - The Networking Configuration section will require you to specify the following:

  • Host Network IP Address Family - ipv4 or ipv6
  • Host Network Mode - static or dhcp
  • Host Network IP Address - IP Address of the VCSA
  • Host Network Prefix - This is the CIDR notation of the network you plan to place the VCSA on. Example would be /24 (255.255.255.0) which you need to specify as just 24
  • Host Network Default Gateway - Gateway to use
  • Host Network DNS Servers - DNS Server to use
  • Host Network Identity (optional) - This is the FQDN of the VCSA. If you are in a DHCP enabled environment, you can leave this blank which it will automatically default to localhost.localdomain

deploy-vcsa-using-embedded-host-client-3
Step 4b - The SSO Configuration section will require you to specify the following:

  • Directory Password - SSO Admin password
  • Directory Password confirm - SSO Admin password
  • Directory Domain Name - SSO Domain (select vsphere.local if you want the default which I would recommend)
  • Site Name - SSO Site Name
  • New Identity Domain - This is required if it is a new setup and you are not setting up SSO replication with an existing PSC

deploy-vcsa-using-embedded-host-client-4
Step 4c - The System Configuration section will require you to specify the following:

  • Root Password - The root password for the OS
  • Root Password confirm - The root password for the OS
  • SSH Enabled (option) - If you wish for SSH to be enabled after deployment
  • Tools-based Time Sync Enabled - If you do not have an NTP server, you should select this option
  • NTP Servers (optional) - Specify a valid NTP server that you wish to use

deploy-vcsa-using-embedded-host-client-5
Step 5 - You will have the ability to review your configurations before starting the deployment. You should double check to ensure that all OVF properties are correct, else you may get a failed deployment.

deploy-vcsa-using-embedded-host-client-6
Step 6 - Once you are ready, go ahead and click the "Finish" button. This will start the OVF import which you can monitor using the Recent Tasks pane. As part of the OVF/OVA workflow, once the import has completed, it will automatically power on the VM for you. Please do NOT interrupt this process as EHC will be injecting the OVF properties you had specified earlier to the VM to ensure the VCSA will be properly configured.

deploy-vcsa-using-embedded-host-client-7
Once the VM has been powered on, you can then click into the VM Console to view the status of the deployment and hopefully in a couple of minutes, you will have a fully configured and functional VCSA ready for use!

deploy-vcsa-using-embedded-host-client-8
Although EHC today has implemented a pretty generic OVF/OVA interface in the UI to support almost any OVF/OVA, you can see how this could be further improved specifically for the VCSA deployments from a user experience perspective. Who knows, this might get even easier in the future 🙂

How to restrict access to both the Standalone VMRC & HTML5 VM Console?

by 10 Comments

Several weeks back there were a couple of questions from our field asking about locking down access to a Virtual Machine's Console which includes both the new Standalone VMRC (Windows & Mac OS X) which runs on your desktop as well as the new HTML5 VM Console which runs in the browser. Below is a screenshot of the vSphere Web Client showing how to access the two different types of VM Consoles.

restricting-vmrc-and-html5-vm-console-access-1
To prevent users from accessing either of the VM Consoles which also applies to the vSphere C# Client, you can leverage vSphere's extensive Role Based Access Control (RBAC) system. The specific privilege that governs whether a user can access the VM Console is under VirtualMachine->Interaction->Console interaction as seen in the screenshot below.

restricting-vmrc-and-html5-vm-console-access-0
If a user is not granted the following privilege for a particular VM, when they click on either the Standalone VMRC link or the HTML5 VM Console, they will get permission denied and the screen will be blank. Pretty simple if you want to prevent users from accessing the VM Console or allowing only VM Console access when they login.

restricting-vmrc-and-html5-vm-console-access-2

UPDATE (01/31/17): If you are using VMRC 8.1 or greater, you no longer need the additional permission assignment on the ESXi level if you ONLY want to provide VM Console access, just assign it to the VM. However, if you need to provide device management such as mounting an ISO on the client side, then you will still need to assign VMRC role (along with the required privileges for device management) at the ESXi host level.

UPDATE (12/15/15): If you want to restrict users from having ONLY VM Console access which may include the Standalone VMRC, you will need to ensure that the user has the role applied not only on the VMs you wish to restrict but also at the ESXi host level since Standalone VMRC still requires access to ESXi host. You do not need to grant read-only permissions for the user at the ESXi level, but you just need to assign the user "VMRC" only role at the ESXi level or higher to ensure they can connect to the VMRC.