iThinkVirtual™

Install PowerShell and VMware PowerCLI on Ubuntu

| 04/03/2018 | Tags: , , , ,

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 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

Install PowerShell and VMware PowerCLI on macOS

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

Deploy A Virtual Appliance Using PowerCLI

| 04/02/2018 | Tags: , , ,

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-

vSphere…Synology…NFS v4.1

| 31/12/2017 | Tags: , , , ,

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-