Change vCloud vApp/VM Storage Profile with PowerCLI

VMware has done a lot to open up the APIs for vCloud with the 5.1 release, however it still leaves much to be desired. One of the nicer things is the ability to change a storage profile for a VM. However, you need to know the HREF for the storage profile that you want to change to. This wasn’t so easy to get (I would love to be able to use a “get-storageProfile” PowerCLI cmd-let), but thankfully, Jake Robinson (@jakerobinson) and the VMware Community to the rescue:

http://communities.vmware.com/message/2163559#2163559

This script uses PowerCLI for Tenants (which cannot be installed on the same box running the ‘regular’ PowerCli). Taking his prompt to build an XML file from an HTTP GET to a vCloud HREF, we can retrieve storage profiles from any OrgvDC you have rights to. From this XML, we can assign a storage profile to a VM (or in this case, every VM in a vApp) based on it’s name and the Org you’re logged into. I modified his script a little bit, because if we pass an Org to the function, we don’t get the storage profiles, but if we pass an OrgvDC HREF, we automatically get the storage profiles (because storage profiles are assigned to Org vDCs and not globally to an Org). This reduces the number of function calls needed.

All this script needs is your vApp name and desired Storage Profile name.

What this also addresses is the ability to migrate all vCloud VMs off of the “*Any” Storage Profile.

# This function does a HTTP GET against the vCloud 5.1 API using our current API session.
# It accepts any vCloud HREF.
function Get-vCloud51($href)
{
 $request = [System.Net.HttpWebRequest]::Create($href)
 $request.Accept = "application/*+xml;version=5.1"
 $request.Headers.add("x-vcloud-authorization",$global:DefaultCIServers[0].SessionId)
 $response = $request.GetResponse()
 $streamReader = new-object System.IO.StreamReader($response.getResponseStream())
 $xmldata = $streamreader.ReadToEnd()
 $streamReader.close()
 $response.close()
 return $xmldata
}

# This function gets an OrgVdc via 1.5 API, then 5.1 API.
# It then returns the HREF for the storage profile based on the $profilename and

function Get-storageHref($orgVdc,$profileName)
{
 $orgVdc51 = Get-vCloud51 $orgVdc.Href
 $storageProfileHref = $orgVdc51.vdc.VdcStorageProfiles.VdcStorageProfile | Where-Object{$_.name -eq "$profileName"} | foreach {$_.href}
 return $storageProfileHref
}

# Get vApp, Storage Profile and OrgvDC names

$vappName = read-host "vApp name"
$profileName = read-host "Storage Profile"
$orgVdcName = read-host "Org vDC Name"

$orgVdc = get-orgvdc $orgVdcName

#Get storage profile HREF

$profileHref = Get-storageHref $orgVdc $profileName

# Change each VM's Storage Profile in the vApp

$CIvApp = Get-CIVApp $vappName
Foreach ($CIVM in ($CIvApp | Get-CIVM)) {
 $newSettings = $CIVM.extensiondata
 $newSettings.storageprofile.name = "$profileName"
 $newSettings.storageprofile.Href = "$profileHref"
 Write-Host "Changing the storage profile for $CIVM.name to $profileName"
 $newSettings.UpdateServerData()
}

PowerCLI Mass Add Hard Disks to Virtual Machine

While doing some iSCSI LUN testing for a certain storage vendor, I was looking for a way to add multiple hard disks to a single VM across each iSCSI LUN whose name matched a certain pattern. In my case, all luns I was testing against had the full lun path in their name so the were similar to lun1.naa.600144f0dcb8480000005142553e0001 (thanks to Alan Renouf’s post “PowerCLI: Mass provision datastore’s” for guidance on  scripting datastore creation).

However, I do not have all luns mapped to every vSphere host. Easy enough to get around this in PowerCLI. The following script prompts for the Virtual Machine name, size and hard disk format. Then filters the datastores by that VM’s vSphere host and our common string in the datastore name.


$vmname = read-host "VM Name to add disks to"

$vm = get-vm $vmname

$size = read-host "Disk Size (GB)"

$format = read-host "Disk Format (thin, thick, EagerZeroedThick)"

$datastores = $vm | Get-VMHost | Get-Datastore | Where-Object {$_.name -like "lun*naa*"}

foreach ($item in $datastores){
$datastore = $item.name
write-host "Adding new $size VMDK to $vm on datastore $datastore"
New-HardDisk -vm $vm -CapacityGB $size -Datastore $datastore -StorageFormat $format
}

There are a lot of parameters for the New-HardDisk cmdlet that I don’t specify because the defaults were what I already wanted (e.g. Persistence, Controller, DiskType, etc.). Some, like StorageFormat which defaults to Thick Lazy Zeroed, I wanted to control.

In another case, I wanted to add multiple disks from one datastore to a vm.


### Get VM/Disk Count/Datastore information ###
$vmname = read-host "VM Name to add disks to"
$num_disks = read-host "number of disks to add"
$ds = read-host "Datastore to place the VMDK"
$format = read-host "Disk Format (thin, thick, EagerZeroedThick)"
$size = read-host "Disk Size (GB)"

$vm = get-vm $vmname
$datastore = get-datastore -name $ds
$x=0

### Add $num_disks to VM
while ($x -lt $num_disks){
write-host "Adding $size VMDK to $vm on datastore $datastore"
New-HardDisk -vm $vm -CapacityGB $size -Datastore $datastore -StorageFormat $format
$x++
}

You can read more about the New-HardDisk cmlet at:
http://www.vmware.com/support/developer/PowerCLI/PowerCLI51/html/New-HardDisk.html

VMs Grayed Out (Inaccessible) After NFS Datastore Restored

[Added new workaround]

While working with a customer last week with Mike Letschin, we discovered an issue during one of their storage tests. It wasn’t a test that I’d normally seen done, but what the heck, let’s roll.

“What happens to all the VMs hosted on an NFS datastore when all NFS connectivity is lost for certain period of time?”

Well, turns out, it depends on a couple things. Was the VM powered on? How long was the NFS datastore unavailable for?