Copy-VMGuestFile fails with error 500 when Guest OS is "Other"

[Nitzan_S]

Hello

When Guest OS is set to "Other" on a Windows VM the PowerCLI command "Copy-VMGuestFile" fails with error 500.

When changing the Guest OS type to Windows the command works.

On a Linux VM it does work when it's "Other".

Is there a way to understand why is it failing or how to solve it without changing the guest OS type?

Because changing it requires a shutdown of the VM.

Any advise would be appreciated.

Thanks.

[LucD]

Did you check if the vmware.log contains any additional information?

[Nitzan_S]

Thanks for the suggestion.
vmware.log had these 4 logs. Not very informative unfortunately:

2022-03-02T21:17:09.258Z| vmx| I125: VigorTransportProcessClientPayload: opID=8f410a9-dc-f33e seq=6275: Receiving GuestOps.ListFiles request.
2022-03-02T21:17:09.365Z| vcpu-0| I125: VigorTransport_ServerSendResponse opID=8f410a9-dc-f33e seq=6275: Completed GuestOps request.
2022-03-02T21:17:09.558Z| vmx| I125: VigorTransportProcessClientPayload: opID=4f71cbd6-b1-f348 seq=6286: Receiving GuestOps.InitiateFileTransferToGuest request.
2022-03-02T21:17:09.662Z| vcpu-0| I125: VigorTransport_ServerSendResponse opID=4f71cbd6-b1-f348 seq=6286: Completed GuestOperations request.

[LucD]

That at least shows that the correct methods are called.

I suspect that the VMware Tools, based on the GuestId, makes assumptions about the filesystem and the path separator.

Perhaps there is something in the vpxd log (but you might have to set the level to 'verbose' first)

[Nitzan_S]

Thanks @LucD, that's the hunch that I had as well.

Nothing useful in verbosed vpxd unfortunately:

2022-03-03T09:24:40.167Z verbose vpxd[04518] [Originator@6876 sub=Default opID=6c3ef3fd] [VpxVmomi] Invoking [initiateFileTransferToGuest] on [vim.vm.guest.FileManager:guestOperationsFileManager] session [52c9419b-aad6-6193-f4f7-3bb9a401edc9(528bdd1e-f724-7820-fb10-7daeba8ca431)]
2022-03-03T09:24:40.167Z info vpxd[04518] [Originator@6876 sub=vpxLro opID=6c3ef3fd] [VpxLRO] -- BEGIN lro-54326869 -- guestOperationsFileManager -- vim.vm.guest.FileManager.initiateFileTransferToGuest -- 52c9419b-aad6-6193-f4f7-3bb9a401edc9(528bdd1e-f724-7820-fb10-7daeba8ca431)
2022-03-03T09:24:40.167Z verbose vpxd[04518] [Originator@6876 sub=guestops opID=6c3ef3fd] [GuestOperationsManagerMo::PreProcessingModule] preprocessing vim.vm.guest.FileManager.initiateFileTransferToGuest
2022-03-03T09:24:40.167Z verbose vpxd[04518] [Originator@6876 sub=StateLock opID=6c3ef3fd] Attempting to lock vm-XXXXXX in mode SHARED
2022-03-03T09:24:40.167Z verbose vpxd[04518] [Originator@6876 sub=StateLock opID=6c3ef3fd] Successfully locked vm-XXXXXX in mode SHARED
2022-03-03T09:24:40.168Z verbose vpxd[04518] [Originator@6876 sub=proxyManagedObjectImpl opID=6c3ef3fd] Invoking vim.vm.guest.FileManager::initiateFileTransferToGuest with 6 params
2022-03-03T09:24:40.187Z verbose vpxd[04518] [Originator@6876 sub=Vmomi opID=6c3ef3fd] [ClientAdapterBase::InvokeOnSoap] Invoke done (<ESX_NAME>, vim.vm.guest.FileManager.initiateFileTransferToGuest)
2022-03-03T09:24:40.187Z verbose vpxd[04518] [Originator@6876 sub=guestops opID=6c3ef3fd] [GuestOperationsManagerMo::PostProcessingModule] postProcessing vim.vm.guest.FileManager.initiateFileTransferToGuest
2022-03-03T09:24:40.187Z verbose vpxd[04518] [Originator@6876 sub=guestops opID=6c3ef3fd] [GuestOperationsManagerMo::PostProcessingModule] postProcessing FileTransferToGuest, new url is 'https://<IP>:443/guestFile?id=6312&token=<TOKEN>'
2022-03-03T09:24:40.188Z verbose vpxd[04518] [Originator@6876 sub=guestops opID=6c3ef3fd] [PostGuestOpEvent] reporting event for InitiateFileTransferToGuest
2022-03-03T09:24:40.188Z verbose vpxd[04518] [Originator@6876 sub=Vmomi opID=6c3ef3fd] Invoke done: vim.vm.guest.FileManager.initiateFileTransferToGuest session: 52c9419b-aad6-6193-f4f7-3bb9a401edc9 
2022-03-03T09:24:40.188Z info vpxd[04518] [Originator@6876 sub=vpxLro opID=6c3ef3fd] [VpxLRO] -- FINISH lro-54326869

VMware support said they don't cover these type of issue.

 If you have any other tips they are greatly appreciated of course.

[LucD]

Afaik GSS is not correct in not willing to support PowerCLI.

See (and point them to) PowerCLI Support Breakdown
Especially the phrase "If you’re using a cmdlet and you’re hitting some form of error, where the command used to work or should work according to the documentation, a support request can be opened."

I'm doing some further testing.

[Nitzan_S · Accepted solution]

VMware support team said that the PowerCLI commands simply use the VMware API commands which are supported by the SDK support team only.

I was advised to just change the Guest OS type to "Windows" to avoid this issue.

And this might also be the answer the SDK team would provide as well.

We will just go ahead and do the necessary changes.

Thank you for your suggestions @LucD 

[knikolov]

Seems like some colleagues in GSS are not familiar with the support policy for PowerCLI. To avoid such confusions we have included a special chapter on the PowerCLI support in the PowerCLI User's guide. You can see more information and refer GSS to this chapter here (https://developer.vmware.com/docs/13638/powercli-12-3-0-user-s-guide/GUID-0F835722-E667-4177-A8EF-51...). It clearly explains what is covered by the basic or production support contract and what requires SDK and API support contract.