In this post, I am going to discuss a little, “not-so-well-known” utility, called VMware Software Manager.  This little “beast” was first released as v1.0 back on 2015-03-12, and its most current release, v1.5, came out on 2016-08-25.  So as you can see, it’s been quite a while since this tool has seen a new update release.  The problem now is that this utility seems to have been forgotten and/or neglected by VMware, but I will get into more of that a little later.  Let’s start off with the positive stuff.

The Good:

The VMware Software Manager allowed valid VMware-account holders the ability to download various software, such as ESXi or vCenter server, quickly and easily.  The installation was a breeze, the interface was clean and downloading software was effortless.  It basically just worked flawlessly!  The new software was readily available for download shortly after it was announced/released since this utility would read configuration files to see what software is available from the VMware repository and then provided that software for download.

So, having said that, what could possibly be wrong with this thing?  Let’s continue…

The Bad:

My main gripe with this utility was that support was only community-based, so if you had issues, you could forget about raising an official SR with support.  You had to rely patiently on the VMTN community and hope that users were knowledgeable enough and willing to help out.  Not saying anything bad about the community though, it’s a great forum full of some really smart people and it provides a wealth of information.

As I mentioned earlier, when this thing worked…it just plain WORKED!  Then, vSphere 6.0U3A was released with some bad/corrupt or missing files and upon launching the utility, it would simply hang at login or error out due to the missing files not being available! (Shhhh!..someone never updated the configuration files… ¯\_(ツ)_/¯  )  There is a thread over on the VMTN community that myself and others have contributed to and another describing this issue and a workaround method to ultimately get you to log in again.  This involved looking at log files to find which missing file was causing the error, then editing the configuration file to remove the missing files, and it was a major pain!

Lastly, it’s become extremely out of date and it seems as if VMware has completed forgotten about and/or decided to neglect and give up on it as there has not been any new software available for download in at least 6 months.  It’s also possible that the original responsible for this thing disbanded or moved onto other roles…who really knows?  Luckily, a friend and fellow community/vExpert member has provided a solution!

The Alternative:

Fellow vExpert, Edward Haletky aka Texiwill, has created a Linux-based port of the utility, titled “VSM“, which he updates almost daily to add new software and simply improve the appliance and it runs on an RHEL type distro like CentOS.  You can hit the ground running with this appliance in about 30 mins or less.  I have been fortunate enough to serve as a beta tester for him and have been doing so since he released v0.95, just shortly after the initial public launch.  At the time of this writing, the most recent release was v3.7.7 but has now been updated to the newest 4.5.3.  Screenshots may reflect previous versions.

Well…How do you get it?

In this post, I am going to cover how to install this bad-boy on a CentOS 7 minimal installation on ESXi using NFS, and on VMware Workstation leveraging the “Shared Folders” feature using VMHGFS.  Another vExpert, Michael White, has a similar post on setting up this appliance and using SMB/CIFS for storing the downloaded software.  Let’s get to it, shall we!

Prerequisites:

• CentOS 7 x64 (Minimal) w/ open-vm-tools installed
• a non-root user account
• NFS storage or Local Storage (if running this on VMware Workstation/Fusion)

I will assume that you already have a basic installation of CentOS 7 running, or know how to set up a minimal installation, so that process is out of scope for this post.  

If you plan on running this on VMware Workstation/Fusion, run the following command to install the prerequisites needed for installing VMware Tools to get the vmhgfs driver for Shared Folders support.

sudo yum install -y perl gcc binutils make fuse kernel-headers kernel-devel net-tools policycoreutils-python

Otherwise, if you plan on using NFS to store the software, run the following command to install the NFS utilities.

sudo yum install -y nfs-utils

VMware Tools Installation:

Note: Enables vmhgfs driver support for Shared Folders on VMware Workstation or VMware Fusion

I will be installing the latest version of VMware Tools, version 10.2.0.  This can be obtained here.  Extract the .zip and attach the linux.iso to your CentOS VM in Workstation or Fusion.  Once connected, do the following.

Make a directory to mount the cdrom to.

sudo mkdir /mnt/cdrom

Mount the cdrom to this new directory.

sudo mount /dev/cdrom /mnt/cdrom

With the cdrom now mounted, let take a look at whats on the .iso

sudo ls /mnt/cdrom

We can see the compressed file that we will need to extract

Extract/Uncompress this file by running the following.  This is going to extract the file to my current working directory, $HOME

sudo tar zxpf /mnt/cdrom/VMwareTools-10.2.0-7253323.tar.gz

When that completes, we can see what was extracted by running

ls

At this point, we are done with the .iso and can unmount it by running.

sudo umount /dev/cdrom

Now, let’s navigate to the extracted folder and see what we’ve got.

cd vmware-tools-distrib/
ls

The Perl script is what we’re looking for here to install VMware Tools.  This will uninstall “open-vm-tools” if that is already installed on this machine.  Let’s go ahead and run it. 

sudo ./vmware-install.pl

Proceed to answer all the questions asked and select all of the defaults until the installation completes.

(Optional:) If you’d prefer to bypass the questions and force-install with all defaults run the following instead

sudo ./vmware-install.pl --force-install --default

This completes the VMware Tools installation and not the vmhgfs driver is installed.  Onto the good stuff!

VSM Installation:

Texiwill has provided an installation script on his GitHub page which will take care of the installation and its prerequisites. This is the preferred installation method so I’d advise that you download this script, and run it.  You’ll first have to make the script “executable” by running

chmod +x install.sh

