Running Docker inside of VCSA 6.7

During this years VMware {code} Hackathon at VMworld Vegas I submitted a team project which ran PowerShell within the vSphere Client.  To achieve this I had to create a Docker container running PowerShell Core.  During development I ran the container on an Ubuntu Linux server.  For my final submission at the Hackathon I wanted to minimise the dependency to run a separate Linux VM.  So I created a process to install and run Docker directly on VCSA 6.7.

The process to install and run Docker within VCSA 6.7 is surprisingly very simple.  As a reference I used a blog post from William Lam but with a small modification to correctly load the Bridge module in VCSA 6.7 (as opposed to VCSA 6.5 in William’s post).

I thought I would share the steps I used below for others to experiment with.

Step 1.
SSH to the VCSA VM and enter the Shell

Install the docker package

tdnf -y install docker

Step 2.
Load the kernel module to start the Docker client. (This step needs to be re-run if the VCSA is rebooted)

modprobe bridge --ignore-install

If successful no information should be returned.

You can check if the module is installed by running the following

lsmod | grep bridge

[email protected] [ ~ ]# lsmod | grep bridge
bridge                118784  0
stp                    16384  1 bridge
llc                    16384  2 stp,bridge

Step 3.
Enable and start the Docker Client
systemctl enable docker

systemctl start docker


Making the Bridge module load after a reboot (Optonal)

As with William’s process to install and run Docker Step 2 needs to be re-run each time the VCSA is rebooted.  The solution to make the Bridge module automatically load after a reboot happens to be exactly the same.  I’ve included the specific commands to simplify the process.

Step 1.
Make a backup of the file we are going to modify.

cp /etc/modprobe.d/modprobe.conf /etc/modprobe.d/modprobe.conf.bak

Step 2.
Comment out the line that disables the Bridge module from loading

sed -i "s/install bridge/# install bridge/g" /etc/modprobe.d/modprobe.conf

Step 3.
Create a new config file to load the Bridge module

touch /etc/modules-load.d/bridge.conf

Step 4.
Specify the name of the Bridge module to load at reboot

echo bridge >> /etc/modules-load.d/bridge.conf

That’s all we need to do to start running containers on VCSA 6.7.  Excluding the steps to have the Bridge module persist after a reboot and it’s even simpler.


Running a Docker container

If you want to test your first container on VCSA you can try my Docker image I build for the Hackathon.  The steps are very simple and listed out below.

Step 1.
Download the two required files from my GitHub repo

curl -O

curl -O

Step 2.
Build the Image

docker build -t vsphere-powercli .

Step 3.
Start the container with this image

docker run -d -p 4200:4200 --name vsphere-powercli vsphere-powercli

You can check if the docker container is running with the below command.

docker stats

You can check if the port has been mapped correctly by running

docker port vsphere-powercli

Step 4.
Open a web browser and test if you can connect directly to the container through the browser and login to the PowerShell prompt.


Accept any certificate warning and login with the default credentials of powercli / password

I hope that was all fairly straight forward  to understand.  It’s actually all very simple to achieve under VCSA 6.7.  As in William’s post, none of this is supported by VMware, so user beware.  Though I have been playing with Docker inside of VCSA 6.7 for quite a few months now with no noticeable issues.

If you want to see my full VMworld Hackathon project you can check it out over in my GitHub repo

VMware {code} Hackathon – VMworld Vegas 2018

It was a tough decision.  Hit up the Cohesity party and watch Snoop Dogg perform or participate in the VMware Code Hackathon.  No, the decision was easy, I was always going to take part in the Hackathon.  I had regretted not taking part last year and I was super keen for this year’s hackathon, I wasn’t going to miss it.  I think it’s safe to assume I chose wisely.  With my team, Team vMafia, coming away with the winning project and an impromptu segment on Virtually Speaking!

Left to right: Anthony Spiteri, Matt Allllford, Mark Ukotic, and Tim Carman

This year’s Hackathon broke from the format from previous years.  Whereas in previous year you showed up, attempted to form a team and an idea, then execute all within a handful of hours.  This year the Hackathon chose to leverage HackerEarth and give participates three weeks to create a team and build out a hackathon idea.  Without a doubt this was the single biggest improvement to the format of this years event.  Leading to some great projects being built.

Rewind a month, In the week leading up the Hackathon I started thinking about an idea I could submit.  Struggling to think of something I started playing a bit of buzzword bingo.  PowerShell and PowerCLI were big passions of mine.  Docker was an area I wanted to explore more into and I had wanted to learn more about what the vSphere SDK could do.  At that point an idea just naturally presented itself.  Could you run a PowerShell console with PowerCLI modules inside the new HTML5 vSphere Client?

