While attempting to carry out a V2V using VMware Converter I had a permissions related issue when selecting the source machine:
Permission to perform this operation was denied
I triple-checked my permissions within vCenter were sufficient to carry out a V2V, even temporarily granting my own account with the Administrator role directly to the location in question, but still received the above error.
I stumbled across this VMware Community posting which suggested that granting local Administrator rights to the account I was using on the Windows server where VMware Converter was running from might help.
Experienced this issue a month or so back (ended up logging a call with VMware to get confirmation of what happened) and it occurred again today so figured it was worth posting about.
If you receive the following error when attempting to log into vCenter 5.1 with an AD account:
A general system error occurred: Authorize Exception
there are a number of potential issues. however most likely it is related to SSO and one of the Identity Sources.
Having recently enabled Storage DRS in a vSphere 5.1 environment we began to see a lot of the following errors in vCenter:
The device or operation specified at index ‘x’ is not supported for the current virtual machine version ‘vmx-04’. A minimum version of ‘vmx-06’ is required for this operation to succeed
The host(s) running the VM(s) in question contained the error matched in this VMware KB article:
[2009-07-10 14:13:41.632 F638BB90 info ‘vm:/vmfs/volumes/4a56e6c2-9319e3df-f1af-001e0bea4030/RVHOLS029/RVHOLS029.
I recently experienced an issue adding a vSphere 5.1 host to vCenter while using the Add-VMHost cmdlet in PowerCLI. I’m pretty sure the same problem would have occured if I was using the GUI, but this work was for part of some automated deployment work.
On a freshly baked ESXi 5.1 install one of the first tasks is to get it into vCenter. However, this was failing with what initially appeared to be a license issue, despite there being plenty of available licenses.
After upgrading a Cisco UCS C210 M2 rack mount server to ESXi 5.1 and then ESXi patches from 25/07/2013 the host was stuck at ‘Initializing scheduler….’
I had checked my firmware version was satisfactory for ESXi 5.1
but found reports suggesting this (intermittent) issue has been around for a while with earlier versions of ESXi, different versions of UCS models and firmware and maybe HP models too.
Before trying the suggested workaround of disabling legacy USB support, I decided to get the box up to the latest firmware.
Following a switch over from self-signed certificates for vCenter 5.1 to those signed by a internal CA, access to Update Manager via the vSphere Web Client (which seems fairly limited anyway in terms of Update Manager) no longer worked. It was failing with “There was an error connecting to VMware vSphere Update Manager.”
The Webclient log file vsphere_client_virgo.log contains the following error
ERROR [ERROR] http-bio-9443-exec-5 c.vmware.vum.client.adapters.updatemanager.aspects.LoggingAspect Exception caught in class ‘com.
I needed to migrate some Email Alarm Actions between two vCenters; the target at version 5.1 being a replacement for an existing 5.0 vCenter. The first task was to identify which Alarm Definitions had been configured with an email alert. To do that I used the following PowerCLI command to export them to a CSV file:
Get-AlarmDefinition | Select Name,@{N="EmailAction";E={$\_ | Get-AlarmAction | Where {$\_.ActionType -eq "SendEmail"}}} | Export-Csv AlarmActions.csv -NoTypeInformation I could then easily identify those which needed to be migrated across.
While I was removing some ESXi 5.0 hosts from a 5.1 vCenter I encountered the following issue with a couple of them:
General system error: Invalid Fault
In the vCenter vpxd log file this message was accompanied by
msg = “vim.fault.AdminNotDisabled”
It turned out to be a known fault where Lockdown Mode was out of sync between vCenter and the ESXi host. In vCenter it showed as enabled:
However, in the ESXi host it was showing as disabled.
Having installed vCenter 5.1 U1a, it was time to replace certificates. Using the vCenter Certificate Automation Tool to replace self-signed SSL certificates with full certificates you will be taken through various menus to replace each certificate:
When the time comes to replace the vCenter Server certificate, you will firstly be in Menu 4 and then selecting Option 2, Update the vCenter Server SSL Certificate (starting to sound like a dreaded phone call to a utilities or government call centre yet?
While installing vCenter 5.1 recently I experienced the following error at the point where you confirm the AD account to use for the vCenter service:
Failed to verify the service account. Error code: [87]
At first I figured I was mis-entering the credentials, but it turns out to be an issue if the user AD account for the vCenter service is the same name as the vCenter computer account.
Renamed the AD account and started the install again.