For those who prefer the manual approach, you’ll first need to install “wget“, then run the following commands to install the utility.

Note: please change timezone location to your respective location

sudo yum install -y wget
mkdir aac-base
cd aac-base
wget -O aac-base.install https://raw.githubusercontent.com/Texiwill/aac-lib/master/base/aac-base.install
chmod +x aac-base.install
./aac-base.install -u America/New_York
sudo ./aac-base.install -i vsm America/New_York

Congrats!  You’ve successfully installed the utility.  Now to configure it for use.

By default, the VSM script will save the config file (.vsmrc) to “$HOME“.  It will also save the index.html and credstore files in “/tmp/vsm“.  I highly recommend you create an alternate directory to store these files in if you are using a system that has multiple users or change it to save them in the users $HOME directory.  Again, this is optional and can be skipped, but if you’d like to do so, run the following

mkdir /tmp/my_vsm

VSM Initial Configuration:

The last step before you can use the VSM script utility is to configure it.  To list the all available parameters, execute the script with the help parameter.

vsm.sh -h

Based on the help info, the required parameters to set are:

• -v | –vsmdir VSMDirectory (this will be the “my_vsm” directory we created earlier)
• –repo repopath (this will be the path to the directory we’ll create to save our download)

When first executing the script utility, you will be required to enter valid MyVMware credentials which will be saved to the configuration file.

Let’s go ahead and create our repo directories first.  Feel free to use my examples or anything else you’d like.  We will also use the same steps mentioned about to take ownership of these directories and then mount our physical storage to the newly created mount point directory. 

Note: Be sure to enable “Shared Folders” on Workstation or Fusion and select the shared folder to mount it to the VM.  Commands may be different from screenshots as I’ve updated some commands.

For VMHGFS:

sudo mkdir -pvm 755 /mnt/vmhgfs/depot/content
sudo chown -R <non-root_username>.<non-root_username> /mnt/vmhgfs

For NFS:

sudo mkdir -pvm 755 /mnt/nfs/depot/content
sudo chown -R <non-root_username>.<non-root_username> /mnt/nfs

With our directories ready, let’s go ahead and mount our storage to them!

For VMHGFS:

Note: I have mounted the following shared folder to the VM to use for this command.

sudo mount -t fuse.vmhgfs-fuse .host:/content /mnt/vmhgfs/depot/content -o allow_other

For NFS:

sudo mount -t nfs <IP_address>:/<volume#>/<path_to_share> /mnt/nfs/depot/content

For NFS 4.1 (optional):

sudo mount -t nfs4 -o vers=4,minorversion=1 <IP_address>:/<volume#>/<path_to_share> /mnt/nfs/depot/content

Now, with our storage mounted we can run the VSM script and configure for use.

Note: You will be prompted to enter your VMware credentials unless you supply the “-u” and “-p” parameters

For VMHGFS:

vsm.sh -y -v /tmp/my_vsm --repo /mnt/vmhgfs/depot/content --save

For NFS:

vsm.sh -y -v /tmp/my_vsm --repo /mnt/nfs/depot/content --save

That about does it!  The appliance is ready to use and you can navigate through the menus to find your desired software. 

Extras:

To make your mount points persistent through reboots, edit the “fstab” file with your editor of choice.  I prefer to use vi or vim, but many may choose to use nano instead.

sudo vi /etc/fstab

Then, add the following line and save the file.

For VMHGFS:

.host:/content /mnt/vmhgfs/depot/content    fuse.vmhgfs-fuse        allow_other     0 0

For NFS:

<IP_address>:/<volume#>/<path_to_share> /mnt/nfs/depot/content    nfs      soft,bg,rsize=8192,wsize=8192       0 0

For NFS 4.1 (optional):

<IP_address>:/<volume#>/<path_to_share> /mnt/nfs/depot/content    nfs      nfsvers=4.1,soft,bg,rsize=8192,wsize=8192       0 0

Updates are released quite frequently.  To update VSM to the latest version, you can run the following commands manually or add them to a shell script within “/etc/cron.daily” which will run around 3 AM.

Note: please change timezone location to your respective location

cd /home/<user_name>/aac-base; ./aac-base.install -u; ./aac-base.install -i vsm America/New_York

Additionally, if you’d like to keep your favorite download repository up-to-date, edit crontab

Note:  This requires that you first “mark” a repository by using that menu option

crontab -e

Then add the following line to it and save.  This will run daily at 6 AM.

0 6 * * * /usr/local/bin/vsm.sh -y -mr -c --favorite

My Preference:

I tend to use the following command when running VSM to get missing suites and packages from MyVMware.  If you do not use the “-m” parameter, it will only pull the same software available in the original VMware Software Manager tool from VMware.  The “-mr” parameter resets the “MyVMware” software info and implies “-m” hence why this is also used in the crontab line above.  The “-c” tells VSM to generate sha256sum checks against each downloaded file.

vsm.sh -y -mr -c

Note: Depending on what you downloaded, there may be certain .txt files that will fail the checksum.  This is expected and can be safely ignored.

Well, I hope you’ve found this post useful and I thank you for reading!  Special thanks again to Texiwill for making this awesome utility, as well as Mike White for posting his similar article using SMB/CIFS.

-virtualex-

Pingbacks:

• Installing the Linux VMware Software Manager tool
• vSphere Upgrade Saga: Linux VMware Software Manager (VSM)
• Texiwill’s VSM GitHub

Updates:

