$vms = get-civm
$objects = @()

foreach($vm in $vms)
{
 $hardware = $vm.ExtensionData.GetVirtualHardwareSection()
 $diskMB = (($hardware.Item | where {$_.resourcetype.value -eq "17"}) | %{$_.hostresource[0].anyattr[0]."#text"} | Measure-Object -Sum).sum
 $row = New-Object PSObject -Property @{"vapp" = $vm.vapp; "name"=$vm.Name;"cpuCount"=$vm.CpuCount;"memoryGB"=$vm.MemoryGB;"storageGB"=($diskMB/1024)}
 $objects += $row
}

# Use select object to get the column order right. Sort by vApp. Force table formatting and auto-width.
$objects | select-Object name,vapp,cpuCount,memoryGB,storageGB | Sort-Object -Property vapp | Format-Table -AutoSize

You can easily export to a CSV by using Export-CSV or just run the report to get output that looks something like this:

In this case, my client needed to set default security permissions for all new VDPortgroups that were created by vCloud Director. This is different than setting security on a single portgroup. This sets the defaults for ALL portgroups created after the setting change! This is very handy when the network creation is out of our hands.

I’ve written about getting around the missing dvPortgroup inheritance in the past, and there are also a couple good posts from Luc Dekens and Alan Renouf:

http://geekafterfive.com/2011/04/04/dvportgroup-inheritance/

http://www.lucd.info/2009/10/12/dvswitch-scripting-part-2-dvportgroup/

http://blogs.vmware.com/vipowershell/2011/11/vsphere-distributed-switch-powercli-cmdlets.html

Last but not least, special thanks to William Lam for pointing me to the right spot in the API.

What’s different?

1. Typed Values - Metadata must now be put into a certain type. No more throwing random junk into a single metadata entry.
2. Domain and Visibility – Providers now have the ability to provide System metadata entries on objects, which is not editable by users. Providers can additionally make the metadata private, meaning the users cannot see the System metadata on the object at all.
3. Objects – Metadata can now be added to new vCloud Director 5.1 objects, including disks and storage profiles. Additionally, I believe that because OrgVDC networks are now user manageable, vCloud users can add their own metadata to networks.

For more instruction on Metadata in the vCloud API, read “Working with Object Metadata” in the vCloud Programming Guide.

PowerCLI 5.1 R2 example:

There are times when a snapshot doesn’t cut it, and asking the Backup Administrator or Cloud Provider to set up backups doesn’t make sense. Just a couple examples I’ve run into as a Cloud Provider:

• Upgrades with testing could take longer than a snapshot should exist for.
• Temporary workloads may need backups for “warm storage”

So where is the in-between? Wouldn’t it be great to hot clone a VM or VApp with some light scheduling and retention capabilities?

vCloudBackups is the Powershell module for doing this.

The vCloudBackups powershell module allows you to create local backups of VMs and vApps at any cloud provider running vCloud Director 1.5 or 5.1. By local, I mean the VMs and vApps will currently be cloned to the same storage the workloads are currently running on. If you don’t trust your SAN with this level of backup, you probably need to talk to you Backup Administrator or cloud provider for that off-site backup.

How does it work?

Very simply, the module is just doing hot-clones of VMs or vApps through the vCloud API. When backing up just VMs, they are stored inside a vApp simply called ‘Backups.’ Each VM backup is named with the vApp origination, VM name, and a date/time of the backup.

VApp backups are simply just exact copies of the originals, except named titled as Backup with a date/time of the backup.

“Retention” is built into the module as a number to keep. The oldest will automatically be deleted.

Scheduling is accomplished through your Windows Task Scheduler and an included script called MyBackups.ps1. Credentials for your vCloud Director login are stored encrypted in a configuration file, meaning NO PLAIN TEXT PASSWORDS!

If you are interested in the vCloud Backups script, please contact me on Twitter, Google+, or the comments below.

You will find all the new 5.1 API properties and methods in the .extensiondata of objects such as a VM returned by Get-CIVM. Snapshots come to mind as a frequent request. Here’s how to find them:

The .extensiondata property is really the same object as you would get from the Get-CIView cmdlet.

So, lets say we wanted to find out what new fancy 5.1 VM snapshot properties and methods are available to us:

From this,  we see that we now have the ability to automate the creation, removal and revert of snapshots in vCloud Director 5.1!

Creating, Reporting on, and Removing snapshots is now easy!

Let’s check out another one. Edge Gateways are new in vCloud Director 5.1. How do we find those without any new cmdlets? Search-Cloud!

Search-Cloud returns a search object, and from this we can get the .NET object with all the properties and methods.

Note that we don’t have to use the .extensiondata, because we used Get-CIView to directly get the .NET object.

Let’s check out the .configuration!

Both the vCloud Admin and Tenant PowerCLI snap-ins have been updated, so if your cloud provider is running on 5.1, enjoy the new features!

Now, this is certainly not all PowerCLI 5.1 R2 has to offer.  Powershell 3 support as well as an official VDS snap-in are also available! You can read more about these updates on the Official PowerCLI Blog! For tons of VDS examples, See Alan’s post!

