blog.ukotic.net

vExpert 2019 is here and it’s huge!

Well after a long wait it’s that time of year again when the first half of year announcements are made for vExperts. A big congratulations to all the new and returning vExperts this year, in particularly all my fellow Australian vExperts. And yeah why not, a congratulations to even those just across the pond over in New Zealand. It’s just another state of Australia right 😛

This is my fifth year as a vExpert and as of late last year my first as a vExpert Pro. It’s this new sub program that I’m most proud and honoured to be part of. But more on this program later.

This year we have 1739 vExperts being honoured from 74 countries. That’s approximately 250 more than the same time last year and on par with vExpert numbers after the second half intake of 2018.

The United States are most represented with 639, followed by United Kingdom at 157. My home country, Australia, ninth most represented with 45 this year. 18 of those countries are represented by only 1 vExpert.

The recently updated public vExpert directory can be found at https://vexpert.vmware.com/directory/ . It contains all of this years vExperts with their public profile.

Coming back to the vExpert Pro sub program. I first heard about this program being created from Valdecir Carvalho (@homelaber) at VMworld Vegas in 2018. I thought it was a really great idea when Val described it to me. I won’t go into too much detail on this sub program as there’s a number of blogs that cover it very well. Basically though, one of its goals is to create vExperts that can champion the vExpert program in specific countries and regions around the world. In English speaking countries that might be a little hard to understand but in countries that don’t speak English, which it might be surprising to know, covers most of the world. As a result of the language barrier it can be hard to recruit and communicate to vExperts in non English speaking countries. That’s where bilingual vExpert Pros can help translate any vExpert communication back into their native language to fellow vExperts and potential candidates.

Coming a little closer to home I had a few potential first time vExperts in Australia approach and ask to sit down with me and help them work through the vExpert application process. Something that I felt quite humbled to help out with. I also had a number of people ask if I could be used as a reference if further information was required of them. Again, something I was more than happy to help with. If I can take a little of my personal time to help someone join this great program it’s well worth it.

A little bit of insight into how the voting and approval process worked this year. With a huge amount of applicants now applying for vExpert you can understand what a mammoth job it is to go through and screen each person for vExpert recognition and award. This is where the vExpert Pros were able to help out in a voting process. We had the opportunity to go through and help the core VMware vExpert team curate and vote for vExpert approval. I can comfortable say we all took this process very serious. Of course we were just voting and providing feedback with ultimate say and oversight coming from people like
Valdecir Carvalho and Corey Romero in making final decision. I feel the process worked quite well and should lead to a higher level of standard for vExpert approval but also future applications.

In conclusion, with the increased scrutiny and review of applicants. Everyone that made vExpert for 2019 should be extremely proud of themselves. We’re part of a great community and we have a high standard to live up to. The days of providing vague and misleading information on your applications are going away.

Again, congratulations to all the 2019 vExperts! Well Done and keep up the good work.

Configuring ESXi prerequisites for Packer

Posted by Mark Ukotic on March 5, 2019 2 comments

I’m currently working on a Packer build process for a customer using ESXi. The last time I had worked on Packer was over a year ago and I quickly realised how fast I forgot many things for a successful build. It’s also been interesting to experience new bugs and nuances using new versions of products. So I thought I might document some of my experiences to get to a successful build. I think this will easily turn into a multi-part post so I will attempt to document my process as much in order as possible.

A quick recap to Packer if you’re new to it all. Packer is brought to you by the good folks that brought you Terraform and Vagrant --HashiCorp. It’s a relatively small single file executable that you can use to programmatically build images through scripts. You can then take those images and upload them to AWS, Azure, or in my case, VMware ESXi.

While Packer works great with tools like Vagrant and VirtualBox. As a VMware Consultant I want to leverage ESXi for the build process. But before we can start with a Packer build we need to set up a few prerequisites on ESXi.

The first thing we need to do is designate an ESXi host for our builds. The reason we need a host and not a vCenter is that Packer will connect to the host via SSH and use various vim-cmd commands to do it’s work. Once we have a host there are three steps to complete, listed below.

Enable SSH
First we need to enable SSH on our host. There’s a number of different ways to do this. The two easiest ways are via the ESXi host Web Client or if managed by vCenter inside that.

For the host web client, navigate in a browser to https://esxi_host/ui and login with the root account. Navigate to the Manage pane and select the Services tab. Scroll down to TSM-SSH and click Start. Under Actions you may also want to change the policy to Start and Stop with Host.

In vCenter it’s a little different. Locate the host you have designated. Select the Configuration Tab. Scroll down to Security Profile and Click Edit. A new window will appear. Scroll and locate SSH, select start and change the Startup Policy to Start and stop with host.

