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.

Saturday, December 13, 2014

Connecting to VMware View ADAM Database (2012377)


Note: Ensure to take a complete backup of the ADAM database before proceeding. For more information, see Performing an end-to-end backup and restore for View Manager (1008046).

Windows Server 2003

To connect to the View ADAM database:
  1. Log in to one of the View Connection Servers as the domain administrator.
  2. Click Start > Programs > ADAM > ADAM ADSI Edit.
  3. In the console window, right-click ADAM ADSI Edit and Click Connect to.
  4. Under Connection name, type View ADAM Database.
  5. Under Server name ensure localhost is selected.
  6. Under Port ensure 389 is entered.
  7. Under Connect to the following node, Select Distinguished name (DN) or naming context.
  8. In the field under Distinguished name (DN) or naming context type:

    dc=vdi,dc=vmware,dc=int
  9. Click OK.
  10. Click View ADAM Database [localhost:389] to expand.
  11. Click DC=vdi,dc=vmware,dc=int to expand.

Windows Server 2008

To connect to the View ADAM database:
  1. Log in to one of the View Connection Servers as Domain Administrator.
  2. Click Start > Administrative Tools > ADSI Edit.
  3. In the console window, right-click ADSI Edit and Click Connect to.
  4. In the Name field type:

    View ADAM Database
  5. Select Select or type a Distinguished Name or Naming Context.
  6. In the field below Select or type a Distinguished Name or Naming Context, type:

     dc=vdi,dc=vmware,dc=int
  7. Select Select or type a domain or server.
  8. In the field below Select or type a domain or server, type:

     localhost:389

  9. Click OK.
  10. Click View ADAM Database [localhost:389] to expand.
  11. Click DC=vdi,dc=vmware,dc=int to expand.
Note: If you are unable to connect using dc=vdi,dc=vmware,dc=int, try using dc=vdi;dc=vmware;dc=int.

Wednesday, December 3, 2014

VMKcore partitions on ESXi hosts with non-local Disks

When running ESXi from local storage, a VMKcore partition is created during install.
If your ESXi Host 5.0/5.1/5.5 experiences a Purple Screen Of Death (PSOD), it hopefully creates a diagsnostic coredump. This coredump contains useful information for root cause analysis.

When a PSOD should occur, you can retrieve the dump information using the esxcfg-dumppart command: esxcfg-dumppart –log <ESX dump file> or esxcfg-dumppart –L <ESX dump file> from a shell session.

If there is no available disk partition for a coredump on your ESXi host, such as in Auto-Deploy or "USB/Memcard installs" where there is no local disks, you will get the following error message:

No vmkcore disk partition is available and no network coredump server has been configured. Host core dumps cannot be saved.

In such configuration cases, it is better to move the core dumps to a datastore. This has to be a VMFS volume, which rules out NFS. Since the vmkcore dump partition has to be available at boot time, software iSCSI is ruled out too. Only hardware iSCSI or FC LUNs are possible.

Setting VMKcore partition
The following steps are needed to configure the vmkcore partition. In my example I’m using a 10GB LUN provisioned by iSCSI.
Create the LUN
On my shared storage I created a 10GB iSCSI target and assigned it to my ESXi host. Then on the ESXi host you add the iSCSI target. Do a rescan and then add the iSCSI target like you would normally add a new datastore by pressing the “Add Storage” option in the Storage menu on the configuration tab. Choose to add a Disk/LUN and name it something like: vmkcore-esx01. After a rescan the LUN should be available in your storage view.
Change the partition type
Now the datastore needs to have the disk type changed. To do this you will have to logon to the ESXi host using tech support mode. After you are logged in, list all partitions using the fdisk -l command. You will now see a list of partitions in which you should search for your 10GB disk. In my case it looked like:
Disk /dev/disks/naa.5000144f33903730: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Now to change the partition type, run fdisk /dev/disks/naa.5000144f33903730 (copy it from your fdisk list). In fdisk hit “t” to change the partition’s ID, then hit “fc” to change the partition type to VMKcore. Now hit “w” to write the partition table and exit fdisk.
Set and activate the partition
The last step is now to tell ESXi to use a new vmkcore partition using the following command. First we double check for suitable vmkcore partitions:
esxcfg-dumppart –f
 
If the fdisk action went well, you should now see the /dev/disks/naa.5000144f33903730 partition again in the list. To set the partition use the following command:
esxcfg-dumppart -s naa.5000144f33903730:1
If you receive the message: “Unable to set dump partition naa.5000144f33903730:1. 
Use the command switch -a to activate the partition using the following command:
esxcfg-dumppart -a naa.5000144f33903730:1