At this point I didn’t know I had a good idea, let alone just an idea.  I ran it past some friends within a local Aussie Slack group I’m part of.  It went down extremely well but I still had my doubts.  So I did what anyone would do and went to ‘other’ friends who also thought it was a great idea.  So OK I thought, I have an idea.

Having recently quit my job I was able to focus 100% of my attention to the project.  Great for me and the Hackathon, I guess bad for everyone else with jobs 😛  I formed a team and without any persuasion a number of the Aussie Slack team jumped on-board including Anthony Spiteri, Matt Alffford, and Tim Carman.  We were going to need a lot of help so I reached out to a few friends for assistance.

First up was my ex-manager John Imison for some assistance around Docker.  Installing Docker and running a container is one thing.  But building a container image was something new.  John provided some great advice and ideas around building the docker image.  Actually far too many for a Proof of Concept hackathon idea that I could implement in a practical timeframe.  If this project continues to develop past hackathon expect to see some more of his ideas integrated in.

Next I hit up my Developer brother-in-law Simon Mackinnon.  After spending a couple days crying in front of my computer attempting to build and configure my vSphere SDK environment.  I went to Simon for help in decipher the vSphere Plugins.  Simon helped put us on the right track with finding the easiest solution to embed a console into the vSphere Client.

After a solid week of learning Docker and the vSphere SDK it was time to actually build something and put it all together.  Believe it or not this was actually the easiest part of the whole project.  Once I knew how to build a Docker image it was just a matter of customising it for my purpose.  The same went for the vSphere Plugin.  Take a sample plugin and modify it for purpose.

The night of the Hackathon at VMworld was fairly cruisey for Team vMafia 2.0.  Our project was built.  We performed some final testing to prove it all worked.  We gave some of the judges a walk-through of what we built.  I should point out that the night was extremely well run.  Previous years had some controversy around the event.  None of that existed this year.  Two rounds of hot food was served with lots of drinks and candy lollies to be had.  With WiFi and Internet stable and strong.  The event was pushed back from an original start time of 6:30 to 7:30.  This was due to some of the judges holding training sessions / presentations on some of the hackathon themes.  At 10 PM all the teams were given two minutes to present their ideas and projects in front of a projector.  A completed project was not a requirement to present.  The judges had a number of criteria they were working off for judging, such as how well you kept to your 2 minutes and how well you conveyed your idea.

Team vMafia were one of the last to present.  I was certainly not confident as there was some great ideas before us.  I spoke for our team.  I’m not sure how long I presented for but it was definitely less than the 2 minutes.  During the entire presentation i had Anthony Spiteri whispering in my hear, ‘hurry up, don’t waste time, go go go’.  Distracting, yes, but he did keep me on point.  The judges then left the room to vote.  They came back pretty quickly with it being a unanimous decision that Team vMafia had the winning idea of an integrated PowerShell console inside the H5 vSphere Client.  It was not until they called our name that I thought, ‘Hey, maybe we do have a good idea’.

Screen of vSphere PowerCLI being used within the vSphere Client

The night didn’t quite end there for Team vMafia.  After the event we passed by Eye Candy in Mandalay Bay where we ran into the Virtually Speaking guys, Pete Flecha and Glenn Sizemore.  While Anthony denies it , I think this was his master plan for us to bump into them.  We had some great conversations with the guys and they were super excited for our Hackathon project and win that they invited us onto the podcast the following day.

The episode of Virtually Speaking with Team vMafia can be found here.   While I find it hard to listen to myself I’m assured that the segment was really good and funny.  Our segment also managed to make the cut in the same episode as Micheal Dell and Pat Gelsinger which I have to say is pretty cool.  I huge thank you to Pete and Glenn for allow us to come into the show!

Finally I can’t end without linking to the actually project.  During the development I used my own private repos but have now moved it over to my GitHub page.  The project has the very original name of vSphere PowerCLI.  As far a disclaimers go the project is free to download and use at will.  I’m not really holding any restriction on it.  It was always just a Proof of Concept idea I had.  The instructions are hopefully fairly easy to follow.  Most people have been taking a snapshot of their VCSA and using the option to run Docker on their VCSA.  If the support is there I’ll be considering developing the project past hackathon idea.

Thanks for everyone’s support and kind words and let me know if you’d like to see the project developed further.


Run, Don’t Walk. VMworld 2018

I think the worst part of VMworld has to be the end of VMworld.  There’s nothing like the reality check of a 14 hour flight back home to Melbourne.  As I sit here looking out the window at a cold and dreary Melbourne winter’s day it’s a great opportunity to reflect on another great VMworld.

