I was recently doing some work with my VMware Cloud on AWS instance and I needed to verify something in the vSphere API. Since I already had a browser open, rather than context switch, I decided to quickly open up the vSphere MOB which is a debugging tool that provides a browser interface to the vSphere SOAP API. While going through the Virtual Machine view, I was pleasantly surprised to see a new VM config property called createDate which looks to give you the original date/time of when the VM was first created!
This is probably one of the most frequently asked question that I have seen from VI Admins around basic VM management and I am sure everyone has probably had a need to pull this type of information at least once in their career. Historically, VM creation date was not an easy thing to thing to find and success of retrieving that data was dependent on the retention of your vCenter Server Events database since that is where the information is stored. This means if you only retain 6 months worth of historical events, you will not be able to retrieve creation dates for VMs that were created prior to that.
Several weeks back I was chatting with a few of our Engineers from the Core Platform Team (vSphere) and they had shared an interesting tidbit which I thought I was worth mentioning to my readers. When creating a Virtual Machine in either vSphere or Fusion/Workstation, customers have the option to override the default and specify the specific Firmware boot option whether that is BIOS or UEFI.
Like most customers, I do not even bother touching this setting and I just assume the system defaults are sufficient. Interestingly, for Microsoft Windows 10 and Windows Server 2016, there are some important implications to be aware of on whether BIOS or UEFI is used. This is especially important since the default firmware type in vSphere for these OSes are BIOS.
On Saturday, I started to notice that logins to the vSphere Web (Flex) Client stopped working with Google Chrome. Upon a successful logon, it would immediately crash with "Shockwave Flash has crashed" message. I had seen this message plenty of times in the past and usually restarting Chrome would resolve the problem but this time it looked to be persistent even after a system reboot.
I took to Twitter to see if I was the only one hitting this issue since I was not able to find anything on the web and literally in minutes, I had several dozen replies with folks experiencing the same issue which apparently started several days ago but like most, including myself, thought it was an isolated event.
I thought it was just me, but apparently other folks reporting Flash crashing immediately w/Flash Web Client on latest Chrome. Anyone else? pic.twitter.com/8RWbyPGLG4
After a bit of back/fourth and a few other folks chiming in, it looks like Google actually went and published a newer version of Flash (27.0.0.170) with latest Chrome (61.0.3163.100) update. This newer Flash version is not even available for download and the current version as listed on Adobe's website should be 27.0.0.159. This issue not only affects VMware products that uses Flash but any website that has Flash content and I had also noticed few others sharing frustrations on Twitter for other flash-based websites.
Luckily, one workaround that I had found which others have also confirmed is to switch to Firefox which currently does not have this issue Its also been reported that latest updates from Firefox is also distributing the latest Flash which causes the exact same issue. Like most, Chrome is my default browser and it was annoying that I had to switch to another browser but that was the only way I could access the content I needed. Earlier this evening, I was looking at the VMware Reddit Channel and noticed a thread had popped up regarding this exact issue and it looks like more and more folks are now noticing.
Provisioning a new SDDC on VMware Cloud on AWS (VMC) is not an operation that I perform on a regular basis. Usually, one of the first tasks after a new SDDC deployment is setting up a VPN connection between your on-premises datacenter and your VMC environment. Given this is not a frequent activity, I always forget the specific configurations required for my particular VPN solution and figure I would document this for myself in the future as well as anyone else who might also have a simliar setup.
Since the VMC Gateways are just NSX-v Edges, any VPN solution that supports the NSX-v configurations will also work with VMC. In my environment, I am using pfSense which is a popular and free security Virtual Appliance that many folks run in their VMware home lab. Before getting started, it is also important to note that there are two gateway endpoints that you can setup separate VPN connections to. The first is the Management Gateway which provides access to the management infrastructure such vCenter Server, NSX and ESXi hosts and the second is the Compute Gateway which provide access to the VM workloads running within VMC. Since the instructions are exactly the same for setting up the VPN for either gateways, I am just going over the Management Gateway configuration and where applicable, I will note the minor differences.
Step 1 - Login to the VMC Portal (vmc.vmware.com) and select one of your deployed SDDCs. Click on the Network tab and you should be taken to a page like the one shown in the screenshot below. Here is where you will be applying your VPN configuration from the VMC side. Start off by making a note of the public IP Address for the Management Gateway (highlighted in yellow), this will needed when configuring the VPN configuration on the on-prem side. It is probably a good idea to also note down the Compute Gateway IP Address if you plan on configuring that as well.
I had a question the other day on whether it was possible to enable shell access for Active Directory users when logging into the vCenter Server Appliance (VCSA) via SSH? The answer is yes and though this is documented here, it is not very clear whether this is only applicable to SSO-based users only. In any case, the process to enable this is pretty straight forward and simply requires two steps which I have outlined below.
Step 0 - Ensure that your VCSA and/or PSC is joined to Active Directory before proceeding to the next step. If not, take a look at the documentation here for more details.
Step 1 - Login to vSphere Web Client and under Administration->System Configuration->Nodes->Manage->Settings->Access, go ahead and enable boh SSH and bash shell options. The first setting turns on SSH to the VCSA and the second setting allows users (local, SSO and AD) to access the shell on the VCSA.
Step 2 - In the vSphere Web Client and under Administration->Single Sign-On->Users and Groups->Groups, select the SystemConfiguration.BaseShellAdministrators group and add either an AD User and/or Group that you wish to allow to access the shell.
Once you have completed the steps above, you can now SSH to your VCSA/PSC using the AD user (UPN format) that you had authorized earlier. In the example below, I am logging into one of my VCSA using user primp@primp-industries.com and as you can see, I am placed into the appliance shell by default.
At this point I can access all the appliancesh commands just like I normally would if I had logged as a root or administrator@vsphere.local.
If we wish to change to bash shell, we simply just type "shell" which will enable shell access, assuming you had performed Step 2.
One thing that I noticed is that the default home directory for the AD user is /var/lib/nobody and apparently that does not exists by default, so users end up in / directory by default after enabling shell access. I am not sure if this is also related, but the username shows up as nobody as you can see from the prompt. This is something I will share with Engineering to see if we can improve upon as I am sure most of you would rather see the user that is actually logged in.
The good news from an auditing and logging standpoint is that for operations that are logged, it does properly show the username even though the prompt is showing up as nobody.