• 03.23.18 – Updated to reflect changes in manual install commands for VSM v4.0.2, and cron.daily entry since cron runs as root so no need to use sudo
• 04.12.18 – Added TZ (Time Zone) setting to manual install commands and modified /etc/fstab command for NFS mounts
• 04.15.18 – Added “-c” parameter reference
• 01.17.19 – Added some command syntaxes for NFS 4.1

Just a few days ago, PowerShell Core v6.0 was released for Windows, Linux, and macOS systems.  Alongside this release came the release of VMware PowerCLI 10.0.0.78953 which is VMware’s own “PowerShell-like” utility.  

In my previous posts (here and here), I covered how to install those on to a macOS 10.13.x “High Sierra” system and a CentOS 7 system.  In this post, I am going to show how to install both on to an Ubuntu 17.10 system as this is another common distro which I also use in my environments.  Let’s get to it!

Note: If you’re interested in installing this on other Linux distros, please consult the following link.

There is a prerequisite needed before PowerShell can be installed on Ubuntu and that is to install “curl” and then add the PowerShell Core repository (recommended) to your system.

To install curl, enter the following.

sudo apt-get install -y curl

To add the PowerShell Core repository to Ubuntu, run the following command.  Enter your password if prompted

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -

To register the repository, enter the following command.  Again, enter your password if prompted.

curl https://packages.microsoft.com/config/ubuntu/17.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list

Great!  With the prerequisites complete, it’s time to install PowerShell Core 6.0.1.  Run the following command to do so and enter your password when prompted.

sudo apt-get install -y powershell

Awesome!  Now, to launch a PowerShell session in CentOS, enter the following.

pwsh

Within a PowerShell session, you can check the version of PowerShell by running the following.

$PSVersionTable.PSVersion

As new versions of PowerShell are released, simply update by running the following command.

sudo apt-get upgrade -y powershell

While leveraging the PowerShell Core repository is the recommended installation method, there are alternate methods as well.  For more information on that along with uninstallation commands, please see the following link.

Congratulations!  You’ve successfully installed PowerShell Core 6.0.1 onto Ubuntu!  Next comes the fun stuff for us VMware enthusiasts, installing VMware PowerCLI from the “PSGallery”.  Let’s continue!

Since VMware PowerCLI has moved from being its own native installer to the PSGallery, the PSGallery needs to be “Trusted” before anything from it can be installed.  To trust the PSGallery, entering the following command in the PowerShell session.

Note: This is optional and if it is skipped, you will be prompted to trust the gallery when entering the PowerCLI module install command

Set-PSRepository -Name "PSGallery" -InstallationPolicy "Trusted"

Next, run the following command to install the VMware.PowerCLI module.  This will find and install the latest version of the module available in the PSGallery

Find-Module "VMware.PowerCLI" | Install-Module -Scope "CurrentUser" -AllowClobber

Note: Alternatively, you could set the “-Scope” parameter to “AllUsers” and if you wanted to install a different version you could use the “-RequiredVersion” parameter and specify the version number.

Once this finishes, we can check to make sure the module is installed by running the following command.

Get-Module "VMware.PowerCLI" -ListAvailable | FT -Autosize

And if you’d like to see all of the VMware installed modules, run the following.

Get-Module "VMware.*" -ListAvailable | FT -Autosize

As new versions of VMware.PowerCLI are released, you can run the following command to update it.

Update-Module "VMware.PowerCLI"

With VMware.PowerCLI now installed, you can connect to your vCenter Server or ESXi host and begin using its cmdlets to obtain information or automate tasks!

I went ahead and ran the following to ensure the module was imported.  

Import-Module "VMware.PowerCLI"

I noticed one caveat, the SRM module does not seem to be supported in PowerShell Core, so I hope that gets resolved soon.

Let’s test connecting to vCenter server…

Connect-VIServer -Server "<Server_Name>"

I also noticed an error when running the above command stating that the “InvalidCertificateAction” setting was “Unset” and not supported.

To bypass this, enter the following command and then enter “Y” when prompted.  This will set the parameter for the current user.

Set-PowerCLIConfiguration -InvalidCertificateAction "Ignore"

Note: Alternatively, you can also use the “-Scope” parameter and enter “Session”, “User”, or “AllUsers” to apply the setting to those options respectively.

Now, if we try to connect to vCenter again, we should be successful.

Well, that about does it!  I hope that you have found this post useful and I thank you for stopping by and reading my content.  Until next time!

-virtualex-

Pingbacks: 

• Install PowerShell and VMware PowerCLI on macOS
• Install PowerShell and VMware PowerCLI on CentOS

Just a few days ago, PowerShell Core v6.0 was released for Windows, Linux, and macOS systems.  Alongside this release came the release of VMware PowerCLI 10.0.0.78953 which is VMware’s own “PowerShell-like” utility.  

In my previous post, I covered how to install those on to a macOS 10.13.x “High Sierra” system.  In this post, I am going to show how to install both on to a CentOS 7 system as this is the distro I mostly use in my environments.  I may follow this up with an Ubuntu install version.  Anyway, let’s get to it!

Note: If you’re interested in installing this on other Linux distros, please consult the following link.

There is a prerequisite needed before PowerShell can be installed on CentOS and that is to add the PowerShell Core repository (recommended) to your CentOS system.

sudo curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo

This will prompt you to enter your password since “sudo“ is being used. Great!  With the prerequisite complete, it’s time to install PowerShell Core 6.0.1.  Run the following command to do so and enter your password when prompted.

sudo yum install -y powershell

Awesome!  Now, to launch a PowerShell session in CentOS, enter the following.

pwsh

Within a PowerShell session, you can check the version of PowerShell by running the following.

