rayvd
Enthusiast
Enthusiast

ClientSideTaskImpl returned from Set-VM with RunAsync

Background

I am writing a script to ensure that our vCenter is accepting and processing tasks in an acceptable amount of time.  The task I'm using as my "test" is a simple Set-VM task that updates the description (Note) for a VM.

My approach is to submit this task with RunAsync set to true, save the resultant $Task object then cycle through the output of Get-Task waiting until the task with matching $Task.Id is completed.  If the task doesn't complete after a certain amount of time passes, we are notified.

Our vCenter is running v4.1.

Problem

I initially wrote this script on an XP box w/ PowerShell 2.0 and PowerCLI 4.0 U1 Build 208462.  Everything works fine -- and still does in that environment.

The live version of the script, however, is slated to run on a Windows 2008 SP2 machine w/ PowerShell 2.0 and PowerCLI 4.1 U1 Build 266648.  In this environment, the script does not work correctly.  What appears to be happening is that the Task object returned by Set-VM is a ClientSideTaskImpl object.  This object has null values for almost everything (including Id) and its Uid is disimilar from the normal tasks I'd expect to see.

In short, this object is not useful to me when cycling through the output of Get-Task as far as comparisons are concerned.

Is this new behavior in PowerCLI 4.1 vs 4.0?  Should I be approaching the above differently?  How can I keep track of the task object from my Set-VM command and pull it out of the Get-Task list later with confidence?

Thanks for any insight.

Also ref this post which is about the only other information I could find out there from someone having a similar problem.  Oh and also this blog post comment.

0 Kudos
4 Replies
rayvd
Enthusiast
Enthusiast

FYI, updated to PowerCLI 5.0 build 435427 and the behavior remains.

0 Kudos
rayvd
Enthusiast
Enthusiast

Also can confirm that after updating my XP box to PowerCLI 4.1 U1, this "incorrect" behavior begins occurring.  This seems like a bug to me as I can't find anywhere where this behavior change was documented...

0 Kudos
LucD
Leadership
Leadership

You're seeing the typename change that was introduced in PowerCLI 4.1.

See the PowerCLI Teams blog post called Output type changes in PowerCLI 4.1

And yes, this is a problem with the script I posted in About Async tasks, the Get-Task cmdlet and a hash table

Let me check if I can find a bypass.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

rayvd
Enthusiast
Enthusiast

Hmm.  Not totally sure I quite follow how this has resulted in the behavior I'm seeing.  None of my scripts reference qualified namespaced objects.  I note the following...

4.0.1

The object returned by Set-VM -RunAsync:$true is  VMware.VimAutomation.Client20.TaskImpl.  This is the same type as the objects output by Get-Task.

4.1.x

The object returned by Set-VM -RunAsync:$true is VMware.VimAutomation.ViCore.Util10.Task.ClientSideTaskImpl whereas the object returned by Get-Task is VMware.VimAutomation.ViCore.Impl.V1.Task.TaskImpl.

It seems to me that Set-VM -RunAsync:$true should also return VMware.VimAutomation.ViCore.Impl.V1.Task.TaskImpl to mirror the behavior of 4.0.1.

Perhaps this is a side-effect of the namespace issue you described within the cmdlets?

Thanks for your reply.

0 Kudos