This may need to go in the VC forum I dont know. I have the following braindead script below using the VI Powershell toolkit that fails when I call it more than 2x's simultaneously.So basically I am trying to call and shutdown 4 images then restart them. Its being called from ANT so I am a bit limited in that I am running parallel tasks and so I can not just rewrite the script to take multiple uest os names for a shutdown theryby allowing my to call VC once.
param ($x)
#$name = "Vista x86 Enterprise wSP1 N-01"
$Name = $x
#Connect to the VirtualCenter
Connect-VIServer -Server server1.domain.com -Protocol https -User administrator -Password 'XXXXXXXXX'
#Shutdown the VM
Get-VM -Name $name | Shutdown-VMGuest -Verbose
#wait for VM PowerState to go to off this is needed as Shutdown-VMGuest returns before the vm is shut down
do {Start-Sleep -s 5}
while ((get-vm -name $name).PowerState -eq "PoweredOn")
Start-VM -VM (Get-VM -Name $name) -verbos
I see the following
Connect-VIServer : The configuration file has been changed by another program.
(C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.config)
At D:\restartVM.ps1:10 char:17
+ Connect-VIServer <<<< -Server server1.domain.com -Protocol https -User administrator -Password 'XXXXXX'
Connect-VIServer : The configuration file has been changed by another program.
(C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.config)
D:\restartVM.ps1:10 char:17
+ Connect-VIServer <<<< -Server server1.domain.com -Protocol https -User administrator -Password 'XXXXXX'
Get-VM : 12/8/2008 10:54:25 AM Get-VM You are not currently connected to any servers. Please connect first using Connect-VIServer or one of its aliases.
Repeat
The odd thing is the first 2 connections will work but the second 2 will not if I launch the .ps1 4x with different info.
Looks like a bug, we'll investigate.
As a workaround you could lock the script file while connecting, using something like
$handle = new-object System.IO.FileStream("\path\to\your\script", [http://System.IO.FileMode|http://System.IO.FileMode]::Open) ... Connect Here ... $handle.close()
You'd have to add some exception handling to the first line though.
Since you think its maybe a bug I did a little more digging to try and make sure it was not the way I called it via ANT.
I created a batch file as follows and was able to reproduce it. Interestingly this time 3/4 worked but the second time I ran 1/4 worked.
start powershell .\restartVM.ps1 'XP x86 Pro wSP3 N-01'
start powershell .\restartVM.ps1 '2003 x86 Enterprise R2 wSP2 N-01'
start powershell .\restartVM.ps1 'Vista x86 Enterprise wSP1 N-01'
start powershell .\restartVM.ps1 '2008 x86 Enterprise N - 01
This is not the first time this is reported.
See
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
I think just putting the lock around Connect-VIServer would be enough.
Thanks, Luc I didn't see that issue when it first came up.
c_shanklin I am a bit new to Powershell so i am still googling but wouldnt putting a lock on the file while doing the connect cause the other instances(the ones not first) to not be able to open the .ps1 at all?
That's probably true. Maybe you could have a myscript.ps1.lock file that you maintain the lock on.
C_shanklin,
I started down the path of creating a "lockfile" but even these were being created to fast and so I still ran into connection issues plus it was pretty ugly.
But I found something better and simpler that worked.
do {Connect-VIServer -Server server1.domain.com -Protocol https -User administrator -Password 'XXXXX' }
until ($? -eq $true)
The key is $? contains the success/fail status of the last command and since the connect is what was failing this was holding false so we can evaluate it.
So while there are still some error messages showing up after a retry or 2 depending on how many commands I am throwing at it it eventually succeds. It maybe slows it down 10 seconds
That's sad. I would think any Powershell solutions would contain a very major business requirement, multi instancing considerations. Clearly, VI Toolkit is using a central cred store. Upon reflecting the code, i see no regard to interprocess safety using either Mutex or other Kernal synch objects. Can we get a clear list of which cmdlets that we should lock on as temp workaround? Is Connect-VIServer enough?
PS: this may sound a bit negative, but I still reiterate on an amazing productivity this framework brings. I don't have ESX at home, but found immense use in VMWare Server 2.0 home based administration tasks.
I believe only Connect-VIServer is affected. The workaround is basically just, "Keep calling it until it works". After that everything is fine. This is fixed for the upcoming 1.5 release.
Nice to hear you're finding some use for the tool with Server, we're obviously very ESX focused and not really sure how many people out there are using us for Server.