$PSVersionTable.PSVersion

As new versions of PowerShell are released, simply update PowerShell by running the following command.

sudo yum update -y powershell

While leveraging the PowerShell Core repository is the recommended installation method, there are alternate methods as well.  For more information on that along with uninstallation commands, please see the following link.

Congratulations!  You’ve successfully installed PowerShell Core 6.0.1 onto CentOS!  Next comes the fun stuff for us VMware enthusiasts, installing VMware PowerCLI from the “PSGallery”.  Let’s continue!

Since VMware PowerCLI has moved from being its own native installer to the PSGallery, the PSGallery needs to be “Trusted” before anything from it can be installed.  To trust the PSGallery, entering the following command in the PowerShell session.

Note: This is optional and if it is skipped, you will be prompted to trust the gallery when entering the PowerCLI module install command

Set-PSRepository -Name "PSGallery" -InstallationPolicy "Trusted"

Next, run the following command to install the VMware.PowerCLI module.  This will find and install the latest version of the module available in the PSGallery

Find-Module "VMware.PowerCLI" | Install-Module -Scope "CurrentUser" -AllowClobber

Note: Alternatively, you could set the “-Scope” parameter to “AllUsers” and if you wanted to install a different version you could use the “-RequiredVersion” parameter and specify the version number.

Once this finishes, we can check to make sure the module is installed by running the following command.

Get-Module "VMware.PowerCLI" -ListAvailable | FT -Autosize

And if you’d like to see all of the VMware installed modules, run the following.

Get-Module "VMware.*" -ListAvailable | FT -Autosize

As new versions of VMware.PowerCLI are released, you can run the following command to update it.

Update-Module "VMware.PowerCLI"

With VMware.PowerCLI now installed, you can connect to your vCenter Server or ESXi host and begin using its cmdlets to obtain information or automate tasks!

I went ahead and ran the following to ensure the module was imported.  

Import-Module "VMware.PowerCLI"

I noticed one caveat, the SRM module does not seem to be supported in PowerShell Core, so I hope that gets resolved soon.

Let’s test connecting to vCenter server…

Connect-VIServer -Server "<Server_Name>"

I also noticed an error when running the above command stating that the “InvalidCertificateAction” setting was “Unset” and not supported.

To bypass this, enter the following command and then enter “Y” when prompted.  This will set the parameter for the current user.

Set-PowerCLIConfiguration -InvalidCertificateAction "Ignore"

Note: Alternatively, you can also use the “-Scope” parameter and enter “Session”, “User”, or “AllUsers” to apply the setting to those options respectively.

Now, if we try to connect to vCenter again, we should be successful.

Well, that about does it!  I hope that you have found this post useful and I thank you for stopping by and reading my content.  I’d like to give a shoutout to Jim Jones for his post on the same topic.  Until next time!

-virtualex-

Pingbacks: From Zero to PowerCLI: CentOS Edition

Just a few days ago, PowerShell Core v6.0 was released for Windows, Linux, and macOS systems.  Alongside this release came the release of VMware PowerCLI 10.0.0.78953 which is VMware’s own “PowerShell-like” utility.  In this post, I am going to show how to install both on to a macOS system.  Let’s get to it!

There are a few prerequisites needed before PowerShell can be installed on macOS which I will cover, and they are as follows:

• Homebrew – Homebrew installs the stuff you need that Apple didn’t.
• Homebrew-Cask – extends Homebrew and brings its elegance, simplicity, and speed to macOS applications and large binaries alike.
• Xcode Command Line Tools

Per the instructions on the Homebrew site, copy and paste the following command into a terminal window to install Homebrew.

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

This will prompt you to press Enter to continue and the prompt you to enter your password.  It will also check if Xcode command line tools are installed, and if not, it will download and install it for you before completing the installation of Homebrew. Nice!

Now, the next step is to install Homebrew-Cask and per its sites installation notes, copy and paste the following command into a terminal window.

brew tap caskroom/cask

Great!  With the prerequisites complete, it’s time to install PowerShell Core 6.0.1.  Run the following command to do so and enter your password when prompted.

brew cask install powershell

Awesome!  Now, to launch a PowerShell session in macOS, enter the following in terminal.

pwsh

Within a PowerShell session, you can check the version of PowerShell by running the following.

$PSVersionTable.PSVersion

As new versions of PowerShell are released, simply update the Homebrew formulae and update PowerShell by running the following commands in terminal.

brew update
brew cask upgrade powershell

While leveraging Homebrew is the recommended installation method, there are alternate methods as well.  For more information on that along with uninstallation commands, please see the following link.

Congratulations!  You’ve successfully installed PowerShell Core 6.0.1 onto macOS!  Next comes the fun stuff for us VMware enthusiasts, installing VMware PowerCLI from the “PSGallery”.  Let’s continue!

Since VMware PowerCLI has moved from being its own native installer to the PSGallery, the PSGallery needs to be “Trusted” before anything from it can be installed.  To trust the PSGallery, entering the following command in the PowerShell session.

Note: This is optional and if it is skipped, you will be prompted to trust the gallery when entering the PowerCLI module install command

Set-PSRepository -Name "PSGallery" -InstallationPolicy "Trusted"

Next, run the following command to install the VMware.PowerCLI module.  This will find and install the latest version of the module available in the PSGallery

Find-Module "VMware.PowerCLI" | Install-Module -Scope "CurrentUser" -AllowClobber

Note: Alternatively, you could set the “-Scope” parameter to “AllUsers” and if you wanted to install a different version you could use the “-RequiredVersion” parameter and specify the version number.

