WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Standalone VMRC (VM Remote Console) re-introduced in vSphere 5.5 Update 2b

10.10.2014 by William Lam // 53 Comments

The VMRC (VM Remote Console) has gone through several transitions from initially being available as a standalone Windows application to an integrated browser based plugin with the release of the vSphere Web Client. In the latest vSphere 5.5 Update 2b release, a new standalone VMRC has been re-introduced to provide an alternative way to launch a VM console. The reason for this is due to the deprecated and eventual removal of NPAPI (Netscape Plugin Application Programming Interface) based plugin support from all modern web browsers which the current VMRC implementation leverages. Here is a quick excerpt from the vSphere 5.5 Update 2b release notes:

Inability to open virtual machine console using Google Chrome browser when NPAPI support is deprecated
When the NPAPI support in Google Chrome is deprecated, the virtual machine console provided in the vSphere Client Integration Plugin might no longer function when the Chrome browser is updated. As a result, you might be unable to open the virtual machine console using the Google Chrome browser and you might not be able to connect to devices.

UPDATE (10/21/14) - Looks like the standalone VMRC has just been made available and you can now download it by either following the link in the vSphere Web Client if you are on vSphere 5.5 Update 2b OR simply by going to http://www.vmware.com/go/download-vmrc

UPDATE (10/12/14) - It looks like the standalone VMRC is currently not available for download just yet. You can continue using the existing methods to connect to your VM Console, the new Standalone VMRC is NOT required but the links have been put in place to proactively get ready for NPAPI deprecation (more details below). You can subscribe to VMware KB 2091284 which will be updated when the download is available.

UPDATE (05/31/15) - If you are connecting directly to an ESXi host you can either use the vSphere API to query for the VM MoRef ID or you can easily pull it by running the following command directly in the ESXi Shell:

vim-cmd vmsvc/getallvms

The deprecation of NPAPI support is nothing new and has actually been communicated by all major web browsers for quite some time now. To ensure that VMware customers are not affected when this change goes into effect, a new standalone VMRC is being introduced to preempt the upcoming change and provides a new way of  launching a VM console using the vSphere Web Client as seen in the screenshot below.

vmrc
To be able to open a VM Console using the new standalone VMRC, you will of course need to have it installed first. You can find the link to the download on VMware.com but there is also a direct link provided on the VM Summary page in the vSphere Web Client. In addition to the new standalone VMRC, you will still be able to use the existing method as well as the HTML5 based VM console. The HTML5 console continues to work if you do not have CIP (Client Integration Package) installed on your Windows system or if you are running on a Mac OS X system. I am sure many of you are probably asking when will there be Mac OS X version of VMRC? I know I definitely am 🙂 The good news is that this is being worked on and hopefully we will see a Mac OS X version in the very near future.

Furthermore, the new standalone VMRC also includes some nice enhancements that I know some of you have been asking for, especially those that have used the previous standalone VMRC application. The new VMRC can now be directly launched using the following two URI methods:

vmrc://[USERNAME]@[VC]/?moid=[VM-MOREF-ID]
vmrc://clone:[VC-TICKET]@[VC]/?moid=[VM-MOREF-ID]

Here is a screenshot of the standalone VMRC application:

vmrc-0
The first method accepts basic authentication using username/password, the vCenter Server address and the VM MoRef Id. Here is an example of what that would look like:

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://*protected email*/?moid=vm-37

The second method accepts a vCenter Server session ticket which you can generate by using vSphere API acquireCloneTicket() method. A quick way to test this example is by using the vSphere MOB and making a call to acquireCloneTicket using the following URL https://[VCENTER-SERVER]/mob/?moid=SessionManager&method=acquireCloneTicket and then specifying the ticket as seen in the example below.

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://clone:*protected email*/?moid=vm-37

With the new URI handler, you can automatically associate it with the standalone VMRC application which means you can type this into a browser or into a Windows explorer and it will automatically launch VMRC. The other nice thing about the new standalone VMRC is if you would like to reduce the complexity of getting a regular use connected to their desktop, you can easily use the standalone VMRC and dynamically generating a link for your end users to access their VMs without ever exposing them to the underlying vSphere infrastructure. I suspect there will be some really interesting use cases for the new standalone VMRC and the VMRC team will continue to iterate to make it better based on customer feedback.

Categories // Automation, VMRC, vSphere 5.5, vSphere Web Client Tags // HTML5, vm console, vmrc, vSphere

Automate VSAN Observer offline mode configurations

10.09.2014 by William Lam // 1 Comment

I was recently reading two of Rawlinson Rivera's articles (here and here) on configuring the VSAN Observer to be able to run in an "offline mode". The VSAN Observer currently leverages several open source libraries including Javascript, CSS and Font files to render the UI which assumes you have direct internet access to load these library files. In a traditional Enterprise environment, direct Internet access is usually not available and thought it could be provided either through a white list of proxy addresses, but in most cases it is just blocked.

