IT Partners Blog

I’ve been meaning to write this post for a long time.  That’s nothing special since there are several posts that I’ve been meaning to write for quite a while.  As a quick aside, I have to highlight that I have a great deal of respect for @DuncanYB, @FrankDenneman, @scott_lowe, and the countless other bloggers who manage to post quality technical content just about every day – consistently and continuously.  Honestly, I don’t know how they do it.

Ever since the Windows Powershell cmdlets for VI3 were released, in the VMware community, there has been a friendly rivalry between the Perl and Powershell camps — I seem to recall an epic VMworld 2010 air hockey battle between @lamw (Perl) and @alanrenouf (Powershell):

Perl vs. Powershell - Epic Air Hockey Battle - Photo from @mattliebowitz

I realize that there are other ways to access the vSphere API these days, including Java, C# (via the vSphere Web Services SDK), and even Ruby (and a VMware Labs fling here).  Unfortunately, I lack experience with those versions, so I will restrict this post to Perl and Powershell.  If you’re interested about the SDKs in general, more information is available on VMware’s support site.

My Experience

Before I begin, I’d like to tell you a little about me so you know where I’m coming from.

Perl

I have been using Perl for various tasks since 1993 when I picked up a copy of Learning Perl (“the llama book”) by Randal Schwartz  so I could more easily manage a website I was working on at the time.  I had a slightly more scenic road than your average Perl novice since I was learning Perl on a Macintosh. Before they were UNIX-based or even had a command line. Fun? If you’ve ever embedded Hypercard XCMDs in a Perl script, you know what I’m talking about. I published something in 1998 when the AutoStart 9805 worm was running rampant on Macs around the world.  My code was not pretty, but the first version was written in an afternoon and did what I needed it to do.

Powershell

I did not encounter Powershell until 2008 when the VMworld scripting lab team offered me the opportunity to assist in developing the material.  Originally, I agreed because I thought my Perl experience would be helpful and I wanted to spend some time digging around the VI API.  As it turned out, there were already some Perl ninjas on the team and more help was needed with the Powershell material.  I am no @alanrenouf, but I spent many late night hours playing with both plain Powershell and the VMware add-ons so I could understand how the language was put together.  I learned a lot during those days, and even more helping attendees in the labs.

Bias?

I don’t feel that I have a language bias either way, and I tend to develop in whichever language is supported on the target platform(s).  Sure, I can run Perl on a Windows machine, but it still feels unnatural when Powershell is available natively.  Likewise, if it makes more sense to run a certain script from the vMA or from my Mac, I’ll use Perl.  I’ve spent some time on the VMware Community Forums translating from Perl into Powershell and vice versa.  You can do it!

Maybe it is just my perception because I learned Perl first, but I discovered that any significantly complex Powershell script looks a heck of a lot like Perl.  I’ll demonstrate this later.

Perl vs.(?) Powershell

As a team for the scripting lab, we came up with the (crazy?) idea to fork the single 2008 scripting lab into Perl and Powershell options that worked through the same exercises.  The cool thing was that I was able to experience both methods of accessing the virtual infrastructure to accomplish our defined tasks — attendees could go through the lab twice, or switch between languages as well.

While coding and testing the solutions to our lab exercises, it became clear that either language could be used to perform whatever action we required, and the complexity varied based on availability of Powershell cmdlets or pre-existing scripts and understanding of the API.  Some tasks were dead easy in Powershell but quite painful in Perl. Believe it or not, some tasks were easier in Perl because navigating the API’s object structure is common practice in Perl and just felt wrong in Powershell.  At least, until you got the hang of it.

Cmdlets and Scripts

From a Powershell perspective, the cmdlets included with the VMware Infrastructure Toolkit for Windows (now known as vSphere PowerCLI) provide convenient shortcuts for common actions.  The old VMware Infrastructure Perl Toolkit (now vSphere SDK for Perl), includes some pre-written scripts for performing common actions.  The added benefit of the Perl SDK is that the code for the scripts is available so you can see how they work, copy them, tweak, and repurpose as needed.