Once this finishes, we can check to make sure the module is installed by running the following command.

Get-Module "VMware.PowerCLI" -ListAvailable | FT -Autosize

And if you’d like to see all of the VMware installed modules, run the following.

Get-Module "VMware.*" -ListAvailable | FT -Autosize

As new versions of VMware.PowerCLI are released, you can run the following command to update it.

Update-Module "VMware.PowerCLI"

With VMware.PowerCLI now installed, you can connect to your vCenter Server or ESXi host and begin using its cmdlets to obtain information or automate tasks!

I went ahead and ran the following to ensure the module was imported.  

Import-Module "VMware.PowerCLI"

I noticed one caveat, the SRM module does not seem to be supported in PowerShell Core, so I hope that gets resolved soon.

Let’s test connecting to vCenter server…

Connect-VIServer -Server "<Server_Name>"

I also noticed an error when running the above command stating that the “InvalidCertificateAction” setting was “Unset” and not supported.

To bypass this, enter the following command and then enter “Y” when prompted.  This will set the parameter for the current user.

Set-PowerCLIConfiguration -InvalidCertificateAction "Ignore"

Note: Alternatively, you can also use the “-Scope” parameter and enter “Session”, “User”, or “AllUsers” to apply the setting to those options respectively.

Now, if we try to connect to vCenter again, we should be successful.

Well, that about does it!  I hope that you have found this post useful and I thank you for stopping by and reading my content.  I’d like to give a shoutout to Mike White for his post on the same topic.  Until next time!

-virtualex-

Pingbacks: Installing PowerShell/PowerCLI on a Mac

Hello all and thank you for visiting my blog!  In today’s post, I am going to cover how to deploy a VMware virtual appliance (.ova) using PowerCLI.  “Why?” you asked?  Well, because scripting and automation via PowerCLI is fun and awesome!  Sure, it’s simple enough to deploy an appliance natively within the vSphere Web Client by selecting the .ova that you’d like to import, press a few mouse clicks, enter some info, and off you go!  But who wants to do stuff the easy way?  It takes the fun away!

In my opinion, scripting this out is just as easy since you can pre-populate your information into variables, and then run a simple “one-liner” command to kick off the deployment.  Pretty neat right? 

Now, I do understand that initially doing a deployment this way is a bit time-consuming.  But once you have the method and process down, you can create a simple PowerShell script with all of your information embedded, then simply tweak/adjust it as needed per appliance.  The only time-consuming part is identifying the proper variables for each appliance.  Please keep in mind that while most appliances have the same initial setup variables, some may have more and some may have less so it is always best to follow the initial steps I’ll cover below for each appliance to ensure you have all the correct information for your deployment and/or script.

Well, let’s get to it, shall we!

In this example, I will be using the latest version of PowerCLI which, at the time of this writing, is 6.5.4.7155375, to deploy the VMware Support Assistant appliance for vSphere 6.5.

To kick things off, we will be using two important variables, $ovfPath, and $ovfConfig.  The latter will use the $ovfPath variable to discover the correct variable properties to build out our $ovfConfig.  I’ll assume that you’re already connected to your vCenter server in the PowerCLI session but, if not, please go ahead and do so using the “Connect-VIServer” cmdlet.

Let’s define our $ovfPath first:

$ovfPath = "<path_to_ova_file>"

Next, let’s define $ovfConfig

$ovfConfig = Get-OvfConfiguration -Ovf $ovfPath

Great!  Now if we simply type $ovfConfig, it will check our $ovfPath for the file and list the setup properties.

We can see that it has identified “Common“, “IpAssignment“, “NetworkMapping“, and “vami” as the starting base properties.  Next, we will have to drill down into each of these properties to determine the full property “Value” to define our variable with.

So starting with “Common“, let’s drill down more by typing:

$ovfConfig.Common

This now identifies the next “Common” property which is “varoot_password“.  Let’s drill into that to see what it finds.

$ovfConfig.Common.varoot_password

This gives us more information about the property and the key one here is “Value“. 

This means that we have reached the last property entry needed to define our first config variable with.  Great! With this information, our first defined configuration variable will look like this:

$ovfConfig.Common.varoot_password.Value = "<some_password>"

Let’s now move to the next property, “IpAssignment“.  Following the same logic as before and drilling into this property identifies “IpProtocol” which requires a “string” value of “IPv4 or IPv6“. 

This means our next defined variable will look like this.

$ovfConfig.IpAssignment.IpProtocol.Value = "IPv4"

Now for the next property, “NetworkMapping“.  Drilling down into this property identifies “Network_1” which again will be a “string” value for our variable.  This string is the VM PortGroup that you want to attach to the appliance, whether it be on a virtual Standard Switch (vSS) or Distributed Switch (vDS).

This defined variable will look like this.

$ovfConfig.NetworkMapping.Network_1.Value = "<some_vm_portgroup>"

Getting the gist of this yet?  Let’s move onto the final property, “vami“.  Again, following the same logic we’ve been doing and drilling into the “vami” property, we can see that it has identified the “appliance” as “VMware_vCenter_Support_Assistant_Appliance“.  Drilling down further, there are multiple properties discovered in this one and they are “gateway“, “domain“, “searchpath“, “DNS“, “ip0“, and “netmask0“.

Whoa! Quite a few huh?  Yet again, drilling into each of these lets us know that “string” values are required for each property.

These config variables will be defined like this.

