Archive | November, 2017

Export VMware App Volumes – Writable Volumes from VSAN Datastore

28 Nov

If you have a VMware VSAN environment and you wanted to export a App Volumes – Writable Volumes from the vsanDatastore to another datastore, storage or for VMware GSS/R&D for further analysis go ahead and read further!

Background – The traditional way of exporting the Writable Volumes from the source vsanDatastore was to attach the *.vmdk to a dummy VM as a “Existing Hard Disk” and export the dummy VM using the “Export OVF Template” option from the vCenter. Repeat all the steps on target datastore where-in it needs to be imported. However, if you want an alternate and easy method than the dummy VM then follow the below steps.

Step by Step Instructions:

— SSH to any ESXi Host Resource Cluster where the WV is stored and browser to the cloudvolumes/writable directory location:

# cd /vmfs/volumes/vsanDatastore/cloudvolumes/writable (This is the location where all end-user writable volumes are stored)

— Now search for the end-user (E.g twood) for which you want to export the Writable Volumes.

# ls -lh | grep twood
User to export WV

— Now lets open the *.vmdk file using “cat” command to retrieve the Object ID information. Make a note of the ObjectID

# cat DOMAIN!5C!twood.vmdk

Cat to find ObjectID

— In my scenario the Object ID was properly pre-created I didn’t have to use the objtool to find out the Object opened. However, in some cases you might have to run the following command

# /usr/lib/vmware/osfs/bin/objtool open -u (Where Object ID is displayed using the ‘cat’ command

This screenshot below is an example of situations where in the Object ID is not properly pre-created. It will provide you with an output Object Opened at path:
Objecttool Output

— Now using WINSCP login to the same ESXi Host and go to the path:
Object ID – /vmfs/device/vsan/d17efe58-5610-4dd2-0d9e-ecf4bbea2830 (my scenario)
Or/else Object opened at path in the screenshot above.

Download the file “d17efe58-5610-4dd2-0d9e-ecf4bbea2830” which is Writable Volumes (*.vmdk) file and move the files to local or remote location that you are using the WINSCP tool.

— Rename the Object ID to a friendly name shown in the cloudvolumes/writable Directory Folder. I renamed it (DOMAIN!5C!twood.vmdk)

— You don’t need the *.vmdk.metedata file

— The Writable Volumes is now exported out of the VSAN environment you can attach the *.vmdk to a non App Volumes Agent machine to look at the contents inside the Writable Volumes. If you are going to send the vmdk to VMware GSS/R&D make sure to zip it before uploading

I hope you will find these steps useful and help you export a Writable Volume from your vsanDatastore. I haven’t been able to try AppStacks with this method its on my to-do list.

Thanks,
Aresh Sarkari

McAfee Exclusion for VMware App Volumes 2.x – 100% CPU Issues

27 Nov

In your Virtual Desktop Infrastructure with the following configurations:

If you start noticing 100 % – CPU Usage for prolonged period of time and the Horizon Session getting disconnected from time to time after launch then you might need to include the following exclusion within your Writable Volumes (UIA+Profile) snapvol.cfg file:

#McAfeeExclusion
exclude_process_path=\Program Files\Common Files\McAfee\SystemCore

My colleague Daniel Bakshi has written an extensive blogpost on how to modify the snapvol.cfg for individual or group of end-users please reference it to make the necessary changes – Using the VMware App Volumes snapvol.cfg File to Customize Writable Volumes

I hope you will find these exclusion useful and will help you resolve a similar issue a lot quicker. A big thanks to Art Rothstein in helping to troubleshoot and resolve the issue.

Thanks,
Aresh Sarkari

Create a Memory Dump from a Suspended Virtual Machine – VMware vSAN

10 Nov

If you have a VMware VSAN environment and you wanted to capture a memory dump of the Virtual Machine for debugging or want to provide memory.dmp to VMware GSS or R&D for further analysis go ahead and read further!

Use Case – In our scenario had a few VDI Desktops running Windows 10 1607 + Horizon 7.3.1 + App Volumes Writable Volumes 2.13.1 + UEM 9.2.1 that were getting into unresponsive state. As a last resort we wanted to capture the memory dump to find out more what is causing the VM to get unresponsive.

Step by Step Instructions:

— Using the vCenter console select the Virtual Machine VM – Power – Suspend

— This will create the *.vmss and *.vmem file for Debugging. (Note the *.vmem file is applicable for ESXi 6.0 onwards)
VM Directory

— Make a note of the ESXi host Name/IP for the VM is in Suspend state

— SSH to the ESXi Host and browser to the VM Directory location:

# cd /vmfs/volumes/vsanDatastore/od-av-troub-1 (Where “od-av-troub-1” is the VM name)


— Now lets open the *.vmem file using “cat” command to retrieve the Object ID information. Make a note of the ObjectID

# cat od-av-trou-1-7622414e.vmem

Object ID

— In my scenario the Object ID was properly pre-created I didn’t have to use the objtool to find out the Object opened. However, in some cases you might have to run the following command

— Now using WINSCP login to the same ESXi Host and go the path:
Object ID – /vmfs/device/vsan/2c86055a-573b-d20a-5cdf-ecf4bbea1e48 (my scenario)
Or/else Object opened at path and download the file “2c86055a-573b-d20a-5cdf-ecf4bbea1e48” which is your ”*.vmem file and move the files to local or remote location that you are using the WINSCP tool.

— Rename the Object ID to a friendly name shown in the VM Directory Folder. I renamed it (od-av-trou-1-7622414e.vmem)

— For the *.vmss (od-av-trou-1-7622414e.vms) you can directly WINSCP to the ESXi Host and go to the location in the table and move the files to your local or remote location

— Once you have both the files *.vmem and *.vmss you can use a VMware Vmss2core Fling and convert it to a dump. Please make sure you meet the requirements and use the appropriate switches to your environment

# vmss2core -W8 od-av-trou-1-7622414e.vmss od-av-trou-1-7622414e.vmem 

— The above command will generate a memory.dmp file which can used in WINDBG for further analysis. If you are sending the dump file to someone make sure use *.zip and compress it before sending.

I hope you will find these steps useful and save a lot of time during daunting unresponsive VM issues. A big thanks to Frank EscarosBuechsel to helping with the entire procedure.

Thanks,
Aresh Sarkari