Category Archives: View

Sending Horizon View logs via Syslog

Been experimenting with the vCenter Log Insight beta and have all the devices capable of sending syslog sending it to the Log Insight appliance. Pretty cool stuff. However, I deal a lot with Horizon View connection servers and their various logs, and given the ability of Log Insight to ferret out and find details in logs, I thought it would be great to pipe the View logs in to Log Insight for digestion.

Turns out this is pretty simple using Datagram SyslogAgent which not only can send Windows event logs, it can also follow any text log file and pipe it to a remote Syslog server. The great thing is the agent is free and a breeze to install.

Simply download the zip and extract it someplace permanent (Program Files), then run the SyslogAgentConfig.exe utility. Install the service, enter the syslog server IP and port, enable forwarding of event logs if you like, and then enable forwarding of application logs. I created two application log entries – pcoip and Vmware View, as they are in different folders. Editing one allows you to choose the directory and parsing options:

I used the ‘Suggest Settings’ button which will parse the files and determine the appropriate options.

Once done, just start the service and watch syslog data flow to your syslog server!

Also super handy, the settings are stored in the registry which can be exported to other View servers to make installation and configuration a snap. Just export “HKEY_LOCAL_MACHINE\SOFTWARE\Datagram\SyslogAgent” and its child keys, delete the “LastRun” entry from the .reg file and then import the .reg file to the other hosts, then run SyslogAgentConfig.exe which will show the copied configuration. Install and start the service.

View Admin dashboard for vCenter Server 5.1 displays the message: VC service is not working properly

Regarding VMware KB: View Admin dashboard for vCenter Server 5.1 displays the message: VC service is not working properly, I encountered this when upgrading a vCenter 5.0 host to 5.1.

When it was all said and done, I checked the View 5.1.3 console and found the vCenter objects in a red error state, saying the service was not working properly.

I edited the vCenter server in View and it gave me the incorrect username/password. Since that is one of the issues in the KB, I followed the steps to move the View domain to be above the System domain in SSO.

Seems like an obvious thing to do for a new SSO installation – wish the SSO installer would have done this.

Once moved, the vCenter objects turned green and provisioning was able to run.

Determining linked-clone space usage

I wanted to understand how VMware View linked-clone virtual machines consume space. Thankfully, Andre Leibovici has a great article “How to read Linked Clone Storage Provisioning metrics in vCenter“, describing these three storage metrics that are visible from a VM’s Summary tab in vSphere. (Need a review of how linked-clones work? Check out Andre’s “VMware View 4.5 Linked Cloning explained“)

These three storage metrics for every VM are described as follows:

  • Provisioned Storage: amount of total storage provisioned to a VM, since thin-provisioning is in use. This only includes files in the VM directory and is the sum of the “Provisioned size” column in the VM’s folder on the datastore. These files include the main VM disk which actually points to the replica, and then also the snapshot/delta disk. So easily, a linked clone has a provisioned size that is double that of the master VM (and therefore the replica). But it’s slightly misleading because the replica will not grow, only the VM’s snapshot/delta file will grow as the VM is used, until the next recompose.
  • Not-shared Storage: the total storage actually in use by the linked-clone, which only includes files in the VM directory. This would be the sum of the “Size” column in the VM’s folder on the datastore, and is data that the linked-clone has written after recompose or refresh: changes recorded in the delta (snapshot) disk.
  • Used Storage: the sum of storage used to support the existence of the virtual machine – includes the replica disk as well as changes that the VM has written since recompose or refresh.

With these key pieces of information, we can see that the most important metric is “Not-shared Storage”. However, “Used Storage” is useful to compare space savings. If the linked-clone VM was a full-blown normal VM, it would consume the amount indicated in “Used Storage”. But since it is using linked-clone technology, it only actually uses the amount indicated in “Not-shared Storage”, because the main bulk of the VM’s data (operating system, applications baked in to the image) is actually stored in the replica disk which is also used by all the other linked-clones.

If you want to compare across the entire environment and generate a space savings calculation, a bit of powershell can accomplish this:

Function GetUsage {
	$VMs = get-datastore $datastore | get-vm | get-view
	$VMs | foreach-object {
		$VMName = $_ | select -expandproperty name
		$VMUnshared = $_ | select -expandproperty storage | select -expandproperty perdatastoreusage | select -expandproperty Unshared
		$VMUnsharedMB = [math]::round($VMUnshared/1MB,2)
		$VMUsed = $_ | select -expandproperty storage | select -expandproperty perdatastoreusage | select -expandproperty Committed
		$VMUsedMB = [math]::round($VMUsed/1MB,2)
		$UsageObj = New-Object System.Object
		$UsageObj | add-member -type noteproperty -name Name -value $VMName
		$UsageObj | add-member -type noteproperty -name UsageMB -value $VMUnsharedMB
		$UsageObj | add-member -type noteproperty -name FullUsageMB -value $VMUsedMB
	} | sort -property Name | export-csv c:\temp\usage-$datastore.csv -notype

GetUsage "Linked_Clones_01"
GetUsage "Linked_Clones_02"

To run, save it to a file and change the datastores on the “GetUsage” lines (add or remove datastores as needed) and change the CSV path as necessary (default: c:\temp). Connect to a vCenter server (connect-viserver) and run the script. The resulting CSV file will have three columns: Name of the VM, UsageMB (“Not-shared storage”) and FullUsageMB (“Used Storage”).

By adding up the UsageMB column and comparing it to the sum of the FullUsageMB column, one can easily see the difference in space usage by using linked-clone technology versus full-blown virtual machines. To calculate the space savings percentage, use the formula (1-(Usage/Full)).

A customer with over 3,000 linked-clone desktops (using a master VM image of 30GB) is only using 6.55 TB on disk. If these were full-blown virtual machines, the customer would consume over 91TB. By using linked-clones, the customer is realizing a space savings of 93%. Pretty cool stuff.