As with last year I turned VMworld into another working holiday.  If I’m going to sit on a plane for 14 hours I’m sure as hell going to experience as much of the US as I can.  Last year involved a road trip post VMworld driving from Chicago to Toronto lugging all my VMworld swag around with me (very inconvenient let me say).  This year I moved the holiday portion of my trip to the start and drove from New Orleans through Louisiana and around Texas, hitting the major cities along the way to Dallas before flying into Vegas for VMworld.  I absolutely love the States and will take any opportunity to experience new parts of the country.

Love or hate Las Vegas, it’s an amazing place to hold VMworld.  I jokingly titled this post ‘Run, Don’t Walk’.  You see there’s just so much to experience at VMworld you won’t be able to absorb it all in over the 4 to 5 days of the event.  Whether you’re running between sessions.  Visiting vendor booths.  Or hunting down friends.  You’ll inevitably find there’s not enough time.  We love to try to categorise the different types of people who attend VMworld and how they spend their time but I don’t think that’s fair.  Every single person has a different objective.  Ultimately for me, from my point of view, just have fun.  Enjoy the event!  Try to walk away from the event happy and in a positive state of mind.  If you can do that everything else will just fall into place.

For me there was a lot of high points of the event.  The vExpert party at the Pinball Museum.  The Veeam party at Omnia Nightclub.  The VMUG Leader Lunch Q and A with Pat Gelsinger and Ray O’Farrell.  The list kind of goes on…  but the biggest highlight has to be the VMware Code Hackathon.

I entered team vMafia into the Hackathon supported by a number of fellow aussies, Tim Carman, Anthony Spiteri, and Matt Allford.  I have another blog post coming specifically on this event.  But to summarise, the Hackathon ran in lead up to the night’s event over a 3 week period.  The idea I had was to create a PowerShell / PowerCLI console built into the new HTML5 vSphere Client.  To my absolute surprise… we won!  Stay on the lookout for my next post on the Hackathon.

It doesn’t end there.  All the people that you run into and friends you make you will lose track of.  The amount of random Texans I met at VMworld after my road trip through Texas was crazy.  Those guys and gals are everywhere.  An awesome bunch of people from an awesome place.  Not to mention the huge Aussie contingent I met throughout the event.

I finally can’t end without thanking all the vendors who specifically went out of their way to support the vExpert program with some special swag, Cohesity, Datrium, Western Digital, and Uila.  Not to mention Mr vExpert himself Corey Romero.

Thanks VMware for another awesome VMworld!

Getting Started With Ansible And PowerCLI

Continuing on my journey of learning Ansible with a twist of VMware (see my previous post on Getting started with Ansible and VMware).  I’ve started to play around with PowerShell Core and PowerCLI in Ansible.  What I’ve found is that you can do a lot of interesting things with PowerCLI in Ansible, removing the need for a Windows jumphost.

Now I think the magic here is really just using PowerShell Core with Ansible.  However, I wanted to tackle this once again from the VMware admin view point.  So I’m focusing on using Ansible to leverage PowerCLI to connect to vCenter server and to perform some PowerShell / PowerCLI actions, all running from the local Ansible host.

As with my previous post, this is not really an Ansible 101 guide.  Rather the goal here is to show you, the reader, what’s possible with PowerShell Core and PowerCLI using Ansible.  Getting you thinking about how you might leverage this in your environment.

So let’s lay the framework of what we’ll cover below.  I’m going to assume Ansible has already been installed.  I’ll go through the steps to install PowerShell Core onto the Ansible host.  Then install the VMware PowerCLI modules and run some basic Cmdlets.  Finally I’ll cover the more interesting Ansible integration part.

In my lab I’m using Ubuntu.  So everything I’m going to do will be based on this distro.  So let’s get started.

Installing PowerShell

Install PowerShell Core with the following command.  Depending on your Linux distro and version you may have to set an updated MS repo.

sudo apt-get install -y powershell

Next sudo into PowerShell.  We use sudo because the next few commands we run in PowerShell will need elevated privileges.

sudo pwsh

Install the VMware PowerCLI modules with the first command below.  Then change your PowerCLI settings to ignore self signed certificates.  If you have signed certs you can skip this step but most of us probably don’t.

PS /home/mukotic/> Install-Module vmware.powercli

PS /home/mukotic/> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope AllUsers

At this point you can exit out of the PowerShell prompt and come back in without using sudo, or just keep going as is, the choice is yours.  We can now make our first connection to our VCSA host and if successful run a few basic PowerCLI Cmdlets like Get-VMHost.

PS /home/mukotic/> Connect-VIServer {vcsa_server}