There is not a New-CIUser cmdlet *yet*, but I’ll show you the way you can do it now!

We’ll need 3 things: A username, a password, and a role.

To get the role we want to assign the user, we’ll need to use Search-Cloud:

This will give us a list of roles. Pick a role name. As an example, I want to add an Org admin, so I am going to run this:

The previous line queried for the role, retrieved the role object using Get-CIView and assigned it to the $role variable.

Congrats, that was the hardest part… on to the good stuff!

We need to do two things next… Get our Org object, and create a new user object:

Now we assign the fun stuff to our user object (name, password, role)!

and finally, we push the user object to our Org:

So that’s it! Probably 10 lines of code and we have a new user. The secret is really in the .extensiondata of the objects like $org.

A challenge for a lot of vCloud Providers is training the vCloud users. The current training available is for running your own vCloud Director environment, and what little there is  for the vCloud users is mixed with provider level stuff as well. This can be very confusing for the users, as you can imagine.

I am thrilled to say that TrainSignal now has will soon be coming out with a course specifically tailored to vCloud Users!

The course focuses on using vCloud from an Organization perspective. It includes real world examples, best practices, and pitfalls that I’ve fallen in so you don’t have to! In addition, you’ll learn about some cool tools available to users that integrate with a vCloud Organization.

If you are a provider: Contact the TrainSignal team to inquire how you can provide this course to your vCloud users.

If you are a user: Pass this info along to your vCloud Provider, or you can simply purchase the course!

Shout outs to Sean and the rest of the TrainSignal team for all the hard work making my first authored course a reality!

If you want to play with snapshots in PowerCLI, you’re going to need the module in this blog. PowerCLI 5.1 currently only supports the vCloud API 1.5, which means there are no 5.1 API capabilities yet. (I stress “yet.” )

The module uses the current PowerCLI for it’s session and API access, and then bolts on some 5.1 API snapshot magic.

To use the module, simply download the .psm1 file and:

Import-Module vCloudSnapshots.psm1

After that, you’ll have access to 4 cmdlets:

Get-CISnapshot
New-CISnapshot
Remove-CISnapshot
Set-CISnapshot

To get snapshots:

# Get vApps with Snapshots
Get-CIVapp | Get-CISnapshot

# Get VMs with Snapshots
Get-CIVM | Get-CISnapshot

# Get Snapshot info for a particular VM
Get-CIVM "MyVM" | GetCISnapshot

It should be noted that all the cmdlets apply to a VM or vApp, so always make sure you’re doing a Get-CIVM or Get-CIVapp first.

For example…here’s creating, reverting, and removing:

# Create a snapshot for a vApp (or all VMs in the vApp, really.)
Get-CIVApp "MyVApp" | New-CISnapshot

# Revert to our snapshot
Get-CIVApp "MyVApp" | Set-CISnapshot -revertToCurrent

# Remove our snapshot
Get-CIVApp "MyVApp" | Remove-CISnapshot

For more help, just use Get-Help and the command!

vCloud Snapshots Powershell Module

The session is entitled Automating Bare Metal to the Cloud and Beyond.

In this session, Eric will demonstrate the use of PowerCLI and UCS PowerTool to quickly deploy your own cloud infrastructure with a single script. (Amazing!)

After the cloud is built, I will share how real world examples of how Bluelock uses PowerCLI from a provider standpoint. From on-boarding new clients to gathering performance statistics, PowerCLI is a big part of the automation strategy at Bluelock.

It doesn’t end there! I will also share how vCloud Organization users and admins are using PowerCLI for reporting and automation of the public and hybrid cloud! You’ll see some cool examples of how PowerCLI can best the vCloud Web UI!

Alan will be sharing some great PowerCLI learning resources as well, making this session not one to be missed.

So what are you waiting for? Go sign up!

To do this, OVFtool simply requires a source (VMX or OVF), and a destination (a vCloud Locator).

The vCloud locator looks something like this:

vcloud://username:password@host:port?org=name_of_org&vapp=name_of_deployed_vapp&catalog=name_of_catalog&vappTemplate=name_of_vapp_template_in_catalog&vdc=name_of_vdc

As you can see, the vCloud Locator is a URL with all of the information needed to upload your OVF.

Because OVFtool is run from the command line, the simple choice when using Windows is to use the command prompt. Using the Windows command prompt, however, results in errors when uploading to vCloud Director:

ovftool error

This is most likely because of the special characters ovftool uses in the URL (&, :, ?, @). If I had to guess, I’d say it’s the ampersand.

I tried quoting out the vCloud Locator several different ways to get it to understand, but resorted to Powershell to save the day once again.

$vCloudLocator = "vcloud://jake:password@vcloud.example.com:443?org=jake&vappTemplate=MyTemplate&catalog=private"

$sourceFile = "C:\jake\MyVM.vmx"

$ovftool = "C:\Program Files\VMware\VMware OVF Tool\ovftool.exe"

& $ovftool $sourceFile $vCloudLocator

Powershell treats the characters are part of the string, so we just simply pass the string as a parameter to OVFtool.

Hope this saves someone a headache!

For more OVFtool fun, check out my post on using OVF tool with PowerCLI with your vSphere session!