Interactivity

Hands down, PowerCLI provides superior interactivity.  Before you think I’m bashing Perl, let me explain.  Powershell was designed differently than Perl: it is an interactive shell that allows batch execution of commands while Perl is an interpreted language.  Think of Powershell more like your traditional command interpreters like csh, bash, ksh, or even (dare I say it?) DOS.

When using the Perl SDK, a per-script binding is created with the virtual infrastructure (login), the code is executed, and the binding is destroyed (logout).  Because Powershell is an interactive shell and PowerCLI extends that, a binding can persist beyond the lifetime of a single script’s execution.  In fact, it is possible to interact with the environment via that binding by executing cmdlets against the objects within the environment, accessed via the persistent binding or bindings.  Don’t misunderstand, it is possible to do some of this using the Perl SDK, but that’s not how it is normally used. Perl is like a swiss army knife or duct tape: if you can dream it, you can probably make Perl do it — thank you Larry Wall!

Along these lines, I noticed that VMware has grouped their various APIs and SDK-related tools according to the intended audience:

A Simple Example

All of that talk about theory and technical differences… but no code yet.  Who’s bored?  Okay, here comes my first set of examples.  In this one, based on exercises from the VMworld US 2008 Scripting lab, we compare the task of getting a list of all development VMs registered in a vCenter and report their current power state. To make things manageable, each development VM has the string “DEV” in its name:

Powershell

$vc = Connect-VIServer -Server MYVC
Get-VM *DEV*
Disconnect-VIServer -Server $vc -Confirm:$false

Perl

#!/usr/bin/perl -w
# Import runtime libraries
use strict;
use warnings;
use VMware::VIRuntime;
use VMware::VILib;

# Read and validate command-line parameters
Opts::parse();
Opts::validate();

# Connect to the server and login
Util::connect();

# Perform the requested action
my $List = GetVmByName('DEV');
PrintVmPowerState($List);

# Close server connection
Util::disconnect();

##############################################################################

sub GetVmByName {
  my $vmname  = shift;
  return Vim::find_entity_views(
  view_type => 'VirtualMachine',
  filter => {
    name => qr/$vmname/i
  });
}

sub PrintVmPowerState {
  my $vms = shift;
  foreach my $vm (@$vms) {
    print "Virtual machine " .
    $vm->name . " power state is: " .
    $vm->runtime->powerState->val . "\n";
  }
}

To execute this script, it needs to be saved into a file and called:
perl GetVmByName.pl --server MYVC --username MYUSER

That may look very complicated, but, to be fair, the only code that needs to be written is the two subroutines (under the line of hash marks, pound signs, capital 3′s … whatever you want to call them) and their calls from the main program.  The rest is a template created to handle the setup and teardown of the vSphere API connection.  I’ve also taken care to make this script readable – Perl ninjas can shrink this thing down to a few lines if that sort of thing is important.

So, what does that mean?

In the labs, we had several people come in without any scripting experience.  I was totally impressed – it was fantastic to see so much interest in scripting among the VI administrator community.  When we asked whether they were interested in Perl or Powershell scripting, we were asked most of the time for a suggestion.  We came up with one simple question:

1. What operating system(s) are you most comfortable with and which do you intend to use for running your scripts?

If the answer was Linux or MacOS we’d suggest Perl, otherwise we suggested Powershell.  We found that Powershell was much more accessible to people who had never written scripts before.  Sure, writing “hello world” in either Perl or Powershell is just as trivial, but accessing the vSphere API can be more daunting in the Perl world than Powershell’s simple Connect-VIServer cmdlet followed by Get-VM.  More success faster = happier new users.

What do I do?

