Error Setting Timezone on vCloud Director 9.5 Appliance

vCloud Director 9.5 is VMware’s first attempt at an appliance for vCloud Director.  It’s built upon VMware’s Photon OS 2.0.  The appliance does a couple great things.  It’s provided as an Linux appliance pre-configured with all the required dependencies for vCloud Director and installs the vCD binaries.  It also comes as an OVA deployment allowing you to easily enter all the required parameters to simplify the deployment.

Unfortunately the appliance isn’t perfect and has a few bugs in it.  The first of which you’ll come across very soon after deployment when you attempt to set the timezone from the console.

When you open the console for the first time you’ll see a familiar looking console menu where you can login or Set Timezone.  When you attempt to set the timezone you will see an error briefly flash up on the screen then be taken back to the console menu.

/usr/bin/tzselect: line 180 /usr/share/zoneinfo/zone1970.tab No such file or directory
/usr/bin/tzselect time zone files not setup correctly

There is no obvious way to correct this issue until a patch is released.  The timezone, though, can still be set via the CLI with the following steps.

Login to the CLI and type in

ls /usr/share/zoneinfo/

Find your nearest region and perform another ls on that folder.  If your region doesn’t exist you can perform an ls on Etc to select a specific GMT zone.

In my example I choose Australia.

ls /usr/share/zoneinfo/Australia/

Inside this directory find your nearest State or City.

Use the VAMI set timezone command to set this region.  For example

[email protected] [ ~ ]# /opt/vmware/share/vami/vami_set_timezone_cmd Australia/Melbourne
Timezone settings updated

Exit out of the CLI to return to the console menu.  Your timezone should now be set.

Quick Fix: Increase Root Partition Size in VCSA 6.7

Full disclosure, I’m stealing Anthony Spiteri’s ‘Quick Fix’ used in the title of this post.  It’s somewhat related to a post Anthony published yesterday so I hope he doesn’t mind.  Over this past week both Anthony and I upgraded our vCenters from 6.7 to 6.7 U1.  While our problems were slightly different they both had a common issue.  Our root partitions on our Tiny install of VCSA 6.7 had either run out of space or near out of space causing upgrade issues to U1.

While Anthony was adamant in finding the root cause of the issue to free up space my solution was much simpler --just increase the space on the root volume.  I’ve seen this a number of times with Tiny installs of VCSA so I didn’t want to bother troubleshooting a Home Lab problem through the night.

TL:DR

See bottom of post for the full description of my issue.

Issue:

The VCSA root partition is at 100% or near 100% with less than 10% free space available.