Rawlinson provided a nice writeup on the specific library files that needs to be downloaded, the directory structure that needs to be created and the modifications required for each file. Unfortunately, the process is quite manual and potentially very error prone which usually screams for some Automation 🙂 I figure I could help my buddy Rawlinson out by creating two scripts which would download all the necessary files and the other script which will go ahead and update all the appropriate VSAN Observer files.

The first script is called download_vsan_observer_offline_files.sh which will download the necessary library files and put them in the expected directory structure externallibs{js,css,font} using cURL. This shell script is meant to run on a system which has Internet access and uses cURL to perform the download. If you do not have cURL, you can update the script to use wget instead. At the end of the script, you should see a directory created called externallibs which will need to be SCP'ed to the VCSA running the VSAN Observer (this is a prerequisite to the second script).

Here is an example of running the shell script:
automate-vsan-observer-offline-mode-0
The second script is called update_vsan_observer_offline_files.sh which runs on the VCSA that will be used for the VSAN Observer. This shell scripts expects the externallibs directory to be present before updating the VSAN Observer files and will error out if it does not detect it.

Here is an example of running the shell script:
automate-vsan-observer-offline-mode-1
At this point you are ready to run your VSAN Observer in an "offline mode" as Rawlinson has documented on his blog. Please refer his article for more details on using the VSAN Observer.

One thing I was pleasantly surprise to see in the latest vSphere 5.5 Update 2 release of the VCSA is that VSAN Observer now supports HTTPS as well as authentication when logging into the VSAN Observer UI. This is a very nice update and I recommend you download the latest release of VCSA to benefit from these new features.

Categories // Automation, ESXi, VSAN, vSphere 5.5 Tags // ESXi, VSAN, vsan ob, vSphere 5.5

How to automate VM deployment from large USB keys using ESXi Kickstart?

10.08.2014 by William Lam // 8 Comments

During VMworld US, I had the opportunity to speak with several customers to learn about their VMware environment and some of the challenges they were facing. In some scenarios, I was able to offer a solution or a different way of solving the problem. For others, it was primarily feedback on how we can better improve some of our capabilities/features or specific feature requests they would like to see get added.

One interesting challenge that arose from a class of customers who manages hundreds of remote sites is the ability fully automate the provisioning of an ESXi host as well as set of Virtual Machines as part of the initial deployment. The provisioning is all done through Kickstart (unattended installation of ESXi) and usually from a USB device but it could also be from a custom ISO. One ask that kept coming up was the support for larger USB key support within ESXi so that it could be used to include additional payload.

As some of you may or may not know, ESXi can only access USB devices within the ESXi Shell formatted using the FAT16 filesystem which allows for a maximum file size of 2GB for each partition. However, this limitation is only for the ESXi Shell itself and for the size of the ESXi installation media, this is more than sufficient. If you wish to leverage larger USB keys which has increased significantly in recent years from 32GB, 64GB and even 128GB, you can directly pass that into any guest OS through the USB Arbitrator Service (enabled by default) and there you will be able to consume the entire capacity of the USB device. The challenge is how do you go about bootstrapping ESXi as well as the initial set of Virtual Machines with these limitations and completely automated using an ESXi Kickstart?

Over the years I have seen some really creative solutions to solving this problem and funny enough, right before VMworld I had several folks reach out asking similar questions. I decided to take a look and also build upon some earlier work done by a fellow VMware SE (Tim S) to come up with a completely automated solution that would scale to any size USB device and hopefully make it easy to extend if needed.

For this project, I used a 64GB USB key which I received from the folks over at Micron who I visited in the Solution Exchange during VMworld US (these guys are doing some really awesome stuff with VSAN and an All-Flash array, be sure to check them out).

automate-esxi-kickstart-and-servicevm-usb-3
Here is a diagram of the partition structure for the 64GB USB key which I will explain further:

esxi-usb-partition
The first partition is 2GB using a FAT16 filesystem and this is used to store the actual ESXi media along with an embedded ESXi Kickstart configuration file. You can easily reference a remote Kickstart if you wish, but for simplicity purposes and to support some of the requested use cases from customers, I have embedded it.

The second partition is also 2GB using a FAT16 filesystem and this is used to store a tiny VM which I am calling a "Service VM". This VM needs to be small enough to fit the partition and will be used to read the remainder capacity of the USB device which will be using a more capable filesystem type. I have decided to store a pre-configure vMA appliance which is tarred up to reduce the disk footprint.

The third and final partition will consume the remainder capacity of the USB device, in this case it would be 60GB and using a FAT32 partition which can support up to 2TB for a single volume. This is where additional Virtual Machines would be stored and accessed by the "Service VM".

As you can probably guess, the idea is to install ESXi as you normally would to a local disk or directly onto the USB device in which case an additional partition would be required. As part of the installation, the "Service VM" would be boot strapped as it would be visible within the ESXi Shell and registered and powered on during first bootup. A first boot script could then be included in the guestOS which can receive some details about the ESXi deployment which could be hard coded (not recommended) or dynamically discovered as I have implemented it. The USB device would then be passed directly to this "Service VM" to mount and then it would be able to deploy the remainder Virtual Machines which would be stored in this larger partition.

