My Real-World VCAP Scenario to test scripting

I’ve been racking my brains thinking of a real-life VCAP-esque scenario that would force me to write a PowerCLI script.

I know Josh Andrews offered up “create 100 powered off VMs with a certain config or clones of an existing template” which is good but not something I’d normally do in my role.  Then one came to me.  So here it is

*****Disclaimer.  I have not sat the VCAP-DCA yet so have no visibility of the questions.  This question is based on a real-life scenario from my work but modified a bit.  It’s main purpose is to test/teach you PowerCLI so you get the hang of the main components of a basic vSphere PowerCLI script.  *****


Scenario 1

Your company has reviewed storage use and found that a large amount of storage has been taken up by a group of VMs with names starting VMP.
Upon further inspection an engineer identifies that the pagefiles ARE on a separate drive, which is a the secondary virtual disk, but they are using Tier1/Premium storage.
Your storage team identify sufficient space on Tier2 storage and present an empty LUN which is visible to all your hosts.

You need to ensure that page files on the existing VMs are on Tier2 storage.
A new LUN has been presented with identifier naa.6001405df3d2046d4a02d3fe4db20bd5
Use iSCSI01 as the new datastore name and  use host to create the lun from.
All secondary vmdks were created using the default naming convention.
1) Create a datastore on the new LUN
2) Migrate all VMs second virtual disk for the VMP* VMs to the new LUN

This isn’t rocket science and on a small number of VMs you could easily drag and drop in the GUI. But let’s say it’s 100 VMs or 1000.  Then you really want to be getting home some time today!
Breaking down the first step.  We have a host and a device identifier for the lun.  We have a host to create it from and we have a name for the new datastore.  If some of these weren’t given then they could be found using Get-ScsiLun -vmhost

new-datastore -vmhost -name iSCSI01 -path “naa.6001405df3d2046d4a02d3fe4db20bd5” -vmfs -FileSystemVersion 5

Our Datastore is created.  You can watch that happen in vSphere client if you like.

Now we need to move all the secondary disks.
We know the VMs are all named with the prefix VMP
We know that their secondary disk follows the default naming convention.  e.g. vmname_1.vmdk
We know they need to be moved to Datastore iSCSI01

This snippet stores the name of the Datastore in one variable and then stores the harddisk details for any VMs hard disk where the VMname matches VMP* and the hard disk filename matches *_1*
It then invokes the move hard disk cmdlet to actually relocate the vmdks.

$myDS = get-datastore -Name “iSCSI01”
$myDisk = get-vm | where-object {$ -like “VMP*”} | get-harddisk | where-object {$_.filename -like “*_1*”}
move-harddisk -harddisk $mydisk -datastore $myDS

As seen from the command line, I notice I need to add a -Confirm $false to the New-Datastore command to stop the interactive prompt 🙂

And viewed from VI Client


So there we have it.  To make it a standalone runnable script, simply add 2 lines to the top.  One to add the Powershell Snapin for vSphere automation.  Then connect to a vCenter server.

add-pssnapin vmware.vimautomation.core
connect-viserver vc

$newLun = get-scsilun -vmhost | Where-Object {$_.canonicalName -like “naa*”}
new-datastore -vmhost -name iSCSI01 -path “naa.6001405df3d2046d4a02d3fe4db20bd5” -vmfs -FileSystemVersion 5

$myDS = get-datastore -Name “iSCSI01”
$myDisk = get-vm | where-object {$ -like “VMP*”} | get-harddisk | where-object {$_.filename -like “*_1*”}
move-harddisk -harddisk $mydisk -datastore $myDS -Confirm $false

I left out the bit where it took me an hour to see the iSCSI Lun because the networking on my virtual hosts went screwy…!  But otherwise it felt like a productive night!



4 thoughts on “My Real-World VCAP Scenario to test scripting

  1. One thing I do often is run scripts to search for stale snapshots (easy) and also VMs which need disk consolidation. On the consolidate ones, I start consolidation automatically.

    The more we use VM integrated backups, the more this one bites me. Not sure if it would be applicable to VCAP or not though.

    Liked by 1 person

  2. Hi Lee, yes snapshots are a bugbear of mine too. I might write a BOFH* style scenario where
    “The CIO saw a VMware presentation/PDF that stated that best practice on snapshots is to keep them no longer than 72hrs. Set up a scheduled task to run on your vcenter to remove any snaphots older than 72hrs”
    Also yes the guys who deal with VDR/VDP have had tons of hassle with leftover snaphshots from failed/stalled backup jobs.

    Good example!



    • Depends on how the cmdlet is coded, some will accept pipeline/array input. I did start out with a foreach but whilst I was parameterising it I think I just put it in to test and it worked 🙂
      Will maybe do a get-help -detailed tonight to check

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s