Tuesday, February 10, 2015

VMware Horizon View Admin dashboard for vCenter Server 5.1 displays the message: VC service is not working properly or Bad username or password

  • After upgrading to vCenter Server 5.1, in the VMware Horizon View Admin dashboard you see the message:

    VC service is not working properly

  • All other vCenter Server related functions fail, such as powering on and off VDI desktops, or recomposing, adding, or deleting linked clone desktops.
  • When you attempt to change or add (for new VDI environments) the vCenter Server user password or username using View Configuration > Servers > Virtual Center on the View Admin page, the attempt fails with the error:

    bad user name or password

  • Attempting to accept the vCenter Server certificate in the View Manager Administrator portal dashboard fails. You see the error: 

    Vmware View Cannot connect to the vCenter Server{0} because the user name or password is not valid

Solution #1

To resolve this issue, you must add the View domain to the Single Sign-On (SSO) default domain list in the vSphere Web Client.

Notes:
  • Both Single Sign-On and the Web Client services must be running on the vCenter Server machine.
  • Single Sign-On is a required program for vCenter Server and Web Client program must also be installed on the vCenter Server machine for the Web Client service to run.
  • VMware recommends that you run vCenter Server 5.1b (release 947939) or later to address any other possible issues.

To add the View domain to the Single Sign-On (SSO) default domain list:
  1. Log in to the vCenter Server using the vSphere Web Client (https://FQDN_of_vCenter_Server:9443/vsphere-client) as an SSO administrator.

    Note: By default, the SSO administrator user is admin@system-domain and the password is set at the time of the Web Client install. To unlock or reset the vCenter SSO administrator password, see Unlocking and resetting the vCenter Single Sign-On administrator password (2034608).

  2. In the home page, click Administration > Configuration (under Sign-on and Discovery).
  3. In the right side, click the line with the View domain.

    Note: If the View domain is not the same as the vCenter Server domain, you must add the View domain using the add icon at the top of the page.

  4. Add the View domain to the default domain list using the icon at the top of the page. After adding the View domain, it appears at the bottom of the list of default domains.
  5. Using the up arrow, move the View domain so that it is one above the system-domain entry.
  6. Click the save icon and log out of the page.
After completing these steps, the vCenter Server entry in the View Admin dashboard turns green and all vCenter Server related functions on the View Admin page return to normal, and the connection broker(s) are now able to communicate with this vCenter Server.

Solution #2

Go to the View Configuration > Servers > Virtual Center on the View Admin page, change the logon account to another domain admin account(With Domain Admin Privileges), set the password and verify. Once the account is verified and the status console shows that all services are green, go back and change the logon account to some other domain admin account if needed.

In our case, one of our Admins quit and we had to go around and change all domain service account passwords. Once we did this the connection from View to vCenter broke. Had we changed the view logon account to some other valid domain account prior to changing the existing account password, we could have avoided this issue. Once we changed the logon account we went back and used the original service account with the updated password and we were back in business!



Monday, February 9, 2015

How to log in to Single Sign ON SSO in vSphere 5.5 (URL)

I just installed vSphere 5.5 and my vCenter server was already in my domain and I expected to be able to log in with my domain administrator account. Unfortunately it was not the case. To solve the issue I wanted to log in with the vSphere Web Client to validate my permissions and that my domain vclass.local was an identity source. In vSphere 5.1 the SSO administrator was called admin@system-domain this is no longer the case. You need to log in with administrator@vsphere.local and the password you defined under installation of the SSO server. When I logged in with this user I was able to configure my domain as an identity source and give access to my domain admins access to vCenter Server.
You can access the vCenter Web Client on the following url:  

https://WEBCLIENTSERVER:9443/vsphere-client


SSO55


Another thing I noticed was that the administrator@vsphere.local was administrator on the vcenter. In 5.1 admin@system-domain did not have any vCenter permissions set.

vpsherelocal


The only place to configure the SSO is through the Web Client. When you log in with your vSphere Client in a 5.5 environment you will be presented with the following warning

loginwarning

Friday, February 6, 2015

How to change the IP Address of ESXi through the command line

Use VI to edit /etc/vmware/esx.conf or use the following command to manually view the IP address; 

~#esxcli network ip interface ipv4 get

This will give you the list of all VMkernel interfaces with their details (See screenshot below). Changing the IP address is just a matter of adding some parameters:

~#esxcli network ip interface ipv4 set -i vmk(?) -I 10.10.10.10 -N 255.255.255.0 -t static


In your situation you will need to replace “vmk(?)″ with the appropriate VMkernel NIC and change the IP details.

change ip address of esxi

How to disable ESXi firewall vis the command line

When you need to troubleshoot and you need to eliminiate the firewall as the possible cause just log onto the ESXi console and disable the firewall via the CLI.

Use the following command:
 
~#esxcli network firewall set --enabled false

This will disable it permanently.

Changing the load balancing policy in ESXi using CLI 5.1


To change the load balancing policy on an ESXi 5.x standard vSwitch, run this command:


esxcli network vswitch standard policy failover set -l iphash -v vSwitch0

for the portgroup, run this command:

esxcli network vswitch standard portgroup policy failover set -p "Management Network" -l "iphash"

 On ESXi 5.x,
  • To change the load balancing policy to a route based on the originating virtual port ID, run this command:

    esxcli network vswitch standard policy failover set -l portid -v vSwitch0

  • To change the load balancing policy to a route based on the MAC hash, run this command:esxcli network vswitch standard policy failover set -l mac -v vSwitch0

To Set the NIC teaming policy on a Virtual Switch on an ESXi 5.x

  • To list the current NIC teaming policy of a vSwitch, use the command:

    # esxcli network vswitch standard policy failover get -v vSwitch0
  • To set the NIC teaming policy of a vSwitch, use this command: 
# esxcli network vswitch standard policy failover set -l policy -v vSwitchX
For example, to set the NIC teaming policy of a vSwitch to IP hash:

# esxcli network vswitch standard policy failover set -l iphash -a uplink=vmnic0,vmnic4 -v vSwitch0
Note: Available Policy Options:
  • explicit = Use explicit failover order
  • portid = Route based upon port id (This is the Default setting)
  • mac = Source Based Upon MAC Hash
  • iphash = Source based up IP hash (This is only to be used in a etherchannel\Portchannel)

Thursday, December 18, 2014

Troubleshooting and Frequently Asked Questions for space reclamation in VMware Horizon View 5.2.x and 5.3.x (2039907)


Cause

For the space reclamation feature to work correctly, ensure that:
  • VMware Tools provided with vSphere version 5.1 or later are installed on the virtual machine.
  • The virtual machine is using virtual hardware version 9 or later.
  • In the View Administrator console, the Reclaim VM disk space option is selected for the vCenter Server. For more information, see Allow vSphere to Reclaim Disk Space in Linked-Clone Virtual Machines in the VMware Horizon View 5.2 Administration Guide
  • In the View Administrator console, the Reclaim VM disk space option is selected for the desktop pool. For more information, see Reclaim Disk Space on Linked-Clone Desktops in the VMware Horizon View 5.2  Administration Guide.
  • The virtual machine is powered on before you initiate the space reclamation operation.
  • There is space that can be reclaimed. This space exists when data is deleted from the guest OS. Sending files to the Recycle Bin does not delete them.
  • The virtual machine is using SCSI disks.
  • Changed Block Tracking (CBT) is disabled on the parent virtual machine.

Resolution

This is a list of possible issues you may encounter with the space reclamation feature in VMware Horizon View 5.2 or 5.3.

Issue 1

Symptom:
In vCenter Server tasks, you see the error:

Task: Wipe a Flex-SE virtual disk
Status: A general system error occurred: Wipe Disk failed: Failed to complete wipe operation.


Possible cause:
VMware Tools has not been upgraded to the latest version provided with the host, which must be version 5.1 or later.

Resolution:
Upgrade the VMware Tools in the guest OS, then reboot the guest OS.


Issue 2

Symptom:
  • The vmware.log in the virtual machine folder contains messages similar to:

11-14T18:48:52.922Z| vcpu-0| I120: ToolsRpcDiskWipeProgress: progress response: No wipable disks found
11-14T18:48:52.922Z| vcpu-0| W110: DiskVigorWipeProgressCB: Wipe progress RPC Error: No wipable disks found


Possible cause:
The virtual machine does not have SCSI disks.

Resolution:
The disk (the OS virtual disk in View) must be SCSI, not IDE. Space reclamation does not work on IDE virtual disks.


Issue 3

Symptoms:
  • When space reclamation is launched, you see this event in vCenter Server:

    General system error: Wipe disk failed
  • In the vmware.log file, you see messages similar to:

    2012-11-22T19:53:16.006Z| vcpu-0| I120: ToolsRpcDiskWipeProgress: progress response: No wipable disks found

    2012-11-22T19:53:16.006Z| vcpu-0| W110: DiskVigorWipeProgressCB: Wipe progress RPC Error: No wipable disks found


  • In the VMware Tools log file, you see messages similar to:

    [Nov 23 14:44:55.646] [    info] [vmsvc] Could not initialize backend for drive C:\: 50
    [Nov 23 14:44:55.646] [ warning] [diskWiper] Mount point C:\ is not wipable
    [...]
    [Nov 23 14:44:55.646] [    info] [vmsvc] Device specifically advertises its NON-TP nature, bailing out.
    [Nov 23 14:44:55.646] [    info] [vmsvc] Failed to get Initialize SCSI Backend TP Device \\.\PhysicalDrive2 status 50.


  • When you run the grep scsi *vmx command, you see output similar to:

    $ grep scsi *vmx

    scsi0:0.present = "TRUE"
    scsi0:0.fileName = "wlabsetest1-checkpoint.vmdk"
    scsi0:0.deviceType = "scsi-hardDisk"
    scsi0:0.ctkEnabled = "TRUE"
Cause:
CBT is enabled for the virtual machine.

If CBT is enabled on an SE sparse disk based pool, then space reclamation does not work.

Resolution:
To work around this issue, disable CBT on the parent virtual machine and recompose the pool.

Disable CBT for the OS disk (typically scsi0:0 ). For more information, see Enabling Changed Block Tracking (CBT) on virtual machines (1031873).

Note: Space reclamation only affects the OS disk, so disable the CBT on the OS disk only.

vMotion fails at 68% with the error: An error occurred restoring the virtual machine state during migration (2012207)

Symptoms

  • Cannot vMotion a virtual machine.
  • vMotion fails at 68%.
  • You see these error:
    • A General System Error
    • Failed to receive migration.An error occurred restoring the virtual machine state during migration.
  • If you navigate to the Virtual Machine folder, you see three vswp files instead of two
  • When using Windows 8, you observe errors in the vmware.log similar to:

    11-01T15:39:00.158Z| vmx| DUMPER: Item 'CtrCountX' [-1, -1] not found.
    11-01T15:39:00.158Z| vmx| VMGenCtrCheckpoint: Failing restore from old Win8 checkpoint

    Cause

    This issue occurs if the state of the virtual machine cannot be determined from the .vmx file.
    Starting with ESXi 5.0, by default, each virtual machine has two vswp files when the virtual machine is powered on. This issue occurs when the machine has three vswp files, instead of two.

    Resolution

    To work around this issue in a View environment:
    1. Log in to the VMware View Administrator page.
    2. Click Inventory > Desktop.
    3. Click the virtual machine for which vMotion failed.
    4. Click the More commands drop down and select Enter Maintenance Mode.
    5. In vCenter Server, right-click the virtual machine and click Power > Power off.
    6. Right-click the datastore and browse to the virtual machine storage location.
    7. Verify that the vswp files are no longer present.
    8. Right-click the virtual machine and click Power > Power On

      Note: Do not use Restart or Reset.

    9. Right-click the datastore and browse to the virtual machine storage location.
    10. Verify that the virtual machine has only two vswp files.
    11. Perform the vMotion again.
    To work around this issue in a non-View environment:
    1. Connect to vCenter Server using the vSphere Client.
    2. Right-click the virtual machine and click Power > Power off.
    3. Right-click the datastore and browse to the virtual machine storage location.
    4. Verify that the vswp files are no longer present.
    5. Right-click the virtual machine and click Power > Power On

      Note: Do not use Restart or Reset.

    6. Right-click the datastore and browse to the virtual machine storage location.
    7. Verify that the virtual machine has only two vswp files.
    8. Perform the vMotion again.
    If the issue persists and you still see three vswp files:
    1. Connect to vCenter Server using the vSphere Client.
    2. Right-click the virtual machine and click Power > Power off.
    3. Right-click the datastore and browse to the virtual machine storage location.
    4. Right-click the vswp file and click Move To.
    5. Expand and select a temporary destination location where you want to save the the files and then click Move. You can also rename the vswp file.
    6. Right-click the virtual machine and click Power > Power On.

      Note: Do not use Restart or Reset.

    7. Right-click the datastore and browse to the virtual machine storage location.
    8. Verify that the virtual machine has only two vswp files.
    9. Perform the vMotion again.