Category: PowerCLI (Page 1 of 2)

New Release: PowerCLI 11.4.0

New version of  PowerCLI released version 11.4.0

Heres a brief breakdown of the updates included:

PowerCLI 11.4.0 comes with the following updates:

  • Add support for Horizon View 7.9
  • Added new cmdlets to the Storage module
  • Updated Storage module cmdlets
  • Updated HCX module cmdlets

Dont forget its easy to update your powercli version (see below)

1
Update-Module VMware.PowerCLI

And finally heres a link to the vmware article with all the info https://blogs.vmware.com/PowerCLI/2019/08/new-release-powercli-11-4-0.html?src=so_5a314d05e49f5&cid=70134000001SkJn

New Release: PowerCLI 11.0.0

New version of  PowerCLI released version 11

Heres a brief breakdown of the updates included:

  • Added a new Security module
  • Added new cmdlets for Host Profiles
  • Added a new cmdlet to interact with NSX-T in VMware Cloud on AWS
  • Support for vSphere 6.7 Update 1
  • Support for NSX-T 2.3
  • Support for Horizon View 7.6
  • Support for vCloud Director 9.5
  • Multiplatform support for the Cloud module
  • Updated the Get-ErrorReport cmdlet
  • Removed the PCloud module
  • Removed the HA module

Dont forget its easy to update your powercli version (see below)

1
Update-Module VMware.PowerCLI

 

And finally heres a link to the vmware article with all the info

https://blogs.vmware.com/PowerCLI/2018/10/new-release-powercli-11-0-0.html

vCloud Identifying Chain Linked VM’s

Currently working on a project to decommission a very old non updated vcloud infrastructure for a customer who wants to move back to vsphere. They don’t really utilize the full vCloud feature set as it was put in as part of a larger project that never came to fruition.  Part of the first step should be to see what chain linked virtual machines we have, as if not when we attempt to migrate them away we are just going to give ourselves a world of pain. The PowerCLI below should identify all the virtual machines within the VDC’s and how long the chain length is.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
if( (Get-Module -Name "VMware.VimAutomation.Cloud" -ErrorAction SilentlyContinue) -eq $null)

{Import-Module VMware.VimAutomation.Cloud}

Connect-CIServer -Server "your vcloud director fqdn" -ErrorAction Stop

$VApps = Get-CIVApp

Foreach($vapp in $VApps){

$vms = $vapp.ExtensionData.children.vm

foreach($vm in $vms){

$CL = $vm.VCloudExtension.any.VirtualDisksMaxChainLength

if($CL -gt 1){

$info = $vm.Name + " chain length=" + $CL

$info}

}}

Perennial Reserved RDM’s

I got asked a couple of days about why an esxi server was taking roughly 45 mins to come back up after a reboot. Looking at the node when it eventually came back up showed that it had a number of RDM’s that were associated to virtual machines. Those virtual machines were mostly Windows RDM’s  used for MSCS. What was happening is that when esxi was booting it could see all theses luns and was trying to read the header, it was that delay in its attempts to read the header that was causing the 5 min boot time.

What was needed was to reserve those luns so that they were ignored on the boot scan. Using the powercli below we can define the target cluster, scan through the virtual machines within an identify all the raw devices and mark then as reserved.  It will then do this on each nodes in the cluster which reduced your boot time from say 45mins to a few minutes (depending on your hardware)

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$TargetCluster = "Cluster Name"

$VMhosts = Get-Cluster $TargetCluster| Get-VMHost

$RDMDisks = Get-VM -Location $TargetCluster | Get-HardDisk -DiskType "RawPhysical","RawVirtual" | Select ScsiCanonicalName

foreach($VMhost in $VMhosts) {
Write-Host "Connected To Server : " $VMhost
$esxcli = Get-ESXCLI -VMHost $VMhost
foreach($RDMDisk in $RDMDisks) {
Write-Host "Setting Perennially Reserved On : " $RDMDisk
$esxcli.storage.core.device.setconfig($false, ($RDMDisk.ScsiCanonicalName), $true)
}
}

New Release: VMware PowerCLI 10.1.0

A New version of PowerCLI has been released today to support the recent releases of vSphere 6.7/ vSAN 6.7 and NSX-T 2.1.

It includes the 20th module  vmware.vim that we can use to work with API’s in VMware on AWS so that should be something to look into later.

If like me and run via a Linux Powershell then to update the  PowerCLI modules all you need to do is the following (via the powershell prompt):

1
Update-Module VMware.PowerCLI

Heres a link to the VMware article that talks about some of the new features:

New Release: VMware PowerCLI 10.1.0

 

PowerCLI Deploying 6.5u1 vCSA

Deploying vCSA in 6.5 normally means that you need to run through the manual process using your web browser. However there is another method,  vcsa-deploy.exe if you like the idea of having it scripted as a re-usable configured deployment.

I though i would give this a try using the following script i have put together for the recent 6.5u1 vCSA release.

The vcsa-cli-installer\templates folder hosts all the templates that can be selected and you can tailor your modified .json file by adding/removing attributes as required (however don’t forget the options depend on the template you will be using)

