Browsed by
Tag: cli

VCSA Tools – Part 1 – journalctl. Better way for vCSA log revision.

VCSA Tools – Part 1 – journalctl. Better way for vCSA log revision.

There’s a plenty of great CLI tools in VCSA that modern vSphere administrator should know, so I decided to share my knowledge and describe them in the series of articles.

The first one is journalctl. A tool that simplifies and quickens the VCSA troubleshooting process.

Below I’m presenting how I’m using it, to filter the logs records.

Log in to VCSA shell and run the commands below, regarding to the result you want to achive.

The logs from the current boot:

journalctl -b

The boots that journald is aware of:

journalctl --list-boots

It will show this kind of results representing each known boot:

-3 26c7f0e356eb4d0bbd8d9fad1b457808 Wed 2019-01-09 15:18:12 UTC—Wed 2019-01-09 16:58:18 UTC
-2 124d73cf46d441908db7609813e0c49a Wed 2019-01-09 17:01:08 UTC—Fri 2019-01-11 10:22:39 UTC
-1 ebf1ba1936404fb086727b61ac825d47 Fri 2019-01-11 11:22:59 UTC—Fri 2019-01-11 15:48:37 UTC
 0 bd70a6d99a7245dc9b7859c5f2a7ef6f Mon 2019-01-14 10:19:47 UTC—Tue 2019-01-15 12:38:16 UTC

Now you can use it, to display the results of the chosen boot:

journalctl -b -1

To limit the results to the given timeframe, use dates or keywords:

journalctl --since "2019-01-10" --until "2019-01-14 03:00"


journalctl --since yesterday


journalctl --since 09:00 --until "2 hour ago"

Limiting the logs by service name:

Get the service names first:

systemctl list-unit-files | grep -i vmware

To show only records for vpxd service in current boot:

journalctl -b -u vmware-vpxd.service

Filtering by Id (Process, User or Group):

Get the user Id, e.g.:

cat /etc/passwd | grep -i updatemgr


journalctl _UID=1017 --since today

Filtering by the binary path:

journalctl -b --since "20 minute ago" /usr/sbin/vpxd

Displaying kernel messages:

journalctl -k

Limiting messages by their priorities:

journalctl -p err -b

where the priority codes are:

0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug

Of course those examples don’t exhaust all the possibilities this tool has, but consider them as a usage starting point. Feel free to add new, useful examples in comments below.

That’s all for today!

Alternative methods to create virtual switch.

Alternative methods to create virtual switch.

Creating virtual switch through GUI is well described in documentation and pretty intuitive using GUI. However, sometimes it might be useful to know how to do it with CLI or Powershell, thus making the process part of a script to automate initial configuration of ESXi after installation.

Here you will find commands which are necessary to create and configure a standard virtual switch using CLI and Powershell. Those examples will describe the process of vSwitch creation for vMotion traffic which involves VMkernel creation.

I. vSwitch configuration through CLI

  1. Create a vSwitch named “vMotion”

esxcli network vswitch standard add -v vMotion

  1. Check whether your newly created vSwitch was configured and is available on the list.

esxcli network vswitch standard list

  1. Add physical uplink (vmnic) to your vSwitch

esxcli network vswitch standard uplink add -u vmnic4 -v vMotion

  1. Designate an uplink to be used as active.

esxcli network vswitch standard policy failover set -a vmnic4 -v vMotion

  1. Add a port group named “vMotion-PG” to previously created vSwitch

esxcli network vswitch standard portgroup add -v vMotion -p vMotion-PG

  1. Add a VMkernel interface to a port group (Optional – not necessary if you are creating a vSwitch just for VM traffic)

esxcli network ip interface add -p vMotion-PG -i vmk9

  1. Configure IP settings of a VMkernel adapter.

esxcli network ip interface ipv4 set -i vmk9 -t static -I -N

  1. Tag VMkernel adapter for a vMotion service. NOTE – service tag is case sensitive.

esxcli network ip interface tag add -i vmk9 -t vmotion

Done, your vSwitch is configured and ready to service vMotion traffic.


II. vSwitch configuration through PowerCLI

  1. First thing is to connect to vCenter server.

Connect-VIServer -Server vcsa.vclass.local -User administrator@vsphere.local -Password VMware1!

  1. Indicate specific host and create new virtual switch, assigning vmnic at the same time.

$vswitch1 = New-VirtualSwitch -VMHost sa-esx01.vclass.local -Name vMotion -NIC vmnic4

  1. Create port group and add it to new virtual switch.

New-VirtualPortGroup -VirtualSwitch $vswitch1 -Name vMotion-PG

  1. Create and configure VMkernel adapter.

New-VMHostNetworkAdapter -VMHost sa-esx01.vclass.local -PortGroup vMotion-PG -VirtualSwitch vMotion -IP -SubnetMask -vmotionTrafficEnabled $true


Importing the Dukes Bank sample application blueprint – Introduction to vRealize CloudClient

Importing the Dukes Bank sample application blueprint – Introduction to vRealize CloudClient

Have you just installed the vRealize Automation in your lab and do not know how to start the journey with services? The Dukes Bank for vSphere application might be a perfect start for you!

But what is that mystery Dukes Bank application ? It is not widely known that there are let’s say “embedded” samples of multi-tiered vRealize Automation blueprints  that includes multiple machine components with networking and software components.

The reason that it is not known by many is that they are not available ad-hoc after installation, you will not see them inside your catalog. To publish these services in Tenant’s catalog you need to import and configure it first. Bellow I described the procedure how to import and publish these services, in another article you will find out how to configure it.

The ZIP file for Dukes Bank sample application blueprint is include on the vRA appliance, however to import it you have to use vRealize Cloud Client which can be downloaded here.

vRealize CloudClient is a CLI utility that provides verb-based access with a unified interface across vRA APIs, it is available since vRA version 6.2. The purpose of CloudClient tool is to create a layer of abstraction between vRA and end consumer, I mean Administrator of vRA to increase the ease by which he is able to run automated actions against vRA. It is worth to meantion that this tool is not a REST or SOAP API. It uses the vRA API instead.

Just to list a few of use cases for vRA API:

  • Reporting;
  • Monitoring and troubleshooting;
  • Change request system;
  • Operation scripts;
  • Migration between environments;
  • Creating reservations;
  • Creating business groups;
  • Creating entitlements;
  • Other management tasks.

Going back to the point, after downloading the CloudClient you can run it from Windows as well as Linux, however I realized that if you want to import Dukes Bank application you must run it from vRA appliance.

Whilst running it from Windows I received an error like below:


Well, my recommendation is to copy CloudClient into vRA appliance and run it using

Before you will be ready to import Dukes Bank you need to download the package using following command:

#wget –no-check-certificate https://YOUR_vRA_URL:5480/blueprints/dukesbankappforv

Then you could copy it to /tmp for easier navigation.


When you have the package it is hight time to run CloudClient and connect to vRA using following command:

vra login userpass –user tenant_admin_username –tenant your_tenant_name –server –password your_pass


After successful login you can validate and import the package.

To validate use the following command with dry-run:

vra content import –path / –dry-run true –resolution OVERWRITE

NOTE! Pay attention to capital letters, it is case sensitive.

To import the package change the argument of dry-run to false:

vra content import –path / –dry-run false –resolution OVERWRITE


And that is it, the first step to deploy sample blueprints is done. You can validate that these packages are imported by from your vRA console. You need to log in as a user with software and infrastructure architect privileges. The Dukes Bank blueprints and software components on the Design > Blueprints tab and the Design > Software Components tab.