PS /home/mukotic/> Get-VMHost

Creating the PowerShell Script

Assuming all is successful up to this point we can now turn the above commands into a PowerShell script called vcsa_test.ps1.  It’s not ideal but for the sake of demonstration purposes I put the username and password details into the script.  I like to pipe the vCenter connection to Out-Null to avoid any stdout data polluting my output results.

Connect-VIServer -Server vc01.ukoticland.local -User {vcsa_user} -Password {vcsa_pass} | Out-Null
$result = Get-VMHost | Select-Object -ExcludeProperty ExtensionData | ConvertTo-Json -Depth 1
$result | Out-File -FilePath vmhost.json

Creating the Ansible Playbook

We can now create an Ansible Playbook that will call our PowerShell script.  Exit out of the PowerShell prompt and using vi, nano, or another editor create a file called vcsa_test.yml and enter the below.  The only real important line is the one with ‘command’.  Remember that spacing is important in the yaml file.

- hosts: localhost

    - name: Run PowerShell Core script
      command: pwsh /home/mukotic/vcsa_test.ps1
      ignore_errors: yes
      changed_when: false
      register: powershell_output

Now try running the Ansible Playbook we just created and check if it runs.

ansible-playbook vcsa_test.yml

Again if all successful the results should look something similar to below.

PLAY [localhost] ****************************************************************************************************************************************************

TASK [Gathering Facts] *******************************************************************************************************************************************
ok: []

TASK [Run PowerShell Core script] ********************************************************************************************************************************
ok: []

PLAY RECAP ******************************************************************************************************************************************************* : ok=2 changed=0 unreachable=0 failed=0

Finally we check if our ouput file created correctly.

cat vmhost.json

“State”: 0,
“ConnectionState”: 0,
“PowerState”: 1,
“VMSwapfileDatastoreId”: null,

“DatastoreIdList”: “Datastore-datastore-780 Datastore-datastore-529 Datastore-datastore-530”

What we covered above are just some of the fundamentals to running a PowerShell Core script on an Ansible host.  There are still a lot of improvements that can be made.  The most obvious is we can move our username and password details out of the main PowerShell script.  We could also take the json output and pass it into the Ansible Playbook to read the values for later use in our plays.  But most importantly we can now start to make advanced configuration changes in vSphere where Ansible modules don’t exist.


Installing PowerShell Core on Linux -- MS

Getting Started With Ansible And VMware

For a little while now I’ve been playing around with Ansible and exploring its VMware modules.  While using Ansible with the VMware modules is not overly complex.  I quickly realised there were very little examples out on the web for the VMware administrator.   So I thought I would put together a very simple crash course on getting starting with Ansible and VMware.

The intention here is not to explain how Ansible works.  There’s a lot of information out on the web around that, plus I’m still learn too.  Instead I just wanted to put together something relatively simple.  Show how to quick and dirty get Ansible installed on a Linux box with the required VMware SDK.  Then create an Ansible playbook to build a basic environment in vCenter.  This will involve a new Datacenter, a Cluster, and a Resource Pool.

So let’s get started.

Installing Ansible

Firstly let’s install Ansible.  Ubuntu and CentOS are common distros so I cover them both below.  With Ubuntu I also add the Ansible repository.  While I don’t believe it’s really required it seems to be what most people do.


sudo apt-add-repository ppa:ansible/ansible

sudo apt-get install ansible


sudo yum install ansible

Once installed we can run a simple verification check to see if the install was successful.

ansible -m ping localhost