$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.gateway.Value = "<gateway_ip>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.domain.Value = "<domain_name>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.searchpath.Value = "<dns_searchpath>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.DNS.Value = "<dns_ip(s)>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.ip0.Value = "<appliance_ip>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.netmask0.Value = "<netmask_ip>"

From what we’ve obtained so far, all of our defined variables look like this.

Ready to deploy the appliance?  Not quite yet!  There are some additional variables we can create/define to make the syntax of our command shorter, neater, and nicer.  First, let’s see what the cmdlet requires.  The cmdlet used to deploy an appliance is “Import-vApp“.  Clinking that link and reviewing the table show us what is required or not.

From this table, I am going to define some more variables for the following parameters.

• Source
• Name
• VMHost
• Datastore
• DiskStorageFormat
• Location
• OvfConfiguration

Now, with all of the variables defined, we are ready to enter the “Import-VApp” command with the required parameters.

Import-VApp -Source $ovfpath -OvfConfiguration $ovfConfig -Name $VMName -VMHost $VMHost -Location $Cluster -Datastore $Datastore -DiskStorageFormat $DiskFormat -Confirm:$false

A progress bar will load in your session showing that the deployment has kicked off, and a short while later it will end, meaning that the appliance has been successfully deployed.

A quick look at the vSphere Client, and we can see that the appliance is indeed there and configured as per the settings we defined earlier in our configuration.

At this point, you can safely power-on the appliance and proceed with normal setup processes.  Also, as I noted earlier, you can take all of these variables and create a PowerShell script to deploy your appliances with and just add/remove/change variables as needed per appliance!  Automation at its finest!

Well, I’d like to thank you for stopping by and supporting my page.  I do hope that you have found this information useful, and hope you’ll return again.  Thanks much and I’ll catch you on the next one!

-virtualex-

Welcome, and thanks for visiting my blog!

In this post, I am going to cover how to enable NFS v4.1 on a Synology device and then mount and NFS v4.1 datastore in VMware vSphere 6.5.  By default, Synology devices support NFS v4 natively, and although they can also support NFS v4.1, it is not enabled.  Well, not to worry because I am going to show you just how to enable the feature on your device.

NFS v4 and v4.1 have been around for quite a few years but it has not taken off then way NFS v3 did way back when.  There were some major flaws pointed out with NFSv4 so NFSv4.1 was created to rectify those flaws, and VMware was one of the first major companies to adopt and support the new Network File System.  But unless your storage device supported the newer NFS versions, you would be stuck mounting NFSv3 volumes by default.

In this demo, I will be using my new replacement Synology DiskStation DS415+ and my homelab “datacenter” running the latest version vSphere 6.5.  So let’s jump right in!

Using a terminal application like PuTTY, connect to your Synology device via SSH using an admin user account.  This can be the default “admin” account and any new user account with Administrator privileges.  Once connected enter the following command to change the directory:

cd /usr/syno/etc/rc.sysv

Once in this directory, run the following command (enter the account password if prompted):

sudo cat /proc/fs/nfsd/versions

This will show us the current NFS version currently enabled and supported by the Synology device. 

We can see that all versions prior to 4.1 have a “+” sign next to them and 4.1 has a “-” sign next to it.  Let’s change that!

In order to change this, we will need to edit a shell (S83nfsd.sh) file using “vi”.  Run the following command to open the file with VI Editor:

sudo vi S83nfsd.sh

This will open the shell file and will place the cursor at Line 1, Character 1 as depicted in the following screenshot.  

Navigate down to line 90 using the down arrow and you will see the following line of text.

This is where the magic happens!  To edit the file now, press the “I” key on your keyboard to initiate an “Insert” then add the following to the end of the text so the line looks like the following screenshot.

-V 4.1

To commit and save this change, first press the Esc key.  Next type the following command and hit “Enter” to write and then quit vi editor.

:wq

 

 

Next, we need to restart the NFS service.  To do so enter the following command:

sudo ./S83nfsd.sh restart

 

If we again run the following command, we will see that there is now a “+” sign next to 4.1.  Hooray!

sudo cat /proc/fs/nfsd/versions

 

Now that we have enabled NFSv4.1 functionality on your storage device, let’s go ahead and mount an NFS volume to our hosts in vSphere.

I have enabled NFS and NFS v4 support then created the following shares with assigned permissions on my device, and am going to mount the ISOs share first in this example by issuing a command via PowerCLI.  We can also see that I do not have any NFS mounts currently in my environment

I’ve launched PowerCLI and connected to my vCenter Server using the Connect-VIServer cmdlet then issued the following command:

Get-VMHost | New-Datastore -Nfs -FileSystemVersion '4.1' -Name SYN-NFS04-ISOs -Path "/volume3/NFS04-ISOs" -NfsHost DS415 -ReadOnly

*Note:* an important argument here in the “-FileSystemVersion”.  If I do not specify the version, it will assume version 3.0 by default.

If I go back and look at my datastores via the Web Client, I can see that my new NFS 4.1 datastore has been mounted to each one of my ESXi hosts. Nice!

*Bonus:* If I’d like to easily remove this datastore from all of my hosts, I can issue the following command via PowerCLI.

Get-VMHost | Remove-Datastore -Datastore SYN-NFS04-ISOs -Confirm:$false

Now I can see that the host has been removed successfully!

Well, that about wraps this one up.  I hope that this has been useful and informative for you and I’d like to thank you for reading!  Until next time!

-virtualex-

**NOTE: This is completely for experimental purposes and is unsupported by both Apple and VMware**

Hello all!  This is just a quick follow up to my previous guide on running macOS 10.12 Sierra on ESXi 6.x, where I have now successfully updated the VM to macOS 10.13 High Sierra.

