vSphere Server Appliance 6.5: Could not connect to one or more vCenter Server systems: https://:443/sdk

Do you get the next error in vSphere Web Client 6.x?:

Could not connect to one or more vCenter Server systems:
https://<IP-adres or FQDN>:443/sdk

If you open the URL, you get this error:

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http16LocalServiceSpecE:0x00007f24400047c0] _serverNamespace = /sdk action = Allow _port = 8085)

Are you using the appliance? My problem was solved by the next solutions:

Source: https://communities.vmware.com/thread/547345

I seem to have fixed my issue by simply typing in a System name in the dialogue pictured below, instead of leaving it blank, which relied on the DHCP reservation/DNS entry in my router that worked under 6.0U2.

I've now survived 5 ESXi reboots, using ESXi host reboot, which was set to shut down all VMs gracefully, and to restart VCSA automatically.

I will continue to test and reboot, but first, a flight to catch, with my server onboard, of course ;-)

Here's how I was doing 6.0U2 or 6.5 installs, choosing DHCP, and leaving System name blank (but setting up a DHCP reservation for the VM's MAC address, and setting up a DNS name, by suspending the VCSA 6.5 appliance moments after the power up button appears, and grabbing the fresh  VM's MAC, then resuming)

  

I don't use DDNS:

  but figured I'd try to put in a System name anyway:

 Five reboots later, I seem to be good, used to fail on first or second reboot/restart of VCSA.

More information:

https://www.youtube.com/watch?v=gjls1PcxiWY&feature=youtu.be

VMware vSphere Essentials V6 - Migrating storage tip.

The migration option "Change storage only" is not allowed in VMware vSphere Essentials.

If you want to migrate a VM storage from one datastore to another, then use "Change both compute resource and storage".

After the migration is completed, use "Change compute resource only"option to migrate the VM back to his original host.

This way you can live migrate the storage of you VM. It takes more time and work, but the VM stays online.

VMware Tools & SIDEBYSIDE Event ID 33

On a few VM's the VMware tools didn't work. After starting the service, I got an error. This is the error in the Event Viewer:

Activation context generation failed for “C:\Program Files\VMWareTools\plugins\vmusr\vmtray.dll”. Dependent Assembly Microsoft.VC90.MFC,processorArchitecture=”amd64″,publicKeyToken=”1fc8b3b9a1e18e3b”,type=”win32″,version=”9.0.30729.4148″ could not be found. Please use sxstrace.exe for detailed diagnosis.

The solution:

Install: 

Microsoft Visual C++ 2008 Redistributable – x86 9.0.30729.4148 (32bits)

or

Microsoft Visual C++ 2008 Redistributable – x64 9.0.30729.6161 (64bits)

For more useful information check this website:

http://vpxa.info/index.php/2016/02/16/vmware-tools-10-0-5-3227872-sydebyside-event-id-33/

Problem with HP 1.6TB HH/HL Value Endurance (VE) PCIe Workload Accelerator

I had a problem with HP 1.6TB HH/HL Value Endurance (VE) PCIe Workload Accelerator(763836-B21) in a HP DL380P Gen3 server. After installing the latest drivers from the HP website on an ESXi 5.5 U2 host, I got this error:

Error: Fusion-io driver not loaded. Exiting.

Also fio-status command was not working. Same driver error.

Downloaded driver version: VSL3.2.6_ESXi-5.5.zip


Solution: 

I contacted HP and got the right driver. This right driver was not available on the website.

HA failover initiated on

Unable to remove warning message in cluster in VMware vCenter Server 4.x/5.x: HA failover initiated on <clustername> (2004802) 

Symptoms

• You see a warning message for a cluster in VMware vCenter Server:
  
  HA initiated a failover on datacenter
  or
  vSpere HA initiated a virtual machine failover action in cluster.....
  
  
• After the warning message appears, you are unable to remove it.
• No options are present for removal of the warning message.

Purpose

This article provides information on how to clear the failover warning message in vCenter Server.

Cause

This issue occurs when a HA failover event occurs in the cluster, which triggers the warning message. This locks the warning message and prevents it from being removed.

Resolution

To resolve this issue:

1. Disable HA at the cluster level. For more information, see Disabling VMware High Availability (HA) (1008025).
2. Enable HA at the cluster level. For more information, see Enabling VMware High Availability and VMware Distributed Resource Scheduler in a cluster (1034280).

 Source: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004802

Vmware to Hyper-V Conversion Tools

Vmware to Hyper-V Conversion Tools:

 More information at:
http://www.microsoftvirtualacademy.com/training-courses/vmware-to-hyper-v-migration

Server's certificate cannot be checked.