“new.vcsa”: {
         “esxi”: {
                   “hostname”: “”,
                   “username”: “root”,
                   “password”: “”,
                    “deployment.network”: “VM Network”,
                    “datastore”: “ESXi host datastore, or a specific datastore in a datastore cluster.>”

The script below will deploy a vCSA to esxi host 192.168.1.5, the deployment used will be an install (you could script migrate/upgrade) and use the database tiny option (as we are managing 10 or less hosts), it has been told all the relevant IP details to configure and the datastore it will be placed on.

Don’t forget the memory requirements, even a tiny vCSA required 10GB of RAM.

You of course need to be connected by a connect-viserver to the ESXi node to run

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Convert JSON file to PowerShell object
$configconfig = "D:\VMware-VCSA-all-6.5.0-8024368\vcsa-cli-installer\templates\install\embedded_vCSA_on_ESXi.json"
$deploy = "D:\VMware-VCSA-all-6.5.0-8024368\vcsa-cli-installer\win32\vcsa-deploy.exe install --accept-eula --acknowledge-ceip "
$UpdatedConfig = "D:\VMware-VCSA-all-6.5.0-8024368\config.json"
$config = (Get-Content -Raw $configconfig) | ConvertFrom-Json

# vCSA system information
$config."new.vcsa".os.password="VMw@re123"
$config."new.vcsa".sso.password = "VMw@re123"
$config."new.vcsa".sso."site-name" = "Default-Site"

# ESXi Host Information
$config."new.vcsa".esxi.hostname="192.168.1.5"
$config."new.vcsa".esxi.datastore="Datastore1"
$config."new.vcsa".esxi.username="root"
$config."new.vcsa".esxi.password="VMw@re123"
$config."new.vcsa".esxi."deployment.network"="VM Network"
$config."new.vcsa".appliance."deployment.option"="tiny"
$config."new.vcsa".appliance.name="MGMT-vCSA65u1"

# Networking
$config."new.vcsa".network.mode = "static"
$config."new.vcsa".network.ip = "192.168.1.25"
$config."new.vcsa".network.prefix = "24"
$config."new.vcsa".network.gateway = "192.168.1.1"
$config."new.vcsa".network."dns.servers"="192.168.1.1"
$config."new.vcsa".network."system.name"="MGMT-vCSA65u1.local"
$config | ConvertTo-Json | Set-Content -Path "$UpdatedConfig"
iex "$deploy $UpdatedConfig"

 

PowerCLI Disconnect CD Drives

So today we hit that old chestnut of an issue , you go and try and Storage vMotion a load of VM’s, when you get an error you realise that they had CD Drives connected.

You have two options manually go through through each VM and unmap the drive or a quick bit of PowerCLI to solve the problem.

First we do a quick check of the VM’s and see whats connected and to what:

1
Get-VM | Where-Object {$_.PowerState –eq “PoweredOn”} | Get-CDDrive | FT Parent, IsoPath

 

If there are none that we require lets set them all to “No Media

1
Get-VM | Where-Object {$_.PowerState –eq “PoweredOn”} | Get-CDDrive | Set-CDDrive -NoMedia -Confirm:$False

 

There we go, we can now do the Storage vMotion’s without issues.

PowerCLI 10 On A Raspberry PI

First things first I am a big fan on the raspberry PI and have more or less every iteration scattered around the house doing different jobs. In fact i tend to use one for access to my home lab using either a ssh session or via xrdp to a nice xfce session via tightvnc (maybe thats for another blog post).

However running PowerCLI on it never occurred until recently.  So i though why not try it so here goes..

Assuming your running Raspbian Stretch on a PI 3

Microsoft have kindly given some nice instructions on how to install PowerShell on the Raspberry PI and others at: Microsoft Link (I made a change to the below as we need version v6.0.1)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Install prerequisites
sudo apt-get install libunwind8

# Grab the latest tar.gz (Changed as PowerCLI needs v6.0.1)
wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.1/powershell-6.0.1-linux-arm32.tar.gz

# Make folder to put powershell
mkdir ~/powershell

# Unpack the tar.gz file
tar -xvf ./powershell-6.0.1-linux-arm32.tar.gz -C ~/powershell

# Start PowerShell
~/powershell/pwsh

This gets up PowerShell up and running now all we need to do is install the PowerCLI modules. Again VMware this time have provided some instructions at VMware Link

1
2
#Install PowerCLI Module
Install-Module -Name VMware.PowerCLI -Scope CurrentUser

It Takes a little while to run, then you need to give it permission to do the install (Press Y)

And that is it, we can now use PowerCLI from our Raspberry PI

PowerCLI Enable SSH On A Host

Must admit there comes a time when you need to enable SSH on an ESXi host and i for one find navigating the GUI a bit time consuming and to be honest not really necessary.

To that matter using good old PowerCLI we can enable ssh on a host with a very simple command line

1
Get-VMHost HostName | Get-VMHostService | Where Key -EQ "TSM-SSH" | Start-VMhostService

And then once we are finished its good practise to disable SSH once again.

1
Get-VMHost HostName | Get-VMHostService | Where Key -EQ "TSM-SSH" | Stop-VMHostService -Confirm:$False

 

PowerCLI VMtools Update on Reboot

Easy task for today was to set all the virtual machines to auto update the VMware tools on next reboot, we could of course manually use the webclient on each virtual machine but that is a bit time consuming, so we may as well use some PowerCLI to get the job done.

Here is some quick code to do the job.

1
2
3
4
5
6
7
Foreach ($VMS in (Get-VM)) {
$VM = $VMS | Get-View
$VMConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$VMConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$VMConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"
$VM.ReconfigVM($vmConfigSpec)
}

 

 

 

 

« Older posts