move-vm triggering unexpected storage vmotion

[lusid2]

After updated vCenter from 6.7U1 to the latest version, move-vm has started attempting to storage vmotion VMs to arbitrary datastores when I call it to move a VM into a vApp.  This often fails because the host doesn't have access to the datastore, and it will often pick a local datastore on some other host as the target.

PS C:\vlab> $VM=get-vm 'vm1'

PS C:\vlab> $vApp=get-vapp 'vapp1'

PS C:\vlab> move-vm $VM -destination $vApp

move-vm : 7/22/2019 1:33:53 PM  Move-VM         The operation for the entity "vm1" failed with the following message:

"Unable to access the virtual machine configuration: Unable to access file [zESX40SSD]"

At line:1 char:1

+ move-vm $VM -destination $vApp

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Move-VM], CannotAccessVmConfig

    + FullyQualifiedErrorId : Client20_TaskServiceImpl_CheckServerSideTaskUpdates_OperationFailed,VMware.VimAutomation

   .ViCore.Cmdlets.Commands.MoveVM

In this example it tried to move the VM to a local datastore on some other host, in this case a host in a completely different cluster.  If it had chosen a datastore the host could access, it would have triggered a storage vmotion.  Just to be clear, no portion of the VM is touching datastore "zESX40SSD".  Move-VM is just broken.

It should not be doing this, and it worked correctly as recently as vCenter 6.7U1.

[LucD]

I assume you mean vCenter 6.7U2?
Just tried with PowerCLI 11.3.0 and the Move-VM works without an issue.

What does the following return?

Is that perhaps the datastore the VM is being svMotioned to?

(Get-View -Id $vapp.ExtensionData.Datastore).Name

[lusid2]

ExtensionData.Datastore is empty, since the vApp contains no VMs.

If I use the vcenter GUI to place a VM into that vApp, it then returns the datastore containing the child VM, but that doesn't appear to impact the spurious svmotion behavior. 

[LucD]

Which VCSA and PowerCLI versions are you using?
And on which platform are you running the code? What does $PSVersionTable show?

[lusid2]

vCenter:  6.7.0.32000 Build 14070457

PowerCLI:  11.2.0.12483635

Code is running on Server2012R2:

PS C:\vlab> $PSVersionTable

Name                           Value

----                           -----

PSVersion                      5.1.14409.1005

PSEdition                      Desktop

PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}

BuildVersion                   10.0.14409.1005

CLRVersion                     4.0.30319.34209

WSManStackVersion              3.0

PSRemotingProtocolVersion      2.3

SerializationVersion           1.1.0.1

[lusid2]

After updating to 11.3.0, the behavior changed.  Now instead of getting a spurious svmotion, it will succeed on simple VMs, or it will generate an error message. 

In this example, the VM is touching 2 datastores.  The host has access to both datastores.  move-vm generates an error.  Then I isolate the VM to a single datastore and move-vm succeeds:

PS C:\vlab> get-vm test3

Name                 PowerState Num CPUs MemoryGB

----                 ---------- -------- --------

test3                PoweredOff 1        1.000

PS C:\vlab> get-vm test3 | get-datastore

Name                               FreeSpaceGB      CapacityGB

----                               -----------      ----------

install                                358.922       2,237.439

vLabs                                   99.998         100.000

PS C:\vlab> get-vm test3 | move-vm -destination vapp1

move-vm : 7/22/2019 3:23:47 PM  Move-VM         Object reference not set to an instance of an object.

At line:1 char:16

+ get-vm test3 | move-vm -destination vapp1

+                ~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Move-VM], VimException

    + FullyQualifiedErrorId : Core_BaseCmdlet_UnknownError,VMware.VimAutomation.ViCore.Cmdlets.Commands.MoveVM

PS C:\vlab> get-vm test3 | get-datastore

Name                               FreeSpaceGB      CapacityGB

----                               -----------      ----------

vLabs                                   99.998         100.000

PS C:\vlab> get-vm test3 | move-vm -destination vapp1

Name                 PowerState Num CPUs MemoryGB

----                 ---------- -------- --------

test3                PoweredOff 1        1.000

[LucD · Accepted solution]

I'm not convinced you are seeing spurious svMotions.

That is also not what the original error is saying.
It says the VM's config file could not be accessed.

After the upgrade, you are having problems when the VM is spread over 2 datastores.

Is that the case for all VMs that are using 2 or more datastores?

It could be that you are seeing something similar as in Move-VM doesn't work against new VCSA 6.7 instance

Testing with the API method might give an indication.

In the meantime, I'll try to do some additional tests and see if I can replicate the error you are seeing.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.

[lusid2]

I can't blame you for that.  The error message and the behavior don't align.  In the case where it picked an NFS datastore the host didn't have access to, the error message was the same.  Once I mounted the datastore on the host, and tried again, it didn't error out but it tried to vmotion the VM to that datastore instead.

But back on 11.3.0, another example of it not working was a VM with ~60 virtual disks.  I had to remove about 45 of them before move-vm would work on this VM.

I'll try the API back door.  It looks like less effort than reverting to 6.7U1.

[lusid2]

The API method does work.  Thanks!