Administration dashboard in VMware Horizon View 5.1/5.2/5.3 reports the error: Server's certificate cannot be checked (2000063)

Symptoms

• View Administration dashboard displays Connection Server in red status.
• View Administration dashboard displays Security Server in red status.
• Clicking Connection Server in View Administration displays this error:
  
  Connection Server certificate is not trusted
  
• Clicking Security Server in View Administration displays this error:
  
  Server's certificate cannot be checked
  
• You are able to connect externally through the Security Server.
• The certificates on the server are valid.

Cause

This issue occurs if the Certificate Revocation List (CRL) includes a URL that cannot be accessed from the Connection Server paired to the Security Server.

Resolution

To resolve this issue, ensure that the Connection Servers that are paired with Security Servers are able to check the URL in the Certificate Revocation List (CRL), if your environment includes a proxy server that controls Internet access.

To work around this issue, create a CertificateRevocationCheckType registry string in Windows Registry.

Note: This procedure modifies the Windows registry. Before making any registry modifications, ensure that you have a current and valid backup of the registry and the virtual machine. For more information on backing up and restoring the registry, see the Microsoft article 136393.

To create a CertificateRevocationCheckType registry string in Windows Registry:

Note: If you are using multiple connection servers, you need to make this registry modification on all Connection Servers.

1. Navigate to HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware VDM\Security\ in the View Connection Server.
   
   Caution: Ensure that you make changes in the Connection Server and not the Security Server.
   
   
2. Create the CertificateRevocationCheckType registry string (REG_SZ) and set its value to 1.
   

A reboot is not required to make this change take effect.

 

source: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2000063 

VMware Virtual SAN Setup

The basic vSAN setup tutorial:

How to change Horizon View SESparse to VMFSSparse

Nice article about changing SESparse to VMFSSparse:

How to change Horizon View SESparse to VMFSSparse

In my article Clearing up Space-Efficient Virtual Disk questions I explained the most important requirements and constraints when the new SESparse VMDK disk format with Horizon View 5.2.
Just in cased you missed it:

• This new feature requires vSphere 5.1 as well as hardware version 9 for the VMs.
• The Space Efficient format is only for for linked clone pools; and only for the OS disk.
• Horizon View automatically chooses the space efficient format when possible and there is no official way to change this behavior.
• The Space Efficient Format is not yet supported for Windows 8.
• The space reclamation process is kicked off automatically by Horizon View when the reclaimable space for the VM exceeds the threshold set by the administrator.
• The space reclamation statistics (reclaimed amount, reclaimed time) are displayed in the Pool Summary, and Desktop Summary.
• SESparse disks ARE COMPATIBILE with the Horizon View Storage Accelerator technology from View 5.1 / vSphere 5.

Despite many customers are already successfully using the new feature and are effectively saving on the overall storage capacity utilized, some customer asked me how to disable this feature and re-instate VMFS Sparse as the default disk type. For many VMware internal reasons SESparse is the Default behavior and cannot be changed from the Admin UI. However there are couple ways to disable it.

Read more......

Source: http://myvirtualcloud.net/?p=4745

The Host IPMI System Event Log Status alarm.

I had this error and solved it with this solution:
A reset of the management agent on the ESXi hosts was required to.

The Host IPMI System Event Log Status alarm is triggered repeatedly in VMware vCenter Server 4.x and 5.x (1033725)

 Symptoms

• The Host Intelligent Platform Management Interface (IPMI) System Event Log (SEL) Status alarm is triggered repeatedly on the ESXi/ESX host.
• Acknowledging the alarm removes the exclamation on the ESXi/ESX host in the inventory.
• The alarm is triggered again after some time.
• The messages.log file (located at /var/log) contains errors similar to:
  
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  snmpd[19956]: Connection from UDP: [10.16.16.65]:61945
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  /usr/lib/vmware/bin/vmware-hostd[19577]: Accepted password for user root from 10.16.16.65
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  snmpd[19956]: Connection from UDP: [10.16.16.65]:61945
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  sfcb-vmware_raw[5153]: IpmiIfcSelReadAll: failed call to IpmiIfcSelReadEntry cc = 0xff
  
  Note: For more information, see Location of vCenter Server log files (1021804).

Cause

This issue occurs when the alarm monitors the capacity of the IPMI System Event log and is triggered when the log is full.

Resolution

To determine why the log has filled up, investigate the hardware.

To resolve this issue, stop the alarm from triggering repeatedly and clear the IPMI System Event log and reset the sensors.

To clear the log and reset the sensors:

1. Open vCenter Server using vSphere Client.
2. In the vCenter Inventory, select the ESXi/ESX host.
3. Click the Hardware Status tab.
4. Click System Event log under View.
5. Click Reset Event Log. The red alert is removed from the System Event log.
6. Click Reset Sensors to reset the host sensors.