Enable GuestIPHack
Next we need to run a command on the ESXi host. What this command does is allow Packer to infer the IP address of the Guest VM via ARP Packet Inspection.

SSH onto the ESXi host (e.g. using putty) and run the below command.

esxcli system settings advanced set -o /Net/GuestIPHack -i 1

Open VNC firewall ports on ESXi
Lastly, Packer uses VNC to issue boot commands to the Guest VM. I believe the default range is 5900 -- 6000. 5900 being the default for VNC but if you’re performing multiple builds or the port is in use Packer will cycle through the range until it finds an available one.

Run the following commands on the host to allow us to modify and save the firewall service.xml file.

chmod 644 /etc/vmware/firewall/service.xml
chmod +t /etc/vmware/firewall/service.xml
vi /etc/vmware/firewall/service.xml

Scroll to the very end of the file and just above the last line /ConfigRoot press i (to insert) and add the below in.

<service id="1000">
  <id>packer-vnc-custom</id>
  <rule id="0000">
    <direction>inbound</direction>
    <protocol>tcp</protocol>
    <porttype>dst</porttype>
    <port>
      <begin>5900</begin>
      <end>6000</end>
    </port>
  </rule>
  <enabled>true</enabled>
  <required>true</required>
</service>

press ESC and type in :wq! to save and quit out of the file.

Restore the permissions of the service.xml file and restart the firewall.

chmod 444 /etc/vmware/firewall/service.xml
esxcli network firewall refresh

You can check if you successfully made the change by heading back over to the host in the web client and checking the Security Profile section. Only the first port will be shown and not the range. You can also use the below commands on the host to confirm and see the entire range of ports set.

esxcli network firewall ruleset list
esxcli network firewall ruleset rule list

These are the only three changes you really need to make to an ESXi host for a Packer build to work successfully. I’ve tried to go into a little detail of each step to provide an explanation of what each change is doing. In reality it should only take a few minutes to implement.

In some secure environments I’ve seen SSH set with a timeout. If you notice SSH disable after you’ve enabled it. You’ll need to remove the timeout as SSH needs to stay enabled. You’ll also want to confirm that no external firewalls are blocking access to the VNC port range from Packer.

In future posts I’ll go into detail around the prerequisites in configuring a Windows Server to run Packer and importing / exporting OVF images.

VMware Cloud on AWS Management Exam 2019

Posted by Mark Ukotic on January 22, 2019 2 comments

It’s been a busy few weeks for me. Earlier on this month I wrote about sitting the VMware Cloud Provider Specialist Exam and continuing on from that I decided to pursue the VMware Cloud on AWS Management Exam.

As I previously discussed with the Cloud Provider exam it falls into a new collections of exams from VMware that are aimed at providing skills and achievements rather than certifications. Now if you’re a little confused let me clarify it a little more. Unlike the Cloud Provider which would require you to hold a VCP and provides you a badge denoting you as a Specialist. The VMware Cloud on AWS exam has no prerequisites and gives you a Skill VMware / Acclaim badge. All straight-forward right?!?! If you’re still confused, don’t worry about it for now, many people are.

Covering off some of the fundamentals of this exam. It’s a non-proctored web based exam. Meaning you can sit it whenever and where ever you like. You have 30 questions with 45 minutes which to complete it in. So while not many questions, you have only a minute and a half on average to answer each question.

Being honest, it’s a fairly basic exam comparative to other VMware exams available. You’re not going to be overly challenged over the 45 minutes. We do have to put this exam into context a little here though. As I mentioned above this exam is classed as a Skill. It’s not a certification so the question count and difficulty of those questions are kind of reflected here. I would rate this Skill exam a little below the level of a Specialist exam like that of the Cloud Provider I took recently.

If you look at what it’s trying to achieve as an exam it does hit the mark. Prior to studying and sitting this exam I really knew little about VMware Cloud on AWS. I had been to many sessions and presentations on VMC over the last year or so. In all the sessions I’ve seen they did a great job of explaining what it is but I still really didn’t know how to use it or all the little intricate things it was capable of. Having now studied and taken the exam, I have a much more thorough understand not just of the product but how it’s actually used and managed.

The types of questions you will see in the exam can be broken up into two basic categories. Simple high level questions of what VMware Cloud on AWS can do and what those services are. Then the slight more technical, but still relatively simple, questions on how to actually perform a task.

My study consisted of the VMware Cloud on AWS: Deploy and Manage three day course. It’s a paid course which you can do in the classroom or on-demand, the latter which I did. This was the bulk of my study which I crammed over three nights after work. The course covers 95% if not 100% of what is in the exam. I supplemented this with a very short demo of the VMware Cloud on AWS -- Getting Started Hands-on Lab and briefly looked at the VMware Cloud on AWS Sizer and TCO site and the VMware Cloud on AWS | FAQs.