localhost | SUCCESS => {
"changed": false,
"failed": false,
"ping": "pong"

Installing pyVmomi

Now we install pyVmomi.  This is VMware’s Python SDK for managing vCenter and ESXi and is required to use the VMware modules that come with Ansible.

sudo pip install pyvmomi

And that’s all that we really need to install to build our first playbook and run it against vCenter.  To run our playbook we’re going to need to create a few folders and files.  The structure will look something similar to below.

├── ansible-vmware
│   ├── group_vars
│   │   └── all.yml
│   └── vmware_create_infra.yml

Let’s create a folder called ansible-vmware and a varibles folder called group_vars below that

mkdir ansible-vmware
mkdir ansible-vmware/group_vars

Now even though this is a crash course to running our first VMware playbook I want to at least do things half right and not have any plaintext passwords.  So before I go too far into creating the yaml files I want to create an encrypted string of our vCenter’s administrator SSO password.  I do that with the following line.

ansible-vault encrypt_string {admin_sso_password} --ask-vault-pass

You’ll be asked for an Ansible vault password and then receive back an encrypted string.  The vault password will be used when we run our play (don’t forget it).  Copy and paste the output and put it aside for a minute.  We’re going to pasta it in our group_vars file that we’re about to now create.

Let’s now create that variables file inside the group_vars folder and call it all.yml

touch ansible-vmware/group_vars/all.yml

Using vi or nano or whatever you prefer to edit the file.  Let’s edit the all.yml file and add in all the variables we will use in our playbook.  Again, crash course, so don’t worry too much about what each one does right this minute.  Just know that we have to reference these values multiple times in our playbook and having a variables yaml file really helps with that.

For the vcenter_password variable use the encrypted string we created in the step above and paste it in so it looks similar to below.  Obviously feel free to change any of the values, datacenter, cluster, etc.

datacenter: ansible_dc1
cluster: ansible_cluster1
resource_pool: ansible_resource1
datastore: datastore01
vcenter_username: administrator
vcenter_password: !vault |

Now we create our main playbook.  This is going to contain all our plays and reference all our variables we just created in global_vars/all.yml

touch ansible-vmware/vmware_create_infra.yml

Like we did with the variables file lets edit this file. Again, vi, nano, whatever.  Copy and past the information below.  Things to note.  Yaml files don’t like tabs.  So spaces only and position is very important.

- hosts: localhost
  connection: local
    - name: include vars
        dir: group_vars

    - name: Create Datacenter in vCenter
        module: vmware_datacenter
        datacenter_name: "{{ datacenter }}"
        hostname: "{{ vcenter_ip}}"
        username: "{{ vcenter_username}}"
        password: "{{ vcenter_password}}"
        validate_certs: False
        state: present

    - name: Create Cluster in datacenter
        module: vmware_cluster
        hostname: "{{ vcenter_ip}}"
        username: "{{ vcenter_username}}"
        password: "{{ vcenter_password}}"
        validate_certs: False
        state: present
        datacenter_name: "{{ datacenter }}"
        cluster_name: "{{ cluster }}"
        enable_ha: yes
        enable_drs: yes

    - name: Create Resource pool in cluster
        hostname: "{{ vcenter_ip }}"
        username: "{{ vcenter_username}}"
        password: "{{ vcenter_password}}"
        validate_certs: False
        state: present
        datacenter: "{{ datacenter }}"
        cluster: "{{ cluster }}"
        resource_pool: "{{ resource_pool }}"

Assuming you created the files correctly and have the right password we are ready to run our first Ansible playbook against vCenter.

ansible-playbook ansible-vmware/vmware_create_infra.yml --ask-vault-pass

This should produce something similar to below

PLAY [localhost] ***************************************************************************************************************************

TASK [Gathering Facts] *********************************************************************************************************************
ok: [localhost]

TASK [include vars] ************************************************************************************************************************
ok: [localhost]

TASK [Create Datacenter in vCenter] ********************************************************************************************************
changed: [localhost -> localhost]

TASK [Create Cluster in datacenter] ********************************************************************************************************
changed: [localhost -> localhost]

TASK [Create Resource pool in cluster] *****************************************************************************************************
changed: [localhost]

PLAY RECAP *********************************************************************************************************************************
localhost : ok=5 changed=3 unreachable=0 failed=0

The resulting output in the vSphere Client should look similar to below.

The cool part is we can run the same command again and again and nothing will change as long as our environment is consistent with our defined yaml files.  They in essence become our working as-built doco.

So the goal from what we’ve just done above was not to actually build an environment but rather to show you how quick and simple we can get Ansible up and running and configuring a vSphere environment.  I’ve avoided a lot of the technical stuff so instead you can think about how this might help you in your environment.

In future posts I might go into more details on specific modules and how to use them but for now I think I might just focus on what’s possible with Ansible and VMware.


Ansible VMware Getting Started

pyVmomi GitHub Page


5 Getting Started PowerShell Core Tips

Now that PowerShell Core 6 has gone GA, it’s a great time to start learning this new version.  So I thought I would put together 5 quick tips and tricks that I’ve used to make using PowerShell Core a little easier for myself while making the transition from Windows PowerShell.

While the intention of this post is not to go into the differences between Windows PowerShell and PowerShell Core.  Despite the slightly mixed or vague messaging we getting from Microsoft on the future of PowerShell.  I think it’s safe to say that PowerShell Core is not a replacement or upgrade for Windows PowerShell but it is the future of PowerShell.  As soon as more and more Modules start supporting PowerShell Core the argument to switch over will become easier.

So while people continue to argue if they should make the switch to PowerShell Core or not here are 5 tips and tricks I have used with PowerShell Core in the meantime.  It’s also worth noting that all of these tips are Windows specific.

Tip 1. Modify your default profile.

I wrote a post on this a little while back on how to modify your default profile in Windows PowerShell here.  I recommend taking a look at it and bring a bit of yourself to PowerShell.  Much of what I discuss in the post is still valid for PowerShell Core.  The only different really is your profile path in PowerShell Core.

You can easily locate your profile in PowerShell Core by typing $Profile at the command profile.  Unless you’ve already modified it, there’s a good chance that the location path doesn’t actually exist on your PC.

In Windows 10 the path is C:\Users\{username}\Documents\PowerShell\Microsoft.PowerShell_profile.ps1.  If it doesn’t exist go ahead and create the folder PowerShell in your Documents folder.  Then create a file called profile.ps1 and modify to your hearts content.  All the steps are laid out in my previous post I mentioned on modifying your Windows PowerShell profile. Without any specific Core modifications I took my already modified profile.ps1 profile from Windows PowerShell and copied it to this location.

Original PowerShell Core console on the left with my modified profile.ps1 profile on the right.

Tip 2. Modify VS Code to use PowerShell Core Integrated Terminal

While I still do like to use the Windows PowerShell ISE with ISE Steroids from time to time.  I’ve for the most part switched to VS Code for most of my day to day use.  If you haven’t yet made the switch I highly recommend downloading it and giving it try.  It’s fast, stable, and uses relatively little memory compared to the PowerShell ISE.

Currently as of VS Code 1.22 you can’t run multiple different Integrated Terminals.  But there’s still a few things we can do here.  We can change our default Integrated Terminal to PowerShell Core.

Open VS Code and navigate to File / Settings.  On the left you have your Default Settings and on the Right you have your User Settings to overwrite the Default Settings.

Enter in the following between the two { }

// PowerShell Core
“”: “C:\\Program Files\\PowerShell\\6.0.0\\pwsh.exe”,

Now when you open up an Integrated Terminal it should default to PowerShell Core (pwsh.exe)

You can download VS Code from

Tip 3. Modify Console Window properties

This one kind of carries on from Tip 1.  More visual customisations on how a terminal session looks and is very much personal preference.  Right click on the top left and pull up the terminal properties.  I drop the Font size down to a non standard size of 13 which fixes what I feel is an overly elongated terminal.  Increase the Layout windows size to 130 x 40 and hard code a different background colour.  Finally I increase the Command History buffer size.

Tip 4. Use Chocolatey to Install and Upgrade PowerShell Core.

Chocolatey is a Windows Package Manager similar to apt-get or yum in the Linux world.  What I love about Chocolatey is that it handles installing and configuring all dependencies you require when installing an application.

Installing Chocolatey is as simple as running a few commands on one line in PowerShell.  Installing / Upgrading Powershell Core is just has simple once Chocolatey is installed.

The below command will install Chocolatey from a Powershell prompt.

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString(‘’))