[email protected] [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 792K 4.9G 1% /dev/shm
tmpfs 4.9G 696K 4.9G 1% /run
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
/dev/sda3 11G 11G 0 100% /

/dev/mapper/imagebuilder_vg-imagebuilder 9.8G 23M 9.2G 1% /storage/imagebuilder
/dev/mapper/log_vg-log 9.8G 2.3G 7.0G 25% /storage/log
[email protected] [ ~ ]#

Resolution:

Increase the size of /dev/sda3

Edit the settings of the VCSA VM and located Hard Disk 1 (This disk represents device SDA).  Increase the size of the disk from 12 GB (for a Tiny appliance deployment).  In the example below I have increase it to  20 GB.

Click OK and reboot the appliance.

After the reboot SSH to the VCSA and enter the shell.

There’s a few different commands you can run at this point (see my full issue below) but the easiest command to run is below

/usr/lib/applmgmt/support/scripts/autogrow.sh

As its name implies this will auto grow the root partition with the available space just allocated.

You should now see something like below.

[email protected] [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 792K 4.9G 1% /dev/shm
tmpfs 4.9G 696K 4.9G 1% /run
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
/dev/sda3 19G 9.1G 8.5G 52% /

/dev/mapper/imagebuilder_vg-imagebuilder 9.8G 23M 9.2G 1% /storage/imagebuilder
/dev/mapper/log_vg-log 9.8G 2.3G 7.0G 25% /storage/log
[email protected] [ ~ ]#

The root partition should now have sufficient space for normal operation or upgrades.

 

 

Full Issue:

During an attempt to update my VCSA from version 6.7 to 6.7 U1 I encountered the following error in the VAMI.

Update installation failed. vCenter is non-operational

Attempting to log onto the appliance may also cause intermediate issues.

Error in method invocation Field messages missing from Structure com.vmware.vapi.std.errors.service_unavailable

Checking the space usage on my appliance showed that I only had 5% free space which appeared to not be sufficient for an appliance upgrade.

[email protected] [ ~ ]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.9G 0 4.9G 0% /dev
tmpfs 4.9G 792K 4.9G 1% /dev/shm
tmpfs 4.9G 696K 4.9G 1% /run
tmpfs 4.9G 0 4.9G 0% /sys/fs/cgroup
/dev/sda3 11G 9.1G 900M 95% /

/dev/mapper/imagebuilder_vg-imagebuilder 9.8G 23M 9.2G 1% /storage/imagebuilder
/dev/mapper/log_vg-log 9.8G 2.3G 7.0G 25% /storage/log
[email protected] [ ~ ]#

After a little bit of troubleshooting and attempting to locate the correct vCenter Hard Disk that /dev/sda3 represented.  I identified that Hard Disk 1 was the correct vCenter disk.  /dev/sda3 has multiple partitions and the actual size of /dev/sda is 12GB for a Tiny VCSA install.

To correct the issue I increase the size of this disk to 20 GB, rebooted the appliance, and ran the below command.

/usr/lib/applmgmt/support/scripts/lvm_cfg.sh storage lvm autogrow

This command auto grew the root partition with the available space on the disk that I had just allocated.  I later found out that autogrow.sh is a much simpler command to run and that lvm_cfg.sh wasn’t available anymore after upgrading to VCSA 6.7 U1.

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 https://raw.githubusercontent.com/originaluko/vSphere_PowerCLI/master/Dockerfile

curl -O https://raw.githubusercontent.com/originaluko/vSphere_PowerCLI/master/supervisord.conf

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.

https://{my_vcsa}:4200

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

  tasks:
    - 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: [10.10.10.10]

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

PLAY RECAP *******************************************************************************************************************************************************
10.10.10.10 : 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.

References

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.

Ubuntu

sudo apt-add-repository ppa:ansible/ansible

sudo apt-get install ansible

CentOS

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_ip: 192.168.0.100
vcenter_username: administrator
vcenter_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          24242245545455516332373965613662616531653266326362643533613932356530663263326663
          65363339653337333478977865425424245245824524824858666463373838323330666633363763
          65323436643563333334527873245674247868727672789689787867867878643130616261336262
          3462323161633933320a653030333478567825725727855427887878787886666624313862663462
          8775

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
  tasks:
    - name: include vars
      include_vars:
        dir: group_vars

    - name: Create Datacenter in vCenter
      local_action:
        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
      local_action:
        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
      vmware_resource_pool:
        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.

References

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
“terminal.integrated.shell.windows”: “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 https://code.visualstudio.com/

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(‘https://chocolatey.org/install.ps1’))

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 https://chocolatey.org/  and instructions to install PowerShell Core can be found at https://chocolatey.org/packages/powershell-core

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:

Add-WindowsPSModulePath

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,enable,disable}
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
(cli)

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 (svc.ni.vmware.com:443): Passed
Support connectivity status (support2.ni.vmware.com:443): Disabled
Registration connectivity status (reg.ni.vmware.com:443): Passed

Web Proxy connectivity status: Passed

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

References

https://docs.vmware.com/en/VMware-vRealize-Network-Insight/3.7/com.vmware.vrni.cli.doc/GUID-5BD84F61-4612-4330-B6D5-8D51DBAD3C25.html