Final Thoughts:
While far from being a deep technical exam. It does a decent job on testing your knowledge of the product and validating those skills. Certainly from my view point it encouraged me to actually spent some time studying VMware Cloud on AWS which I had been otherwise avoiding until now. Don’t expect to become a guru on the product afterwards but take the exam for what it is a learn something new if you haven’t delved into it until now.

VMware Cloud Provider Specialist Exam 2019

Posted by Mark Ukotic on January 13, 2019 No comments

After many months of procrastinating I finally decided to sit the VMware Cloud Provider Specialist Exam (5V0-32.19). The exam was released at the end of August 2018, so it’s been available for quite a few months now. This comes after a long wait from the vCloud community asking for a specialist / dedicated exam around vCloud Director and its product suite.

The first thing to note with this exam is that it’s not a certification but rather falls under a new collection of exams from VMware that are better represented by Skills and Achievements and are acknowledged through VMware / Acclaim Badges (as shown by the one above).

The exam is non-proctored web based. Meaning, like me, you can take the exam first thing in the morning before starting work. This is a format first released by VMware with their VMware Certified Associate exams a number of years back. The exam is 40 questions sat over 60 minutes with the standard 300 passing score. The exam is predominately focused on vCloud Director but also cover numerous other products in the vCloud Suite of products and the Cloud Provider program

It’s a relativity solid exam, I feel sitting in between an Associate and Professional certification in terms of difficulty. Having used vCloud Director and its various suite of tools for quite a few years now. I took this exam cold with no additional study. I managed to answer the 40 questions in a little over 30 minutes and then spent 10 minutes reviewing about a dozen questions I was a little uncertain on. Generally speaking, with these kind of exams, you either know or don’t know the answer. So trust you gut instinct and put your answer as the first thing that comes to your mind. Then flag it for review if you are truly uncertain.

So what should you do if you want to take and pass this exam? It’s a little tricky for me to definitively recommend study material as I relied on my previously gained knowledge of the vCloud Director and it’s various product line. I would certainly say this is an exam for someone that administers and engineers vCloud Director solutions. That’s generally going to be someone in the Service Provider space. If you don’t use vCloud Director I would question the real benefit you would gain from this exam, with the exception of forcing you to study up on the various products that go into this exam. If you’re still set on this exam and don’t have access to vCD you’re best bet would be Hands on Labs HOL-1983-01-HBD -- VMware Cloud Provider Program -- vCloud Director for Service Providers.

There is no formal Blueprint that I’m aware of but there is an Exam Preparation Guide PDF for the exam on the VMware Certification site. It has quite a lot of Sections and Objectives to work through and a huge amount of reference material. This could be quite a challenge for someone new to vCloud Director to work through.

Generally speaking though you will need to know vCloud Director. It’s the core focus of this exam. The exam is also based on vCD 9.1. This is extremely important to know. For example things like supported databases have changed in recently releases of vCD leading you to in incorrect assumption for the answer. While it’s unlikely you’ll be asked to specifically do something around point and clicks. You will more likely need to understand all the different terminologies and constructs used in vCD and how they relate back into vSphere.

You should understand the concepts and components behind vCloud Extender. What it is, what it does, and how you might use it. The same goes for vCloud Usage Meter and it’s newer SaaS offering Usage Insight. While I don’t recall but you may see some questions around vCloud Availability too.

You’ll also probably see a few questions around a new product, Cloud Provider Pod and Cloud Provider Hub. Very few people would have hands on experience with this new product. It’s basically an Orchestration platform to stand up an entire vCloud Director stack from bare metal. I’d recommend watching the VMworld presentation Introducing VMware Cloud Provider Pod presented by Wade Holmes which should give you all the high level information you need on it.

Final Thoughts:
As mentioned above, this is a solid exam. It covers quite a lot of different products in VMware’s Cloud Program Program / vCloud suite. It’s ideally suited to Service Providers using vCD. vCloud Director is a very intricate product with many external dependencies. The exam is a great way to validate and acknowledge those skills you have acquired with vCD and associated products.

Error Setting Timezone on vCloud Director 9.5 Appliance

Posted by Mark Ukotic on December 1, 2018 No comments

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.

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

Posted by Mark Ukotic on October 23, 2018 1 comment

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

Posted by Mark Ukotic on September 19, 2018 No comments

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

Posted by Mark Ukotic on September 8, 2018 No comments

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

Posted by Mark Ukotic on September 3, 2018 No comments

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

Posted by Mark Ukotic on July 16, 2018 1 comment

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