I don’t keep the vSphere API in my head – I swear that @lamw does! I would probably be able to knock out a Perl script to do whatever I wanted pretty quickly if I spent a lot of my time writing that kind of code, but I forget things if I don’t use them regularly.  At this point in my life, I have few development responsibilities, so I may have short periods of scripting with LONG periods of other work in between.  Like many of you, I am typically looking for a quick, simple script to report on or change some aspect of my environment.  I need to be able to dust off my scripting brain and crank out the report. For that, PowerCLI works very well.

Better Together?

Looking back on my recent work, I noticed something interesting:  when I need to understand how an object “looks” in the API, I regularly jump to the PowerCLI console, even if I am going to write the final script in Perl.  Why would I do that?  The answer goes back to the interactivity of Powershell.  Sure, I could fire up a web browser and go to the vSphere API Reference or even go to the Managed Object Browser (MOB), but there is something about the command line that just feels better to me: I can see how my script will see the objects, minus any translation or filtering.

Examples

Reporting

In this case, I want to take a look at an Advanced Setting on my VMs to ensure that it is set properly. Setting it properly would be nice, too. Once I understand how the object is constructed and how I can access that data, I can construct either Perl or Powershell code to access the object.  Here, the vSphere API Reference or MOB are good for getting an idea of where I should look, but I like to poke around on my own sometimes just to see what’s out there.

My example VM is called “MYVM” and we’re looking at the “isolation.tools.paste.disable” setting. Here’s how I find it:

Powershell

PowerCLI C:\> $vmView = Get-VM MYVM | Get-View
PowerCLI C:\> $vmView

Capability           : VMware.Vim.VirtualMachineCapability
Config               : VMware.Vim.VirtualMachineConfigInfo
Layout               : VMware.Vim.VirtualMachineFileLayout
…

PowerCLI C:\> $vmView.Config

