Powercli Version 5.1 Release 1
Host ESXi 5.0
We are trying to run a script, which queries several Linux machines, but we keep on getting the following error:
The script we are using, has the following code:
The script was created by someone who has scripting knowledge, so unfortunately I cannot explain how this script works.
If anyone is able to help or point us in the right direction, it would be appreciated.
I have the impression that the VMware Tools are not running on the guest.
Since these are Linux guests, was the configuration of the VMware Tools done.
Do these tasks start automatically when the OS is started ?
I was hoping you would respond
In vCenter it is showing that vmtools is running within the VM and the version is upto date with Host Version.
I am not sure, if vmtools was actually configured from within the Linux Guest OS.
Ok, then it looks indeed if the VMware Tools are running.
The Timeout the Invoke-VMScript mentions could also come from the fact that the cmdlet can't connect to the VMware Tools on the VM because port 902 is not open.
That is port 902 between the machine where you run the script and the ESXi host where the VM is running.
In my Will Invoke-VMScript work ? post there is code that tests this prereq.
thank you Luc I will check the port out, as per the link you mentioned.
Will get back to you shortly.
Quick question, are vm's are centos vm's will the script work against this OS?
Do I just need to copy the script from the webpage and past it into Notepad ++?
Im not a scripting person, unfortunately.
I cannot seem to get the script to work
I have copied the script to the root of my C drive
Then typed the following in PowerCli
$vm = Get-VM -Name voffice-1160
./Test-InvokeVMScript.ps1 -VM $vm
When I do this, it just brings me back to the command prompt.
I also tried to run
Get-VM voffice-1160 | Test-InvokeVMScript & Get-VM voffice-1160 | ./Test-InvokeVMScript
But nothing seems to work, am I doing something wrong? I guess I really need to learn powercli:smileyblush:
The script in my post is a function, you could do the following
Get-VM voffice-1160 | Test-InvokeVMScript
Thank you for the instructions, we have followed this and I can see from the detail report, it states Port902 is open and VMTools is running.
But yet we still get these error messages.
I also did a telnet to the host on port 902 and it connected without any issues.
Not sure if I need to nc -z vmip 902 to test communication further.
We also noticed, that on some hosts the script runs fine, but on other we get the errors on a few or many Linux VM's.
Only thing different is some hosts have SNMP enabled on Port 161 whilst others do not, but not sure how SNMP will impact the script of VMTools Timeout.
Afaik SNMP has no impact on the Invoke-VMTools cmdlet.
Are all these VMs running the same Linux OS and the same version ?
Can deduce a communality between the VMs where the cmdlet doesn't work ?
Also check the vmware.log on the VMs where it doesn't work.
That log might contain some clues
Just to give you a quick update.
When I was running the script I was connecting to our vcenter then executing the a script, tailored to individual hosts.
We have modified the script and are now running the script, whilst connected to an individual host, for some reason the script is running much better and not giving those vmtool timeout errors.
I am not sure, what difference it makes running a script via vCenter or directly running it against a specific host.
How does powercli interact with vCenter?
Afaik, the initial Connect-VIServer sets up a connection with the vSphere server (beit vCenter or ESXi) over port 902.
For the Invoke-VMScript there are several conditions to be met, but in the end the client station (the PC where you run the script) needs to connect (again over port 902) to the ESXi where the VM is running.
So in principle it shouldn't make any difference.
Btw was there anything in the vmware.log for the VM where it fails ?
I have checked the VMware.log for the some vm for some of the those vm;s which the script had issues with.
But within the log file, there was nothing relating to why the script failed.
Infact, it did not log anything in relation to the script.
I am now going to check the VMware.log file, for a vm which had no issues when the script was run, will let you know if I find anything.