Zsoldier's Tech Blog

[ Update: Current preferred method would be to change your system locale, unless you know how to remove the encoding from the .vmdk file itself as well. The second method works to bring a system back up quickly, but you will notice the vmdk shows up as 'invalid' which only becomes an issue if and when you decide to use snapshots.] Summary: This probably occurs on small percentage of users' systems who change their system locale from English to another language, then back. To fix this: Change your system locale to match that listed in the vmx/vmsd file of your VM. OR Remove the Unknown (Invalid) VM from Inventory. Open the vmx and/or vmsd file(s) with notepad or other text editor and delete the line that contains ".encoding = "[systemlocale]"" Then re-add it to Inventory. Error: The selected virtual machine is not recognized on this system. The cause of this problem may be that the virtual machine's .vmx file is corrupted, or that the virtual m

Summary: With this powershell script, you can enable the "Check and upgrade Tools before each power-on" option on all your VM's without having to power them off. $ErrorActionPreference = "SilentlyContinue" connect-viserver -server [VCServer or ESX Host] -user [user] -password [password] get-vm | foreach-object { $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec $vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo $vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle" (Get-View $_.ID).ReconfigVM($vmConfigSpec) } Configuration: Virtual Center 2.5 Build 104215 ESX Server 3.5 Update 2 (110268) PowerShell V1 using PowerGUI 1.5.2.550 w/ VI Toolkit 1.0 Update 1 Build 113525 Caveats: [ UPDATE: The script has been updated to continue past any errors generated. So if any VM's have issues it will just continue to the next VM in line to update. You will have to audit systems that were not updated with the s

A powerful combination that can make your day to day administration easier. Here are links to the tools to begin using powershell with VMWare: Download and install Powershell: (If you are using Vista SP1 or newer, it's in your "Turn Windows features on or off" section of Control Panel) http://www.microsoft.com/downloads/details.aspx?FamilyId=6CCB7E0D-8F1D-4B97-A397-47BCC8BA3806&displaylang=en VI Toolkit : (This gives you the various 'cmdlets' to use with Powershell) http://www.vmware.com/sdk/vitk_win/index.html PowerGUI : (A free GUI style script editor, works pretty well for being free) http://www.powergui.org/index.jspa VMWare PowerPack : (Free powerpacks for use w/ Virtual Infrastructure) http://www.powergui.org/entry.jspa?externalID=1802&categoryID=290 Lab Manager PowerPack : (Free lab manager powerpack) http://www.powergui.org/entry.jspa?externalID=1647&categoryID=290

Summary: Cloning, building, moving, a machine into a "Virtual Machines and Templates" folder within Virtual Center w/ complete Administrator rights causes permissions error above. The issue simply boils down to that you are likely using AD groups to delegate permissions within Virtual Center. If so, one group has administrative privileges over the entire tree, while you've assigned another AD group a role w/ less access to a sub-folder in the tree. If your account happens to be a member of both groups, you've effectively denied your administrative rights over that sub-folder. This may either be a bug or an intentional function. I'm thinking it's a bug. Configuration: Virtual Center 2.5.0 Build 104215 Windows 2003 Active Directory Domain Resolution/Workaround: To workaround this issue, you can simply remove yourself from that other AD group, or create another account that is only apart of the administrative group of Virtual Center. For a failsafe, cre

Summary : This usually occurs because the mgmt-vmware decides for whatever reason to stop talking back to Virtual Center and will not gracefully restart. Configuration: ESX 3.5.0, 110268 (Update 2) Virtual Center 2.5.0 Build 104215 These steps may help you resolve issues with other versions, but attempt at your own risk. Resolution: Log into the Service Console via Putty or another SSH Client and type " service mgmt-vmware restart ." If successful in restarting the service, continue to step 2. If not successful see the immediate bullet below: If the restart process hangs, you may need to open another putty session to kill -9 the process. (ex. kill -9 mgmt-vmware) Once killed type " ps aux | grep hostd " If the first line does not contain " vmware-watchdog " then it likely contains " config.xml -u " if so you'll need to kill -9 it based on the PID. The PID would be the highlighted value in the following example: root 14096