ChangeVersion                : 2011-12-20T16:10:43.434877Z
Modified                     : 1/1/1970 12:00:00 AM
Name                         : wintest2
GuestFullName                : Microsoft Windows Server 2008 R2 (64-bit)
Version                      : vmx-07
…
ExtraConfig                  : {nvram, virtualHW.productCompatibility, pci…
CpuFeatureMask               :
…

PowerCLI C:\> $vmView.Config.ExtraConfig

Key                           Value
---                           -----
nvram                         wintest2.nvram
virtualHW.productCompatibi... hosted
pciBridge0.present            true
sched.scsi0:0.throughputCap   off
disk.EnableUUID               true
pciBridge4.present            true
snapshot.action               keep
deploymentPlatform            windows
… (that's a LONG list... let's filter it!)

PowerCLI C:\> $vmView.Config.ExtraConfig | ? {$_.Key -like "isolation*"} | ft -a

Key                                  Value
---                                  -----
isolation.device.connectable.disable true
isolation.tools.connectable.disable  true
isolation.tools.copy.disable         true
isolation.tools.diskShrink.disable   true
isolation.tools.diskWiper.disable    true
isolation.tools.dnd.disable          true
isolation.tools.paste.disable        true
isolation.tools.setGUIOptions.enable false
isolation.tools.setinfo.disable      true

I now know that the value of the “isolation.tools.paste.disable” Advanced Setting is accessible on my VM at the following location: VM->Config.ExtraConfig[isolation.tools.paste.disable]  For the sake of this example, we’ll assume that the key is present and set to something (true).

Perl

I know I may take some heat from the Perl purists who know that they can achieve the same result using Perl SDK and some simple print/printf or Data::Dumper commands, but the above process is how I tend to work.  (For more information on using Data::Dumper with vSphere, you can go here.) Armed with an understanding of where the data that interests me lives, I can create some Perl code to perform the appropriate query in the same manner.  Note the process is pretty much the same as in Powershell:

1. Obtain a View of the VM
2. Grab the Config->extraConfig property
3. Find the key(s) in question
4. Print the value(s) associated with the key(s)

# Connect to the server and login
Util::connect();

my $vm_name = 'MYVM';
my $check_key = 'isolation.tools.paste.disable';
my $vm_view = Vim::find_entity_view(
view_type => 'VirtualMachine',
filter => {'name' => qr/$vm_name/i}
);

my $extraConf = $vm_view->config->extraConfig;

foreach(@$extraConf) {
  my $vm_key = lc($_->key);
  if($vm_key =~ m/$check_key/) {
    print "$vm_key\t" . lc($_->value) ."\n";
  }
}

# Close server connection
Util::disconnect();

Making Changes

Making changes is a little more difficult, but looks even more similar between languages:

Perl

my $vm_name = 'MYVM';
my $vm_view = Vim::find_entity_view(
  view_type => 'VirtualMachine',
  filter => {'name' => qr/$vm_name/i}
);

my $virtualMachineConfigSpec =
  VirtualMachineConfigSpec->new (
    extraConfig => [OptionValue->new(
      key => 'isolation.tools.paste.disable',
      value => 'true' ),] );

$vm_view->ReconfigVM( spec => $virtualMachineConfigSpec);

Powershell

$vmView = Get-VM MYVM | Get-View

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.extraConfig += New-Object VMware.Vim.optionvalue
$vmConfigSpec.extraConfig[-1].Key = "isolation.tools.paste.disable"
$vmConfigSpec.extraConfig[-1].Value = "true"

$vmView.ReconfigVM($vmConfigSpec)

I hope this is useful, or at least interesting for people to see. If you made it this far, thanks for reading!

{ 0 comments }

This is a continuation of Storage Migration with (and without) RDMs, part I

As of the last posting, we had identified the need to migrate a batch of vSphere 4.1 VMs configured with physical mode RDMs (pRDMs) from one storage array to another.  During this process, we decided that it would be nice to convert the (legacy) pRDMs to VMDKs in order to conform to the customer’s new standard configuration.

Doing them one at a time can be a lot of work, is error-prone, and I’m lazy when it comes to tasks that can be scripted.  There had to be some way PowerCLI could be brought to bear. What follows is our solution. Note that relocating and converting the pRDM to a VMDK must be done with the VM powered off. The script will check for that and let you know.

I based the following function (heavily) on Set-ThinDisk from the VMware vSphere PowerCLI Reference: Automating vSphere Administration.  You can get it on Amazon(US) here. I probably could have put this together without their framework, but it would have taken much longer and been nowhere near as elegant.

function Convert-RdmToVmdk { 
<#
.VERSION
   1.1 - 12/19/2011
.SYNOPSIS
   Converts an physical mode RDM to a thick provisioned VMDK hard disk
.DESCRIPTION
   Makes a thick provisioned copy of an RDM disk on a new
   datastore and configures the virtual machine to use the thick
   provisioned copy
.NOTES
   Author: Doug Baer
   Inspiration: Automating vSphere Administration by Luc Dekens,
             Arnim van Lieshout, Jonathan Medd,
             Alan Renouf, Glenn Sizemore
.PARAMETER HardDisk
   Specify the hard disks you want to convert
.PARAMETER datastoreName
   Specify the name of the datastore which will host the VMDK(s)
.PARAMETER credential
   A PSCredential object used to authenticate the VMHost server
.PARAMETER user
   The user account used to authenticate the VMHost server
.PARAMETER password
   The password for the account specified by the -User parameter
.PARAMETER replace
   Optional parameter to delete the original thick file
.EXAMPLE PS> Get-VM VM001 | Get-HardDisk | Convert-RdmToVmdk -Credential `
                  $hostCred -datastoreName "MyNewDatastore"
.EXAMPLE PS> $hd = Get-VM VM001 | Get-HardDisk | `
                 ?{$_.Name -eq "Hard disk 2"}
         PS> Convert-RdmToVmdk -hardDisk $hd -user "root" -password `
                "password" -replace  -datastoreName "MyNewDatastore"
#>

   Param ( 
      [parameter(valuefrompipeline = $true, Mandatory = $true, HelpMessage = "Enter a hard disk entity")] 
         [VMware.VimAutomation.ViCore.Types.V1.VirtualDevice.HardDisk]$hardDisk, 
      [Parameter(Mandatory = $true, HelpMessage = "Enter the target datastore name")] 
      [ValidateNotNullOrEmpty()] 
         [string]$datastoreName,
      [Parameter(Mandatory = $true, ParameterSetName = "cred", HelpMessage = "Enter a PSCredential object")] 
         [System.Management.Automation.PSCredential]$credential, 
      [Parameter(ParameterSetName = "user")] 
      [ValidateNotNullOrEmpty()] 
         [string]$user = "root",
      [Parameter(Mandatory = $true, ParameterSetName = "user", HelpMessage = "Enter the root account password")] 
         [string]$password, 
         [switch]$replace) 
   
   process { 
      if ($hardDisk.Parent.PowerState -eq "PoweredOff") { 
         if ($hardDisk.DiskType -eq "RawPhysical") { 
            Write-Host "...Connecting to host $esxhost"
            if ($credential) { 
               $esxHost = Connect-VIServer -Server $hardDisk.Parent.host.name -Credential $credential -NotDefault
            } else { 
               $esxHost = Connect-VIServer -Server $hardDisk.Parent.host.name -User $user -Password $password -NotDefault 
            }
            $vmdkFile = $hardDisk.Filename -replace ('\[.*\]',"[$datastoreName]")
            $datastore = $hardDisk.Filename.split('[')[1].split(']')[0] 
            $esxHardDisk = Get-HardDisk -server $esxHost `
               -Datastore $datastore `
               -DatastorePath $hardDisk.Filename
            Write-Host ("Copying RDM@ " + $hardDisk.Filename + "`n`t to VMDK " + $vmdkFile)
            Copy-HardDisk -HardDisk $esxHardDisk `
               -DestinationPath $vmdkFile `
               -DestinationStorageFormat "thick" | Out-Null 
            Write-Host "...Disconnecting from host $esxhost"
            Disconnect-VIServer $esxHost -Confirm:$false
               
         # Change the VM to use the VMDK instead of the pRDM
         $spec = New-Object VMware.Vim.VirtualMachineConfigSpec
         $spec.deviceChange = New-Object `
            VMware.Vim.VirtualDeviceConfigSpec[](2)
         $spec.deviceChange[0] = New-Object `
            VMware.Vim.VirtualDeviceConfigSpec 
         $spec.deviceChange[0].operation = "remove" 
   
         if ($replace) { 
            $spec.deviceChange[0].fileOperation = "destroy" 
         } 
   
         $spec.deviceChange[0].device = $hardDisk.ExtensionData 
         $spec.deviceChange[1] = New-Object VMware.Vim.VirtualDeviceConfigSpec 
         $spec.deviceChange[1].operation = "add" 
         $spec.deviceChange[1].device = New-Object VMware.Vim.VirtualDisk
         $spec.deviceChange[1].device.key = -100 
         $spec.deviceChange[1].device.backing = New-Object VMware.Vim.VirtualDiskFlatVer2BackingInfo 
         $spec.deviceChange[1].device.backing.fileName = $vmdkFile
         $spec.deviceChange[1].device.backing.diskMode = "persistent" 
         $spec.deviceChange[1].device.backing.thinProvisioned = $false
         $spec.deviceChange[1].device.controllerKey = $hardDisk.ExtensionData.ControllerKey 
         $spec.deviceChange[1].device.unitNumber = $hardDisk.ExtensionData.UnitNumber 
         
         $vm = Get-View -Id $hardDisk.ParentID 
         Write-Host "...Reconfiguring VM to use VMDK"
         $vm.ReconfigVM_Task($spec) | Out-Null 
         } else { 
            Write-Host ("Virtual disk " + $hardDisk.Name + " is " + $hardDisk.DiskType + ", not a physical mode RDM")
         }
      } else {
            Write-Error "Virtual machine must be powered off" 
      }
   } #process
} #function

###

Note that the Copy-HardDisk cmdlet requires acting against a specific host, in vSphere 4.x, at least. I believe in vSphere 5.0, this requirement is gone and only the vCenter binding is required.

Once we created the host credential object (using Get-Credential) and connected to vCenter (using Connect-VIserver), we were able to use the function as follows:
Get-VM MyVM | Get-HardDisk | `
Convert-RdmToVmdk -Credential $hostCred -datastoreName "MyVMFSDatastore"
… as long as MyVM is currently powered off. This will walk through the Hard Disks attached to the VM and convert all of the encountered pRDMs to VMDKs on the datastore called “MyVMFSDatastore”.

To move different pRDMs to separate datastores, use something like the following:
$hd = Get-VM MyVM | Get-HardDisk | ?{$_.Name -eq "Hard disk 2"}
Convert-RdmToVmdk -hardDisk $hd -Credential $hostCred `
-datastoreName "MyOtherDatastore"


DISCLAIMER: As with any code, it is your responsibility to test the code’s suitability in your environment. I have successfully tested this function in our lab and have used it to migrate production workloads in a vSphere 4.1 environment — it works for me, but YMMV.

The Result
After running this script for each VM and powering them back up in the production environment, we manually cleaned up the old mapping files and un-presented the LUNs from the old array. So far, so good.

Issues?
When testing in my lab against a Windows 2008 R2 VM, I encountered an odd issue. Note that we did not encounter this in any of our production moves, and I have had a difficult time recreating it in the lab. However, I include it here in the event that someone runs into it — maybe it’ll save someone a little time.

The problem looked like this: Windows did not assign the drive letter back to the partition on the migrated disk and Disk Management console wouldn’t touch it. The error reported was, “The operation failed to complete because the Disk Management console view is not up to date.” I even tried using diskpart, but it wouldn’t even recognize that there was a partition on the disk. In my research of this issue, I turned up a lot of confused people on various support forums asking the same question, mostly with respect to removable drives.

The bottom line appears to be that Windows recognized a change in the device that confused the driver (kind of like the OS saying, “Hey, that’s not the same disk! What are you trying to pull here?” I came up with a workaround and what I think is a solution. Whatever you do, DO NOT FORMAT THE DRIVE!! — I don’t care what the articles on the forums say. (For the record, diskpart‘s clean [all] command is destructive) There were many, many people who formatted their disks while trying to figure this one out. I believe that ‘fixes’ the problem, but in a rather destructive way (i.e. you’ve got a working partition but no data).

Workaround
The workaround is to shut down the VM and change the SCSI ID of the VMDK — just bump it from SCSI0:2 to SCSI0:3, power up and Windows will recognize it properly (it won’t think you’re trying to pull something), mount the partition and assign the drive letter. Unfortunately, moving the VMDK back to the original SCSI ID resurfaced the problem.

Solution?
Digging around in Windows Device Manager when the VM exhibited the problem (I don’t love doing that) led me to what I think is a solution. In this instance, Windows apparently detected enough of a change in the disk to create another instance of a storage object, but only a partially functional one. Deleting this object and rescanning for new hardware (a good old-fashioned reboot would be best, of course) gave me my drive back.

Unfortunately (fortunately?) I was unable to duplicate the issue on demand in order to get a screenshot and record the ghost device’s name. In my various trials, the only ‘problem’ I could consistently create had to do with the VMDK-based drive needing to be ‘Onlined’ in Disk Management after the swap. Just be aware that it could show up — If I am able to re-create it, I will be sure to post screenshots here.

{ 0 comments }