This next command will install PowerShell Core and any dependencies it needs.  Replace install with upgrade if you have a previous version of PowerShell Core installed.

choco install powershell-core -y

You can download Chocolatey from their website at  and instructions to install PowerShell Core can be found at

Tip 5. Find some modules

PowerShell Core by default uses a different module path to load modules. Meaning that all your Windows PowerShell modules won’t just import and run. This doesn’t mean that they won’t work. PowerShell Core has been designed to be has backwards compatible as possible. While modules like Active Directory won’t work correctly many still do.

By installing the WindowsPSModulePath module from the PowerShell Gallery, you can use Windows PowerShell modules by appending the Windows PowerShell PSModulePath to your PowerShell Core PSModulePath.

First, install the WindowsPSModulePath module from the PowerShell Gallery

Install-Module WindowsPSModulePath -Force

Then run the Add-WindowsPSModulePath cmdlet to add the Windows PowerShell PSModulePath to PowerShell Core:


This will now allow you to now start using all your current Windows PowerShell modules in Core (in your current session).  This is not a guarantee that they will work though.  So test thoroughly.

If you’re after specifically supported PowerShell Core modules you can search for the tag PSEdition_Core in the PowerShell Gallery.


I hope some of the above quick tips help you get started with PowerShell Core and make the transition a little easier.

Change vRealize Network Insight consoleuser Password

The last few posts I’ve written about have revolved around vRealize Network Insight.  In these posts I mention using the consoleuser account and in my case using the default password for this account, which for the record is ark1nc0ns0l3 (shhh, don’t tell anyone).  Clearly not good practice so I thought I would briefly mention the process to change the password for the account.

The steps involved to change the password are fairly straight forward and as the consoleuser account can be logged in via SSH out of the box it’s recommended to be changed.