Introduced in ESXi 5.1 Update 2 (Build Number: 1483097) and ESXi 5.5 Patch 1 (Build Number:  1474528), there is a new localcli command line to clear the IPMI SEL logs:

localcli hardware ipmi sel clear

To run this command on the ESXi 5.1 or 5.5 host:

1. Connect to the ESXi host via SSH. For more information, see Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910).
2. Run this command:
   
   localcli hardware ipmi sel clear

Additional Information

If you find an incorrect date and if you are unable to reset the logs, restart the management agents and sfcbd-watchdog on ESX, or the management agents on ESXi.

• From the console on ESX, run the command:
  
  /etc/init.d/sfcbd-watchdog restart
  
• On ESXi, restart the management agents. For more information, see Restarting the Management agents on an ESX or ESXi Server (1003490).

Upgrading VMware Tools Using RPM on a Linux Guest

Upgrading VMware Tools Using RPM on a Linux Guest Imported from Workstation Might Fail (1004319)

Details

Upgrading VMware Tools using RPM on a Linux guest might fail with a message similar to the following:
Error: unpacking of archive failed on file /usr/lib/vmware-tools/lib32/libXrender.so.1: cpio: rename failed - Is a directory
This problem occurs on a Workstation 5.x Linux virtual machine that is installed with Workstation 6.0 VMware Tools using RPM, and this virtual machine is imported into ESX Server 3.5.x.

Solution

To work around this issue:

1. Uninstall VMware Tools from the virtual machine:
   
   # rpm –qa | grep VMwareTools
   # rpm –e <old_tools_RPM_name>
   
   
2. Reinstall VMware Tools on the virtual machine:
   
   # rpm –ivh <new_tools_RPM_name>

How to disable warnings for ESXi Shell and SSH

I used this to get rid of these annoying messages every time on one ESXi host. There was one exception because of management reasons. The others hosts are in lockdown mode.

Cluster warning for ESXi Shell and SSH appear on an ESXi 5.x host (2003637)

Symptoms

• ESXi host shows these errors:
  
  
• ESXi Shell for the Host has been enabled
• SSH for the host has been enabled

Cause

Note: This article pertains to vSphere 5.0. For vSphere 4.x, see Cluster warning shown in vCenter Server when Remote Tech Support Mode (SSH) or Local Tech Support Mode is enabled (1016205).
In vSphere 5, you can enable both Remote SSH and the ESXi Shell for management of hosts from the vSphere Client, vSphere Web Client and from the Direct Console User Interface.
These messages that appear with a yellow exclamation mark is a proactive security measure and inform administrators that remote access is enabled for the server.
Disabling Remote SSH and ESXi Shell removes the messages from the host.

Resolution

To disable these warnings using vSphere Client:

1. Select the ESXi host from the Inventory.
2. Click the Configuration tab.
   
3. Click Advanced Settings in the Software menu.
4. Navigate to UserVars > UserVars.SuppressShellWarning.
5. Set the value from 0 to 1.
6. Click OK.

To disable these warnings using esxcli:

1. Connect to the ESXi host through SSH using root credentials.
2. Run this command:
   
   vim-cmd hostsvc/advopt/update UserVars.SuppressShellWarning long 1

To enable these warnings using esxcli:

1. Connect to the ESXi host through SSH using root credentials.
2. Run this command:
   
   vim-cmd hostsvc/advopt/update UserVars.SuppressShellWarning long 0

To disable SSH and warning using vSphere Web Client:

• Disable remote access to the ESXi 5.x host
• 1. From the vSphere Web Client, select vCenter from the Home menu.
  2. Select Hosts and Clusters under the Inventory Trees.
  3. Expand the tree in the left pane of the vSphere Web Client.
  4. Click the ESXi host with the yellow exclamation and click the Manage tab.
  5. Click Settings and highlight Security Profile.
  6. Scroll to Services and click Edit.
  7. Highlight ESXi Shell and click Stop.
  8. Repeat for SSH, then press OK.
• Disable the Warning message
• 1. From the vSphere Web Client, select vCenter from the Home menu.
  2. Select Hosts and Clusters under the Inventory Trees.
  3. Expand the tree in the left pane of the vSphere Web Client.
  4. Click the ESXi host with the yellow exclamation and click the Manage tab.
  5. Click Settings and highlight Advanced System Settings.
  6. Locate the parameter UserVars.SuppressShellWarning and click the pencil icon to edit.
  7. Change the value to 1 and press OK.

System logs are stored on non-persistent storage (2032823)

System logs are stored on non-persistent storage (2032823)

Details

You receive this message when your system stores its log files on non-persistent storage.

