WilliamLam.com

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

12.08.2015 by William Lam // 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.

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.

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.

Automating post-configurations for both PSC & VCSA 6.0u1 using appliancesh

11.23.2015 by William Lam // 4 Comments

In vSphere 6.0, we introduced a new command-line option to allow you to automate both the deployment and upgrade of a vCenter Server Appliance (VCSA) and Platform Services Controller (PSC) using a simple JSON configuration file. This has been a very popular request from customers and one that I have been asking for some time now and was glad to see it was finally made available with the VCSA. One thing that was still missing from an Automation standpoint was being able to some basic post-configurations after the initial deployment. Common operations such as adding additional user accounts, configuring SNMP for monitoring or adding proxy server were available but had to be done interactively and manually.

In vSphere 6.0 Update 1, an enhancement was made to the appliancesh interface which will now allow customers to automate the post-configurations of either a VCSA or PSC by simply re-directing a series of appliancesh commands within a file using SSH. Although SSH may not be ideal for all customers and having a programmatic interface via an API is ultimately where we want to get to; This at least allows customers to automate the end-to-end deployment of both the VCSA and PSC as well as covering any additional post-configurations that might be required to stand up a vSphere environment.

To make use of this feature, you simply create a file that contains the list of appliancesh commands that you wish to run on either the VCSA and/or PSC. Here is an example configuration called psc.config (you can name it anything you want):

access.shell.set --enabled false
access.ssh.set --enabled false
ntp.server.add --servers "0.pool.ntp.org,1.pool.ntp.org"
timesync.set --mode NTP
services.restart --name ntp
proxy.set --protocol https --server proxy.primp-industries.com
localaccounts.user.add --email *protected email* --role operator --fullname 'William Lam' --username lamw --password 'VMware1!'
snmp.set --communities public --targets 192.168.1.160@161/public
snmp.enable

Once you have saved the configuration file, you simply SSH to either your VCSA or PSC and re-direct the configuration file by running the following command:

ssh *protected email* < psc.config

Once authenticated, the series of appliancesh commands will be executed and then you will be automatically logged off as seen in the screenshot below.

If you have any feedback in this particular area, please leave a comment as I know both PM/Engineering are interested in hearing your thoughts and what you might want to see in the future in terms of post-configuration of the VCSA and PSC.

Migrating ESXi to a Distributed Virtual Switch with a single NIC running vCenter Server

11.18.2015 by William Lam // 29 Comments

Earlier this week I needed test something which required a VMware Distributed Virtual Switch (VDS) and this had to be a physical setup, so Nested ESXi was out of the question. I could have used my remote lab, but given what I was testing was a bit "experimental", I prefered using my home lab in the event I need direct console access. At home, I run ESXi on a single Apple Mac Mini and one of the challenges with this and other similar platforms (e.g. Intel NUC) is that they only have a single network interface. As you might have guessed, this is a problem when looking to migrate from a Virtual Standard Switch (VSS) to VDS, as it requires at least two NICS.

Unfortunately, I had no other choice and needed to find a solution. After a couple minutes of searching around the web, I stumbled across this serverfault thread here which provided a partial solution to my problem. In vSphere 5.1, we introduced a new feature which would automatically roll back a network configuration change if it negatively impacted network connectivity to your vCenter Server. This feature could be disabled temporarily by editing the vCenter Server Advanced Setting (config.vpxd.network.rollback) which would allow us to by-pass the single NIC issue, however this does not solve the problem entirely. What ends up happening is that the single pNIC is now associated with the VDS, but the VM portgroups are not migrated and the reason that this is problematic is that the vCenter Server is also running on the ESXi host which it is managing and has now lost network connectivity 🙂

I lost access to my vCenter Server and even though I could connect directly to the ESXi host, I was not able to change the VM Network to the Distributed Virtual Portgroup (DVPG). This is actually an expected behavior and there is an easy work around, let me explain. When you create a DVPG, there are three different bindings: Static, Dynamic, and Ephemeral that can be configured and by default, Static binding is used. Both Static and Dynamic DVPGs can only be managed through vCenter Server and because of this, you can not change the VM network to a non-Ephemeral DVPG and in fact, it is not even listed when connecting to the vSphere C# Client. The simple work around is to create a DVPG using the Ephemeral binding and this will allow you to then change the VM network of your vCenter Server and is the last piece to solving this puzzle.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

Here are the exact steps to take if you wish to migrate an ESXi host with a single NIC from a VSS to VDS and running vCenter Server:

Step 1 - Change the following vCenter Server Advanced Setting config.vpxd.network.rollback to false:

Note: Remember to re-enable this feature once you have completed the migration

Step 2 - Create a new VDS and the associated Portgroups for both your VMkernel interfaces and VM Networks. For the DVPG which will be used for the vCenter Server's VM network, be sure to change the binding to Ephemeral before proceeding with the VDS migration.

Step 3 - Proceed with the normal VDS Migration wizard using the vSphere Web/C# Client and ensure that you perform the correct mappings. Once completed, you should now be able connect directly to the ESXi host using either the vSphere C# Client or ESXi Embedded Host Client to confirm that the VDS migration was successful as seen in the screenshot below.

Note: If you forgot to perform Step 2 (which I initially did), you will need to login to the DCUI of your ESXi host and restore the networking configurations.

Step 4 - The last and final step is to change the VM network for your vCenter Server. In my case, I am using the VCSA and due to a bug I found in the Embedded Host Client, you will need to use the vSphere C# Client to perform this change if you are running VCSA 6.x. If you are running Windows VC or VCSA 5.x, then you can use the Embedded Host Client to modify the VM network to use the new DVPG.

Once you have completed the VM reconfiguration you should now be able to login to your vCenter Server which is now connected to a DVPG running on a VDS which is backed by a single NIC on your ESXi host 😀

There is probably no good use case for this outside of home labs, but I was happy that I found a solution and hopefully this might come in handy for others who might be in a similar situation and would like to use and learn more about VMware VDS.