The below process are applicable to both the Platform and Proxy appliances.

1.  Open a console window or SSH to the Platform and or Proxy appliances (depending on what you deployed).  You can user the consoleuser account here with its default password of ark1nc0ns0l3

2. Type in the following command

modify-password system --user consoleuser

3. Type in a new password, hit enter, and verify that password.

…and that’s it!

As I mentioned above this account can be used with SSH and is enabled out of the box so recommended to be changed once vRNI is deployed.


Configure An HTTP Internet Proxy In vRealize Network Insight

Well, we’re up to vRealize Network Insight 3.7 and still no GUI way of setting an internet proxy.  Usually you would configure an HTTP Internet proxy via the VAMI but that also doesn’t exist for reasons I don’t quite understand???  Never the less the process to configure an HTTP Internet proxy can be performed via the CLI easy enough.  Reasons why we might want to do this, apart from the obvious of gaining internet access where none exist without a proxy, is so we can check for software updates and connect to support.

The command we use is set-web-proxy

(cli) set-web-proxy -h
usage: set-web-proxy [-h] {show,enable,disable} …

set the web http proxy (for Internet access)

positional arguments:
show show current configured http proxy state
enable enable http proxy
disable disable http proxy

optional arguments:
-h, --help show this help message and exit

1. First thing we do is connect up to an interactive console session or SSH into our vRNI boxes with the consoleuser account.  The default password for consoleuser if you haven’t changed it is ark1nc0ns0l3

2. Type in set-web-proxy show

You will see something similar to below.

(cli) set-web-proxy show
Http proxy connection disabled

3. Next we set our HTTP proxy using set-web-proxy enable.  This will stop and start a few services but not cause any disruption the to running of vRNI.  Below is an example with a proxy address and port.

(cli) set-web-proxy enable --ip-fqdn vrni-platform.mydomain.local --port 3128
Stopping services
* Stopping DNS forwarder and DHCP server dnsmasq [ OK ]
nginx stop/waiting
launcher-service stop/waiting
* Starting DNS forwarder and DHCP server dnsmasq [ OK ]
Enabling http proxy connections…
Http proxy connection enabled
Connected to http proxy vrni-platform.mydomain.local:3128
* Stopping DNS forwarder and DHCP server dnsmasq [ OK ]
Starting services
* Starting DNS forwarder and DHCP server dnsmasq [ OK ]
nginx start/running, process 5337
launcher-service start/running, process 5415

4. We run set-web-proxy show again.

(cli) set-web-proxy show
Http proxy connection enabled
Connected to http proxy vrni-platform.mydomain.local:3128

5. Finally we can run show-connectivity-status

A bunch of network information will be returned along with connectivity status of a few URLs.

