A quick PowerCLI one liner to locate VMs with thick-provisioned disks attached.
I was lucky enough to take delivery of some new ESXi hosts recently. After installing them in the datacentre, I wanted to test that the network had been patched correctly. This environment is going to have Distributed vSwitches configured, but I wanted to test the physical connectivity before joining them to vCenter- have the physical NICs been patched to the correct networks?
PowerCLI to the rescue! I put together some code which automates this process. Provided with a hostname and a list of NICs and targets which should respond, the code fires off a ping for each interface in turn and reports back with success/fail messages.
For each NIC it creates a temporary switch, portgroup, and VMkernel interface:
Then the esxcli functionality is used to ping a given target address:
Once the test is complete, the temporary virtual network components are removed.
The full code is available for download (and potential improvement) on GitHub.
VMware vSphere 6.5 comes with a RESTful API implementation and there’s some great documentation out there- starting with the API Explorer (http://my.vcenter.name/apiexplorer ). Here’s a quick piece on how to use this API to create a VM from the PowerShell command line. This is intentionally not using PowerCLI, just the native PowerShell cmdlets- partly as a REST learning experience for me, and partly so the API code can be transferred to another language at a later date.
This step is well documented by Chris Wahl. I’ve borrowed some of his code here, and accompanied it with a section to get around the lack of trusted certificates on my homelab. 192.168.0.240 is the IP of my VCSA, so if you’re reusing this anywhere remember to replace that hard coded value where it appears.
Now we have the Session ($session) we can test this by retrieving a list of VMs.
To create a new VM we need to provide a minimal spec for the machine, in JSON format. We need to tell it the intended Guest OS, what datastore is going to hold the VM, and where the VM will be placed in the resource/folder structure. To complete this we need to establish what options are available- just sticking in the display names of a datastore or folder from the Web Client will not work and will likely generate 404 responses to the API call.
To find these names we can use the API, API explorer gives us the following urls
So we can use PowerShell to retrieve a list of Datastores using this line of code
which will produce a list of datastores, each looking something like this:
From this example we want the value of the “datastore” field, e.g “datastore-11”.
Once we have this information we can combine it all to create a JSON spec file. My example looks like this:
Now we’ve done all this prep work, creating a Virtual Machine comes down to a single line of PowerShell pointing at the data.txt file containing the JSON code from Step 2.
The VM is created and we can check this from the vSphere Client:
So, to summarise. Native PowerShell, with a little bit of JSON, can be used to communicate with the vSphere APIs and create new Virtual Machines. Depending on your use case there may be better ways of implementing automation processes through this API (PowerCLI is a good start) but if you want to drop to the raw RESTful API, possibly as a stepping stone to a larger project, PowerShell provides a handy method to get started down that path.
With a list of Surnames in a text file I wanted to see how many start with A, how many with B, and so on. This is my PowerShell solution:
Example Input (surnames.txt file):
Using the manage-bde command you can check the Bitlocker encryption status on both the local Windows computer but also remote devices on the local area network. For example, to check the encryption status of the C: drive on the computer “WS12345” the following command could be used
and the results might look something like this:
Expanding on this we could wrap some PowerShell around the command and read in a list of hostnames from a text file and report on the encryption status of each.
Firstly we need to format the output of manage-bde to only show us the value of the “Conversion Status” field- PowerShell’s string manupulation can come in handy here- we can locate the “Conversion Status” line, check that it is present (if the computer is not on the network, or access is denied the manage-bde command will not return a status), and then trim back the line so we only have the value of the field. For example:
Once this is working, it’s just a case of reading in the text file using the get-content cmdlet and outputting a result. The full code (Get-EncryptionStatus.ps1) I used is available for downloading and/or improving on GitHub here- https://github.com/isjwuk/get-encryptionstatus