VMworld 2015/Hands on Labs

From Omnia
Jump to navigation Jump to search

Hands on Labs

Hands on Lab - http://hol.vmworld.com/

Launch HOL - http://labs.hol.vmware.com/HOL/catalogs/

Download - VMworld 2015 US Hands-on Labs Poster - http://download3.vmware.com/vmworld/2015/downloads/hol-poster-20150803.pdf

Troubleshooting

Clipboard Copy and Paste does not work in vSphere Client 4.1 and later (1026437)

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


There maybe times where you may want to enable clipboard copy/paste on a virtual machine, or even the virtual machines that are residing on an ESXi host. However, by default this functionality has been disabled.

To enable Copy and Paste option for a specific virtual machine:

NOTE: VMware Tools must be installed for this to work.

  1. Log in to vSphere Web Client
  2. Navigate to vc-01b.corp.local and locate linux-base-01
  3. Power off the virtual machine (linux-base-01).
  4. Select the virtual machine (linux-base-01) and click the Summary tab.
  5. Click Edit Settings.
  6. Navigate to VM Options > Advanced > Configuration Parameters > Edit Configuration.
  7. Find the configuration parameters isolation.tools.copy.disable and isolation.tools.paste.disable and change their values to false.
isolation.tools.copy.disable = false
isolation.tools.paste.disable = false

You may click OK to close the Configuration dialog and proceed to power on the virtual machine.

For more information on this, you may proceed to read this KB article (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026437)

Desktop Info

Glenn's Eclectic Freeware - Glenn Delahoy

www.glenn.delahoy.com/software/

http://www.glenn.delahoy.com/software/files/DesktopInfo151.zip

VMware Poor Performance Lab

Just as in real life, there is more than one way to resolve this performance problem.

The root cause of the poor performance is CPU contention, or high CPU overcommittment. Both perf-01a and perf-02a are placing heavy CPU load on esx-01a. Further, the host esx-01a.corp.local has only two cores, while perf-01a and perf-02a have 3 vCPUs total which are each asking for 100% utilization. To improve VM performance, eliminate or mitigate the contention. The primary way to detect the presence of CPU contention is by monitoring the ESXi metric % Ready. Readiness is the percentage of time that the virtual machine was ready, but could not get scheduled to run on the physical CPU. It happens when virtual machines' demand for CPU time exceeds the availablity of the physical CPU. As a rule of thumb, if Readiness exceeds 10%, CPU contention could be negatively affecting virtual machine performance, although the acceptable ready time will depend on your environment. You may have noticed that the Windows 2012 system kernel appears to consume a larger proportion of the VM's CPU time when there is heavy CPU contention on the host. Windows guest CPU time accounting can become skewed when there is resource contention on the host, so take these metrics with a grain of salt.

High percent ready can also occur if overconservative power management techniques are slowing the CPU; see KB 1018206 (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1018206). Always ensure that your host's BIOS power management setting is set to "OS controlled" and that your ESXi power mangement profile is "Balanced" or "High Performance."

Solutions to this scenario:

1. Migrate perf-01a from ESXi host esx-01a to ESXi host esx-02a. esx-02a is not being used, so with fewer VMs contending for CPU resources, performance increases. Alternatively, you could migrate perf-02a from esx-01a to esx-02a to accomplish the same goal.

2. Use Resource Allocation to limit the CPU MHz given to perf-02a. Using "Edit Resource Settings," place a CPU limit on perf-02a.

3. Use Resource Allocation to guarantee perf-01a will receive at least a certain number of CPU MHz. Using "Edit Resource Settings," create a CPU reservation for perf-01a.

If you solved this challenge some other way, good for you. However, please return the setting to its prior state if you will take another module after this one.

For more resources to understand CPU performance,

VMware SSO Login

Many a times, users can get logged out of the vSphere system if:

  1. Their account has been disabled by the SSO administrator
  2. They have too many failed attempts that has breach the Lockout policies set by the SSO administrators.

To solve this challenge:

  1. Log in to vSphere Web Client as a SSO administrator
  2. Click on Administration -> Single Sign-On -> Users and Groups
  3. Look for account name murphy.
  4. Right click and enable the user account murphy.

VMware Permissions

Users require a minimum of read-only permissions at the vCenter Server level. If these permissions are missing, users will receive the Empty Inventory status.

To resolve the issue, assign the affected users a minimum of read-only permissions at the vCenter Server level.

To assign read-only permissions:

  1. Log in to the vCenter Server as administrator with the vSphere Web Client.
  2. Select the appropriate vCenter Server in the navigator window.
  3. Click the Manage -> Permissions.
  4. Right click on murphy and hot change role.
  5. Change access to Read-only and hit Ok.

Have you checked under "Global Permissions" for user murphy@vsphere.local using the SSO administrator (administrator@vsphere.local) account?


VMware - Remote Console: Unable to connect to the MKS

administrator@vsphere.local

administrator@corp.local


Error:

Unable to connect to the MKS: Could not connect to pipe \\.\pipe\vmware-authdpipe within retry period.


Additional Information: This issue was discovered only after your security team changed made changes to security settings on your ESXi host (esx-01b.corp.local)

Hint: There is nothing wrong with the VMRC plugin installed on Chrome or the desktop. It might be an issue with the ESXi host (esx-01b.corp.local).

It is not a user permission issue, as the user "administrator@corp.local" has been given administrative privileges. You might want to check the ESXi host's (esx-01b.corp.local) "Advanced Settings" and verify the requirements that must be in place in order to open a remote console to a virtual machine.

References:

---

Solution

Before you can use VMware Remote Console (VMRC) to open a remote console to a virtual machine, you must enable SSL authentication on the ESX/ESXi host. SSL authentication is enabled by default on ESX/ESXi hosts.

To enable SSL authentication from GUI:

  1. Connect to the vCenter that is managing the host using the vSphere Web Client.
  2. Select esx-01b.corp.local.
  3. Click the Manage tab.
  4. Under Settings - > System, click Advanced System Settings.
  5. Expand Config > Defaults.
  6. Expand Security and select host.
  7. Search for the name "Config.Defaults.security.host.ruissl" option and set it to yes/true.

To find out more, you can read this KB article. (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007386)

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

VMware Enable SSH from Web Client

During most ESXi troubleshooting activities, many administrators do get into issues trying to establish a remote SSH session with a ESXi host. This is because SSH is often disabled to prevent remote access to the ESXi host. It is only activated during troubleshooting activities by the administrators.

To enable SSH on the ESXi host using vSphere Web Client:

  1. Login to vSphere Web Client
  2. Search and locate the ESXi host
  3. Go to Manage tab
  4. Click on Settings -> Security Profile
  5. Under Services, check the status of SSH.
  6. Click Edit to change it to "Running"