Example

When you use the advanced system parameter Syslog.global.logDir to configure the system log location, if you configure the system log location as temporary, for example [] /tmp, you get the esx.problem.syslog.nonpersistent message.

When the location for system logs is not configured, your system uses the scratch partition by default. If the scratch location is set to nonpersistent storage, such as /tmp, you get the esx.problem.syslog.nonpersistent message.

Impact

System logs are required for auditing and diagnostic purposes. If you do not store system logs permanently, for example on a datastore, they disappear after a reboot.

Solution

Verifying the Location of System Logs in vSphere Client

To verify the location:

1. In vSphere Client, select the host in the inventory panel.
2. Click the Configuration tab, then click Advanced Settings under Software.
3. Ensure that Syslog.global.logDir points to a persistent location. The directory should be specified as [datastorename] path_to_file where the path is relative to the datastore. For example, [datastore1] /systemlogs.
   
4. If the Syslog.global.logDir field is empty or explicitly points to a scratch partition, make sure that the field ScratchConfig.CurrentScratchLocation shows a location on persistent storage.

Verifying the Location of System Logs in vSphere Web Client

To verify the location:

1. Browse to the host in the vSphere Web Client navigator.
2. Click the Manage tab, then click Settings.
3. Under System, click Advanced System Settings.
4. Ensure that Syslog.global.logDir points to a persistent location.
5. If the field Syslog.global.logDir is empty or points to a scratch partition, make sure that the field ScratchConfig.CurrentScratchLocation shows a location on persistent storage.
   
   Note: You must reboot the host for the changes to take effect.

Note: To log to a datastore, the Syslog.global.logDir entry should be in the format of [Datastorename]/foldername. To log to the scratch partition set in the ScratchConfig.CurrentScratchLocation, the format is blank or []/foldername.

 

Additional Information

For more information on determining persistent logging, see Determining whether an ESXi host has persistent logging (2004773).

For more information on configuring Syslog on ESXi, see Configuring syslog on ESXi 5.x (2003322).

 

Product(s):
VMware ESXi
VMware vCenter Server

Product Version(s):
VMware ESXi 5.0.x
VMware ESXi 5.1.x
VMware vCenter Server 5.0.x
VMware vCenter Server 5.1.x
VMware vCenter Server 5.5.x

 

 

Host currently has no management network redundancy (1004700)

Howto suppress this message:

Host <xxx> currently has no management network redundancy

I found this article in the VMWare KB:

Network redundancy message when configuring VMware High Availability in vCenter Server (1004700)

Symptoms

When configuring the VMware High Availability (HA) in a vCenter Server, you see the message:

Host <xxx> currently has no management network redundancy

Cause

This message is displayed if the network redundancy configuration within theService Console/VMkernel Port Management Network is incorrect. This message can be safely ignored.

Resolution

To prevent this message from appearing, and to comply with proper network redundancy, VMware recommends that you add a second vmnic to the service console or management network vSwitch configured with NIC teaming, and that you keep both as active adapters, or place one in standby. For more information, see NIC teaming in ESXi and ESX (1004088).

Alternatively, you can add a second service console on a different vSwitch and subnet. To suppress this message on ESXi and ESX hosts in the VMware High Availability (HA) cluster, or if the warning appears for a host already configured in a cluster, set the VMware HA advanced option das.ignoreRedundantNetWarning to true and reconfigure VMware HA on that host. This advanced option is available in VMware Virtual Center 2.5 Update 3 and later.

If the warning appears even when there are two available uplinks for the vSwitch hosting the Service Console/VMkernel Port Management Network, providing a redundancy, see ESX/ESXi host displays warning message when test condition is false (2008602).

Note: If the warning continues to appear, disable and re-enable VMware High Availability in the cluster.
To set das.ignoreRedundantNetWarning to true:

1. From the VMware Infrastructure Client, right-click on the cluster and click Edit Settings.
2. Select vSphere HA and click Advanced Options.
3. In the Options column, enter das.ignoreRedundantNetWarning
4. In the Value column, type true.
   
   Note: Steps 3 and 4 create a new option.
5. Click OK.
6. Right-click the host and click Reconfigure for vSphere HA. This reconfigures HA.

To set das.ignoreRedundantNetWarning to true in the vSphere 5.1 Web Client:

1. From the vSphere Web Client, right click on the cluster.
2. Click on the Manage tab for the cluster, then under Settings click vSphere HA.
3. Click on the Edit button in the top right corner.
4. Expand the Advanced Options section, and click Add.
5. In the Options column, type das.ignoreRedundantNetWarning.
6. In the Value column, type true.
7. Click OK.
8. Right-click the host and click Reconfigure for vSphere HA.

Source:http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004700