Storage vMotion Powershell script will not iterate through list of Vms sequentially on a datastore after first Storage Vmotion completes

[glezama]

I have adapted a powershell script to login to a vcenter with admin credentials then iterate through all the VMs sequentially on a particular datastore(A) and move them to datastore(B) against a Vcenter 6 appliance and a ESXI 6 host.

The script ensure that the Storage Vmotion for a VM is complete before it iterates to the next VM in the list

The script works successfully for the the first VM to be processed but it is not signalling that the Storage Vmotion for the first VM is complete. So the script never moves on to the second VM in the list.

1. What could be the error stopping iteration through the list of Vms?
2. The script is a few years old. Is there a better way to do this currently?

# Customized from script found at https://communities.vmware.com/thread/455209

# Script uses the cmdlet 'Storage-Vmotion' from the above thread and cmdlet 'Get-VIeventPLus' found at

#  http://www.lucd.info/2013/03/31/get-the-vmotionsvmotion-history/

# Load PowerCLI cmdlets 

Add-PSSnapin VMware.VimAutomation.Core -ErrorAction "SilentlyContinue" 

# Define vCenter User and target Datastore 

$vcHost = 'VCENTER' 

$vcUser = 'VCENTER_ADMIN' 

$vcPass = 'PASSWORD'

$svmSource = 'SOURCE_DATASTORE'   

$svmTarget = 'DESTINATION_DATASTORE' 

# Ignore is there is an invalid certificate (this is for use in the lab and not production)

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

# Connect to vCenter 

Connect-VIServer $vcHost -User $vcUser -Password $vcPass 

# Get VMs (pass array of VMs to $VMs from the source datastore) 

$VMs = get-datastore $svmSource | Get-VM 

Write-Host $VMs 

Storage-Vmotion -VMname $VMs -DesitinationDatastore $svmTarget 

[LucD]

The Storage-Vmotion function has a flaw in that it checks at the end (the Do-Until construct), for the VmMigratedEvent.

But it looks at events since $date, adn that is the date before the first svMotion.

So all subsequent svMotions will not wait in that Do-Unitl loop, since the script will find the VmMigratedEvent from the 1st svMotion.

To fix this, the $date variable needs to be calculated inside the ForEach loop (over the VMs) and before the Move-VM.

[TheVMinator]

I have the same question - I'm hoping to find an example of a fully baked storage vmotion script that effectively waits for the vmotion event for each VM to complete until the next one starts. 

Has anyone taken a crack at fixing this bug or could attempt to do so and post your results?

[TheVMinator]

LucD - would be very interested to get your opinion on this - what if - instead of using an event to do this, we used a task?  Would that make it easier?  For example if I did something like this:

$vms = get-vm

foreach ($vm in $vms ){ 

               $task = move-vm -vm $vm -Datastore datastore2 -ErrorAction Stop -RunAsync            

               while($true)

               {

                    Start-Sleep 5                 

                    $LocalTask = Get-Task -Id $task.Id  

                    If($LoTask.State -eq 'Success') {

                        break

                    }    

               }         

               }

Basically - we are capturing the task ID of the initial move-vm operation - then continuing to check vcenter until the status of that task ID is 'success'

If the goal is to not start the second vm until the 1st is completely svmotioned, can using a "task" like this instead of an "event" accomplish the same thing more easily or is there a gotcha in that approach? 

Would definitely be interested to know if you know of problems with checking the status of the task as opposed to checking for an event...

Thanks again!

[LucD]

To make it clear, there is no issue in checking for an event, it is the Storage-Vmotion function that has a flaw.

This is a user written function.

For waiting for the end of the vMotion, the event or the task are equivalent.

You can pick either method.

[TheVMinator]

LucD , much appreciated - it does seem the method above is quite simple so if there are no gotchas to it I'm going with the task approach.  Thanks again!