If you simply try to run the upgrade via a self-made ISO, or via the Mac App Store, the final image will fail to boot.  The reason being is because starting with macOS 10.13, Apple has converted the file system from Hierarchical File System Plus (HFS Plus orHFS+) to the new Apple File System (APFS).  During the upgrade process, the HFS+ will be converted to APFS, and the unlocker utility which allows us to even run a macOS VM on ESXi doesn’t support APFS.  In fact, support for ESXi, in general, is no longer available in the latest Unlocker 2.1.1 so I am still using the Unlocker 2.1.0 for ESXi, and Unlocker 2.1.1 for VMware Workstation 14.

For this quick tutorial, I am using the latest VMware ESXi 6.5 Update 1 Build 7388607 and I started by simply cloning my macOS 10.12 VM to a new virtual machine.

Once powered on, go to the Mac App Store and download the macOS High Sierra installation.  When the download is complete, DO NOT run the installer and quit it instead.  You will now have the installer application available in your Applications folder.

Now, open a Terminal session and enter the following command as one line.  Depending on the account you’re are logged in with, sudo may or may not be needed.

sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/startosinstall --converttoapfs NO --agreetolicense --nointeraction

The key argument here is the “–converttoapfs NO” which prevents the OS from converting the drives file system format from HFS+ to APFS.  Additionally, the “–nointeraction” argument is optional.

Now sit back, relax, and let the upgrade do its thing.  When the upgrade is complete, the VM should have successfully booted up and you will now be running macOS High Sierra.

-virtualex

Pingbacks:

• https://ithinkvirtual.com/2017/02/12/create-macos-os-x-vm-on-vmware-esxi-6-5-vmware-workstation-12-x/

Having a backup solution is imperative in any IT environment, whether it be Production or a simple Home Lab like I have.  There are many different brands and companies that offer backup solutions, such as Veeam or Nakivo, to name a few.  But I personally like to stick with the VMware product line so that I can build the necessary skills and knowledge of their software, required to successfully grow and advance my career.  My personal choice, and preferred backup solution, is VMware vSphere Data Protection (VDP) since it’s fairly simple to deploy, configure, and manage.  

VDP is a robust, simple-to-deploy, disk-based backup and recovery solution that delivers storage-efficient backups through patented variable-length deduplication, rapid recovery, and WAN-optimized replication for disaster recovery (DR).  Plus, it’s vSphere-integration and simple user interface makes it an easy and effective backup tool.  Additionally, it is now bundled with vSphere Standard, Enterprise Plus, and vSphere with Operations Management Enterprise Plus by default.

Since I have recently rebuilt by personal home-datacenter, I opted to deploy VDP 6.1.3 in my environment.  Version 6.1.3 was released back in November 2016, and just recently, version 6.1.4 was released on March 16, 2017.  Of course, as I always like to be on the latest and greatest versions of software, I just had to upgrade my appliance.  So before starting any upgrade, I always like to refer to the official documentation for upgrade procedures and best practices, but I wasn’t really able to find anything out there on the “inter-webs”.  So I figured, “what the heck, why not just give it a go and make my own documentation?”.  Not only will this be beneficial to me, but I hope that it will also help others in the community who’d like to update their appliances as well.  Let’s get to it!…

Prerequisites:

• Snapshot of your current VDP appliance

If you do not take a snapshot, you will be prompted to do so before you’re even allowed to perform the upgrade.

As previously mentioned, I will be upgrading my appliance from 6.1.3 to 6.1.4.

Begin by taking a snapshot of your current appliance, then attach the VDP Upgrade .ISO media to the appliance.

Login to the application’s web UI and click on the Upgrade tab.  It should automatically detect the presence of the ISO and begin reading it for updates but if it does not, click the Check Upgrades button.  Allow up to 15 minutes or more for the scan to complete before you can proceed with the upgrade.

Once the appliance has detected the available upgrade, click on the upgrade version to select it, then click the Upgrade VDP button.

If you had not taken a snapshot prior to upgrading the appliance, you will be presented with the following, hence the reason I listed this step as a prerequisite.

The upgrade process will now begin by first preparing the package for installation, which can take about 15 minutes or so, so now would be a good time to grab a beer or some coffee!

Afterwards, the actual installation will begin and you shall see the following set of instructions.

From my experience, I did not see the progress bar complete to 100%.  Instead, it disconnected itself from the web UI.  I realized that this meant it was beginning to stop its services and shut itself down.  

Before having come to this realization, I tried to reload the web UI but would simply get a blank screen.

Eventually, I took a look at the VDP appliance console I had previously opened, and noticed the appliance was indeed powered off.   I confirmed by also checking the current status via the Web Client.  This is a good sign as the instructions stated the appliance will shut itself down after the upgrade has completed.

So now that the appliance was shutdown, the instructions explicitly stated to delete the snapshot before restarting the appliance.  Normally, I would wait until after to machine has booted up successfully before I delete a snapshot, just in case something went wrong, but in this case VMware stated this for a reason so I went ahead and deleted the snapshot.

It also stated to reconfigure the disk mode for any disks used by the VDP datastore to “Independent-Persistent”.  I went ahead and checked and saw that it was already set to that mode by default so I didn’t have to change anything there.

Finally, I booted up the appliance and to my delight, the appliance was now running version 6.1.4!  This turned out to be easier than expected!  

I’d like to thank you for reading, and hope that you’ve found this content to be useful.  Please rank this post, feel free to comment, and subscribe to my blog!

 