Upgrade connectivity status ( Passed
Support connectivity status ( Disabled
Registration connectivity status ( Passed

Web Proxy connectivity status: Passed

Over in the settings page of vRNI you should now see some green icons indicating Upgrade Server Reachable.


Offline Upgrade vRealize Network Insight

Earlier this week VMware release the latest update to vRealize Network Insight, version 3.7.  If you jumped on this new update as I did you might have been caught out by a bad build (  Upgrading to this version had a DNS issue that caused a communication issue between the Platform appliance and the Proxy appliance.  The version was quickly pulled and replaced a day later with a new and working build,  It’s unlikely that you will have this old build but before upgrading it’s best to check.

vRNI can be updated in two ways.  An Online upgrade via the GUI and an Offline upgrade via the CLI.  There are a few reasons why you might want to perform an Offline upgrade.  Cluster upgrades can only be performed via an Offline upgrade.  Your vRNI appliance might not have internet access.  Or like me you have configured a proxy server on your vRNI appliances but because vRNI wants to make your life difficult it doesn’t detect new updates.

The Offline upgrade can only be performed on version 3.5 or 3.6 and is very similar to previous upgrades.

1. Download the ZIP bundle from VMware.

2. Snapshot both your Platform and Proxy appliances or live life like a cowboy.

3. Copy (SCP) the ZIP bundle to both appliances (Platform & Proxy).

I had difficulties using WinSCP due to the limited console access given by the appliance so I used pscp.exe that comes with the Putty package.  The location to where you can copy the bundle to can also be a bit of a challenge.  I chose /home/consoleuser/downloads/ using user consoleuser.

Below is the command I ran from a PowerShell prompt from my Windows box.

PS C:\Program Files (x86)\PuTTY> .\pscp.exe -scp E:\temp\VMware-vRealize-Network-Insight. [email protected]:~/home/consoleuser/downloads/

4. SSH over to the Platform appliance with the user account consoleuser which has to be upgraded first. The default password for consoleuser in vRNI is ark1nc0ns0l3

5. Run the package-installer command to upgrade the appliance.

Below is an example of the command I ran.

package-installer upgrade --name /home/consoleuser/downloads/VMware-vRealize-Network-Insight.

The upgrade process can take a while so be patient.  A successful upgrade should look similar to below.

login as: consoleuser
[email protected]’s password:
vRealize Network Insight Command Line Interface
(cli) package-installer upgrade --name /home/consoleuser/downloads/VMware-vRealize-Network-Insight.
Do you want to continue with upgrade? (y/n) y
It will take some time…
Successfully upgraded

6. SSH over to the Proxy appliance now with the same user account consoleuser.

7. Run the same command as on the Platform appliance.

package-installer upgrade --name /home/consoleuser/downloads/VMware-vRealize-Network-Insight.

As with the Platform upgrade it will take some time and the output after the upgrade should look the same

8. (Optional) Run show-version and confirm you are running the latest version build on each appliance.

That’s all there is to it.  Stopping and Starting services aren’t necessary.  As with no need to reboot appliances.

You can now open up a web browser and login to your upgraded vRNI platform appliance. Check that everything looks over in settings.


Melbourne VMUG 2017 Recap

Last week the Melbourne VMware User Group held its final vBeers event of the year, closing out another massive year for the group.  It’s been a lot of hard work to bring the group to the end of the year but it’s been hugely rewarding to be part of.  Throughout the year I met a lot of people being introduced to VMUG for the first time.  Received some amazingly positive feedback from both new and old faces to the group.  And of course made some awesome new friends.  All of which really makes the hard work worth while.

As always Melbourne VMUG year kicked off its year with our annual UserCon in March, an all day free conference run by the community for the community.  For an event held on the other side of the world to many it’s amazing to see our UserCon really start to make a name for itself.  This couldn’t have been more demonstrated with the calibre of international guests eager to come out and support us this year.  From our opening Keynote speakers of Duncan Epping and Amy Lewis, to our closing keynote speakers William Lam and Alan Renouf.  Not to mention Emad Younis, Josh Atwell, and Rebecca Fitzhugh.  An amazing group of people whom I have a new level of respect for.

Following on from our UserCon we held three quarterly meetings throughout the year.  A few notable sessions that really stood out for me were The Register’s, Simon Sharwood, and VMware APJ CTO, Bruce Davie.  Some very insightful sessions that really made you thing about our industry.  New for this year we introduced a closing survey to all our meetings.  The responses received from these surveys would go into shaping subsequent meetings.  It’s been great to see the community support this initiative and be more involved in shaping how future VMUGs runs in Melbourne.  A big thank you to everyone that participated in these surveys!

Back in November a few of us on the committee travelled up to Sydney to help represent not just Melbourne but VMUG Australia at vForum Australia.  I’ve already spoken about vForum in a previous post so there’s not much more I can add to that.  It was a great experience to be behind the booth promoting VMUG to a whole new audience from around the country.  I now have a new level of respect for the hard work vendors and the people put in behind the booth at these kind of events.

Carrying on from previous years we continued to support and run separate vBeers events in between our UserCon and quarterly meetings.  It’s been great to see Melbourne vBeers really coming into it’s own this year.  The more intimate setting allowed for some great conversations that aren’t always possible at regular VMUG meetings.  As with our quarterly meetings many new faces have starting becoming regulars and support from vendors has increased allowing us to do more sponsored nights and drinks.  I look forward to meeting many new and old faces over vBeers next year.

It’s hard to convey in a short post everything that Melbourne VMUG has achieved this year.  Hopefully some of these numbers will help speak to that.  1 UserCon, 3 Quarterly meetings, 5 vBeers nights, 10 community presentations, 12 VMware presentations, and 6 Vendor presentations.  Some ammazing numbers that sets a high benchmark for next year.  I’m extremely appreciative of all those that presented and helped to give back to the community this year.

As always a huge thank you to the committee and supporters of Melbourne VMUG over 2017.  In particular Tyson Then, fellow co-leader.  I could not ask for a nicer guy to be a co-leader with.  Along with fellow committee members Andrew Duancey, Brett Johnson, Damien Calvert, and recently departed Craig Waters.  As well as some of our regular VMware liaisons Mo Jamal, Kev Gorman, and Chris Garrett.  The list does goes on, i’m sure I’ve missed many, just know your your time and effort has been greatly appreciated 🙂

I hope everyone has a great Christmas and an awesome New Year.  Attention now turns towards our next UserCon in March 2018.  Hope to see you all then!