Here is the complete ESXi Kickstart which implements what has been discussed so far and I have also included a break down of the kickstart below:

vmaccepteula
install --firstdisk --overwritevmfs
rootpw vmware123
reboot

network --bootproto=static --ip=192.168.1.200 --netmask=255.255.255.0 --gateway=192.168.1.1 --hostname=mini.primp-industries.com --nameserver=192.168.1.1 --addvmportgroup=1

%post --interpreter=busybox

# stop USB Arbitrator service to access USB device in ESXi Shell
/etc/init.d/usbarbitrator stop

# copy service VM to local VMFS datastore
cp /vmfs/volumes/SERVICEVM/vMA.tar.gz /vmfs/volumes/datastore1
tar -zvxC /vmfs/volumes/datastore1 -f /vmfs/volumes/datastore1/vMA.tar.gz
rm -f /vmfs/volumes/datastore1/vMA.tar.gz

# add guestinfo property for ESXi IP Address for adv. VM deployment
ESXI_IP=$(localcli network ip interface ipv4 get | grep vmk0 | awk '{print $2}')
echo "guestinfo.esxi_ip = ${ESXI_IP}" >> /vmfs/volumes/datastore1/vMA/vMA.vmx

%firstboot --interpreter=busybox

# Ensure hostd is ready
while ! vim-cmd hostsvc/runtimeinfo; do
sleep 10
done

# enable & start SSH
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh

# enable & start ESXi Shell
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell

# Suppress ESXi Shell warning
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1

# rename datastore1
vim-cmd hostsvc/datastore/rename datastore1 mini-local-datastore-1

# Register VM
vim-cmd solo/registervm /vmfs/volumes/mini-local-datastore-1/vMA/vMA.vmx

# connect USB device via passthrough
USB_DEV_NAME="Alcor Micro Corp"
USB_DEV_BUSID=$(lsusb | grep "${USB_DEV_NAME}" | awk '{print $2}' | cut -c 2)
vim-cmd vmsvc/device.connusbdev 1 "path:${USB_DEV_BUSID}/0/1 version:2"

# power on VM
vim-cmd vmsvc/power.on 1

Line12 - Need to disable the USB Arbitrator Service so the USB device can be seen by ESXi since it is by default made ready to be exposed to a VM. The service will be automatically re-enabled after the installation of ESXi which will allow for the VM to connect to the USB device.

Line15-17 - Copy the "Service VM" from USB device to local VMFS datastore1. In the example, I have pre-configured the vMA appliance tarred up the VMX and its respective VMDK.

Line20-21 - Extract the ESXi IP Address and sets a custom guestInfo property so the "Service VM" knows where to deploy the additional VMs to

Line26-29 - This checks to ensure hostd is up and running before continuing on

Line45 - Register the "Service VM" within ESXi

Line49-50 - Identify the USB device ID which will be required to mount to the "Service VM". You will need to update USB_DEV_NAME based on the USB device you are using

Line51 - Connect the USB Device to "Service VM"

Line54 - Power on the "Service VM"

At this point, you should be able to access the USB device from within the "Service VM". We can easily verify this by running the following command:

sudo fdisk -l

automate-esxi-kickstart-and-servicevm-usb-0
As seen in the screenshot above, we can see our three partitions and third is the one with our FAT32 partition which contains a couple of Virtual Machines that I want to deploy. Of course, this partition can contain anything you wish to store, so the sky is the limit!

To mount the USB device and the specific partition, we will create a temporarily directory and issue the mount command by running these two commands:

sudo mkdir -p /mnt/USB;sudo mount /dev/sdb3 /mnt/USB

automate-esxi-kickstart-and-servicevm-usb-1
For my USB key, I have stored both the VCSA and NSX Manager OVA which can then be deployed using ovftool. The last part to be able to make this as seamless and automated as possible is to be able to identify the ESXi host information. If you recall earlier, we had set a custom guestInfo property within our "Service VM". This custom property can then be read by the guestOS leveraging VMware Tools and provides the IP Address to the guest. You can easily set other metadata information but to be able to deploy these additional OVA's, we would need to know the IP Address of the ESXi host and this makes it so you do not need to hard code anything (perhaps ESXi host credentials).

To retrieve this custom property, you will need to run the following command:

vmtoolsd --cmd "info-get guestinfo.esxi_ip"

automate-esxi-kickstart-and-servicevm-usb-2
With these last few guestOS commands, you will be able to create a firstboot script which will automatically mount the appropriate USB partition and deploy these additional Virtual Machines. This is just one of the many possibilities on how you can deploy additional VMs as part of your ESXi Kickstart deployment. Hopefully this solution provides a base in which you can easily customize based on your own requirements.

Categories // Automation, ESXi, vSphere Tags // ESXi, fat16, fat32, kickstart, ks.cfg, sd, usb, vSphere

  • « Previous Page
  • 1
  • …
  • 198
  • 199
  • 200
  • 201
  • 202
  • …
  • 224
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...