-virtualex

For the last 6+ months, I haven’t had much time to dedicate to my home lab and overall home network.  Between holidays, transitioning to a new employer/role, and everyday life getting in the way, I found that I had to put everything on the back burner for a bit…so I inevitably shutdown by home lab. Well now I am back and am looking forward to writing up some new material that I have been meaning to do for a while.  I will start this by saying this is a continuation of my Home Lab 2016 Series, now being dubbed as “Home Lab 2017“!

So first and foremost, I powered up my home lab once again and I intend to leave it up and running at 100% uptime.  While doing so, my Synology NAS decided to reboot itself for an auto-update, right in the middle of a VM’s (my domain controller to be exact) boot process.  This would eventually cause my VMDK file to become corrupted and I could no longer boot my DC and reconnect my home lab.  I also had not yet backed anything up since the environment was still fairly new so I figured why not take this opportunity to rebuild everything and get some new components.

I decided to add a few more (3 per host to be exact), extremely quiet, Noctua NF-A4x10 FLX 40mm  fans.  This will help to keep my ATOM CPU cool as well as exhaust any hot air from out of each case.  I had also been contemplating on doing a Network equipment overhaul.  Last year I upgraded my ASUS RT-AC68U SOHO Router with a Ubiquiti ERLite-3 EdgeRouter, and turned the ASUS into a wireless AP only.  I do not have a single complaint in the performance and overall stability of that setup.  But I recently began looking at the Ubiquiti UniFi gear, and noticed that it the Unified Security Gateway basically runs the same EdgeOS found in the ERLite-3, just with a different web-interface.  Realizing that we are in this new wave of cloud-managed networking, and seeing that the USG-3P was basically on-par with the ERLite-3, I bit the bullet and ordered my new Ubiquiti UniFi gear to replace my current setup.  The featureset in the EdgeRouter series of routers still has the edge over the UniFi’s features but it’s only a matter of time before they are equal, or UniFi surpasses the EdgeRouters.

I decided on the following products:

• UniFi Controller Cloud Key (UC-CK)
• UniFi Security Gateway (USG-3P)
• UniFi Switch 8-60W (US-8-60W)
• UniFi AP-AC-Pro (UAP-AC-Pro)

After getting everything connected, I will say that I was extremely impressed with the ease of setup, current feature set, and the presentation of the Web UI.  I am not going to go into the specifics of how to set it all up, etc. as this is not a UniFi tutorial, but I will say that the little quick start guides tell you everything you need to know.  One can also consult “Mr. Google” for more information.  

My only gripe with the current feature set of the USG-3P is that there is no support for Jumbo Frames…yet!…but hopefully that will come in a future firmware release.  The US-8-60W does indeed support Jumbo Frames so I enabled in on there at least for now.  Additionally, the VOIP LAN port on the USG-3P is there for a future release to add support for it.  I have also read some threads were feature requests have been submitted to allow said port to be used as a secondary LAN/WAN port instead of just for VOIP.  This is currently in beta, but once these settings are added, I feel it would bring the device closer to the capabilities of the ERLite-3 in terms of features. Only time will tell…

Now that I had my basic home network configured, LAN & WiFi-LAN, I powered on my Cisco lab switches and began migrating all of my VLANs over to the new USG-3P, thus removing the need for any static routing which I relied on with my previous setup.  Next, I powered on all of my hosts, and began upgrading them to ESXi 6.5.  Finally, I was finally on my way to getting up to the latest release of vSphere!  Once all of my hosts were upgraded, with the exception of my dev-host as the CPU is not supported in ESXi 6.5, I began spinning up a few new VMs.  I took this time to install Windows Server 2016 for my Domain Controllers, and decided to ditch the Windows-based vCenter server in favor of the vCenter Server Appliance (vCSA) since it now has vSphere Update Manager (vUM) integration and the appliance runs on VMware’s Photon OS.

Once my vSphere environment was minimally setup, I started to deploy some more VM’s with the vSphere Web Client, and I must say the speed and performance of the Web Client in 6.5 is “night-and-day” as compared to the Web Client in 6.0!  Nore more need for the Client Integration Plugin as the newer version for 6.5 runs as a service.  This is the way the web client should have been designed from the very beginning instead of making us all suffer because of how slow the Flash-based version previously was.  Although I always preferred to use the Web Client because of the features within it, I can see why so many users still used the C# “fat-client” instead.  Who wants to wait forever and a year just for the Hosts and Clusters view, or VM’s and Templates view to load?!?!?  I know that I dreaded the loading times.  Currently, my vSphere lab consists of the following machines…for now.

• 2 – Domain Controllers (I’ve learned my lesson and the consequences of only having one DC…)
• 1 – vCenter Server Appliance
• 1 – vSphere Data Protection Appliance
• 1 – Windows 10 Management Jumpbox
• 1 – IP Address Management Server (phpIPAM)
• 1 – Mail Server (hMailServer)
• 1 – WSUS Server
• 1 – SCCM Server ( I am currently teaching this to myself and may eventually leverage SUP, thus replacing/repurposing my current WSUS server)
• 1 – vRealize Configuration Manager (vCM) Server ( I am also teaching this to myself as to become more familiar with the product and its capabilities)
• 1 – OpenVPN Appliance

So now that my Home Lab has been upgraded and completely rebuilt, I look forward to spending more time tinkering with it and putting it to good use for exam studies and personal knowledge.  I am dedicating my Sundays as “Home Lab Fun-days”!  Thanks for stopping by and I hope you enjoyed the read! Please comment below and subscribe!