Adding NFS Storage to the Data Virtual Appliance

Note: If you are using Horizon Workspace 1.5 check the notes at the end of the post.

Before letting users add their files in Horizon Workspace it is important to dedicate enough storage space.

To add space to the data-va you have 2 options:

  • Add a larger VMDK
  • Add an NFS mount

Since it’s not advisable to go the VMDK way if you have more than 6TB of data, i always like to use NFS mount. Another reason is that files won’t be sitting in the data-va so whatever happens to that virtual machine we don’t have to worry about data.

In my lab environment i use Nexenta as primary mean of storage for all needs, including VMware datastore, so i just added another share to export via NFS to use with the data-va:



I added the data-va IP address as root access for the share and also added the Extra Option “anon=0”,

SSH to the data-va with the user ‘sshuser’:

su -
cd /opt/vmware-hdva-installer/bin
./ --nfs

Note: “” is my data-va interface on the Nexenta network segment while “” is my Nexenta interface and “/volumes/vsphere_01/data-va” is the folder path of my NFS export on Nexenta.

You should get an output like this:

HOST: is alive.
mount.nfs: timeout set for Wed Jul 31 11:47:39 2013
mount.nfs: trying text-based options 'hard,rsize=32768,wsize=32768,intr,addr='
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying prog 100005 vers 3 prot UDP port 33327 on /opt/zimbra/store29 type nfs (rw,sync,noatime,hard,rsize=32768,wsize=32768,intr)
Error occurred: directory does not exist or is not writable: /opt/zimbra/store29
zmvolume failed at ./ line 49.

You see an error? Well, it’s kind of normal. I don’t know why but this script always fails at the same point. After a while and with the help of VMTN Community i figured out where it fails and how to manually finish the job.

Let’s first check that at least the NFS is mounted:

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda3 39G 1.9G 35G 5% /
udev 2.0G 152K 2.0G 1% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sda1 128M 21M 101M 17% /boot
/dev/mapper/zimbra_vg-zimbra 9.9G 1.1G 8.3G 12% /opt/zimbra
/dev/mapper/store_vg-store 9.9G 151M 9.2G 2% /opt/zimbra/store
/dev/mapper/db_vg-db 30G 1.2G 27G 5% /opt/zimbra/db
/dev/mapper/index_vg-index 9.9G 151M 9.2G 2% /opt/zimbra/index
/dev/mapper/redolog_vg-redolog 12G 159M 12G 2% /opt/zimbra/redolog
/dev/mapper/log_vg-log 9.9G 153M 9.2G 2% /opt/zimbra/log
/dev/mapper/backup_vg-backup 20G 174M 19G 1% /opt/zimbra/backup
/dev/mapper/data_vg-data 30G 173M 28G 1% /opt/zimbra/data 87G 32K 87G 1% /opt/zimbra/store29

Let’s change permission on the mount point so the zimbra user can write on the path:

chown -R zimbra:zimbra /opt/zimbra/store29
su - zimbra -c 'zmvolume -l'

The output would be something similar to this:

Volume id: 1
name: message1
type: primaryMessage
path: /opt/zimbra/store
compressed: false
current: false

Volume id: 2
name: index1
type: index
path: /opt/zimbra/index
compressed: false
current: true

Volume id: 3
 name: store78
 type: primaryMessage
 path: /opt/zimbra/store29
 compressed: false
 current: true

If you see “type: primaryMessage” and “current: true” for the mount point of the NFS mount then you are good to go, the new path is the primary storage for files.

You might find yourself with the NFS share mounted but with the missing entry in the output of the command ‘zmvolume -l’; in that case after changing the permissions we create the entry manually:

su - zimbra -c 'zmvolume -a -n store78 -t primaryMessage -p /opt/zimbra/store29 --compress false'
su - zimbra -c 'zmvolume -l | tail -7 | head -1 | cut -f2 -d:'
su - zimbra -c 'zmvolume -sc -id 3'
su - zimbra -c 'zmvolume -l'

The output now should look like the above one. Let me explain the above commands:

  • ‘zmvolume -a -n store78 -t primaryMessage -p /opt/zimbra/store29 –compress false’ : Creates an uncompressed store of type primaryMessage on the NFS mount point;
  • ‘zmvolume -l | tail -7 | head -1 | cut -f2 -d:’ : Finds the ID of the store we just created;
  • ‘zmvolume -sc -id 3’ : Sets the newly created storage as current using the store id (3 in my case);

Now files added by users to the data-va should be written on the NFS share.

Take a look at the CLI Command for Horizon Workspace Data Guide for more info on data-va commands.

8/7/13 UPDATE1: I fixed some IP addresses and paths in the outputs that don’t match my configuration. I have 2 labs and i seem to have taken a part of them in one lab and a part in another. Sorry for the inconvenience.

8/7/13 UPDATE2: It would seem like they fixed the script to mount the NFS share in Horizon Workspace version 1.5 since i used it to mount an NFS share in my lab today and i had no issue at all.

VMware Horizon Workspace 1.5 is out!

I went to check the documentation of Horizon Workspace and i can see there’s a whole new section for version 1.5!

Here’s the what’s new in the release notes:

  • Management of VMware® Ready™ Android Devices. Added Android container management for VMware Ready devices.
  • Oracle Support. Added Oracle and Oracle RAC as supported databases.
  • Unified Policies. Made changes to the policy framework for consistency and flexibility. Added a policy previewer.
  • Localized Support. Support for French, German, Japanese and Simplified Chinese localizations.
  • Change in VMware® ThinApp™ licensing tracking. Added per-device licensing support for ThinApp packages.
  • Customizable Getting Started Guide. A Word template with graphics that you can use to create a customized Horizon Workspace getting started guide to meet the unique needs of your end users. See the Getting Started ZIP file.
  • Numerous Bug Fixes. Improved the stability, performance, and scale of Horizon Workspace by implementing a variety of bug fixes.

The upgrade path from previous versions is described in the documentation so i guess once I’m done with the present series of articles i will write a post about upgrading.

How to replace Horizon Workspace 1.0 self-signed certificates with Microsoft CA certificates

UPDATE: If you are deploying Horizon Workspace 1.5 you should look at this post.

In the last post we generated new certificates from an internal Microsoft CA to use them as replacement of the Horizon Workspace self-signed certificates that are created during the setup process.

For certificates to work correctly, all parties in the process need to trust the Certification Authority; this include all servers and clients involved in the Horizon Workspace deployment.

Because of this, before applying the new certificates to Workspace virtual appliances we need to add our internal Microsoft CA to the list of trusted Certification Authorities; this step is not needed if you are buying certificates from a public CA that is already trusted, Verisign can be an example.

In this phase you will need to connect via ssh to all 5 virtual appliances with the user ‘sshuser’ (password is the same as ‘root’) and raise to ‘root’ with “su -“; you will then copy the CA certificate (ca.pem if you followed my previous post) via SCP in the home directory of user ‘sshuser’ then do the following:

cp /home/sshuser/ca.pem /etc/ssl/certs

Then do the following on the service-va and connector-va virtual machines:

/usr/java/jre1.6.0_37/bin/keytool -import -trustcacerts -file /etc/ssl/certs/horizon_private_root_ca.pem -alias horizon_private_root_ca -keystore /usr/java/jre-vmware/lib/security/cacerts

In my case:

/usr/java/jre1.6.0_37/bin/keytool -import -trustcacerts -file /etc/ssl/certs/ca.pem -alias vsphere-va -keystore /usr/java/jre-vmware/lib/security/cacerts

And run the following on the data-va:

/opt/zimbra/jdk1.7.0_05/jre/bin/keytool -import -trustcacerts -file /etc/ssl/certs/horizon_private_root_ca.pem -alias horizon_private_root_ca -keystore /opt/zimbra/jdk1.7.0_05/jre/lib/security/cacerts

In my case:

/opt/zimbra/jdk1.7.0_05/jre/bin/keytool -import -trustcacerts -file /etc/ssl/certs/ca.pem -alias vsphere-va -keystore /opt/zimbra/jdk1.7.0_05/jre/lib/security/cacerts

Note: The password to import the CA in the store is “changeit”.

Note: If you have an intermediate CA certificate you will have to run the same commands for that certificate too.

At this point your internal CA should be trusted but at times I’ve seen this happening only after a reboot of all virtual machines, so let’s just stop the vApp and restart it.

Changing the certificates is a less tedious process and it can be performed entirely using the web interface. Open your browser and connect to the Workspace admin page, in my case and go to “Settings” -> “View Virtual Appliances System Configuration”:


Then click on “SSL Certificate” and paste certificate (horizon.pem) and private key (key.pem) from the files we created earlier, then press “Save”:


You will get a green box as a confirmation.
Now go to “Module Configuration” -> “Go To Connector”:


Now go to “SSL Certificate” and do the same as you did before pasting certificate and private key:


Now you should be able to connect back to the Workspace admin page and notice that you are running with the new certificates, and in my case i have no certificate warning because my workstation is domain joined and by default it trusts the Microsoft CA:


Well that’s great, isn’t it?

There’s still a lot of work to do to complete our environment but are well on our way.

More in the posts to come, see you there!

Using a Microsoft CA to generate certificates for Horizon Workspace

During installation of Horizon Workspace in the last post we used self-signed certificates for simplicity but when you will put Workspace in production you will definitely want to replace those certificates.

In this post we will use an internal Microsoft CA to request certificates for our Horizon Workspace implementation.

Note: The installation of a Microsoft CA is outside the scope of this article.

If you connect to your Horizon Workspace FQDN you will see the classic browser warning when you connect to an SSL website which certificate has been released by a Certificate Authority you don’t trust.

In fact if you take a close look at the certificate you will easily notice the following:


You can see how we don’t trust the CA as it is stated in red and as you can see from the certificate tree at the top.

We need to create a certificate request to pass to our Microsoft CA so that it can process it and spit out a certificate for us. There are several tools to create certificate requests but i like to use OpenSSL because it is available on almost every operating system so if you learn how to do it from that you will be able to do it in most situations.

The steps i am going to take will work on every platform, regardless the fact that i will do this on a Mac you will be able to take the same steps on a Windows box. You can find OpenSSL binaries for Windows here.

On a Mac, open a Terminal window, move to the “/bin” directory of your OpenSSL installation and run the following commands:

sudo openssl genrsa -out key.pem 2048
sudo openssl req -out horizon.csr -key key.pem -new

After running the second command we will be presented with a few questions to compile in order to create a certificate request:

Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Lazio
Locality Name (eg, city) []:Roma
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyVirtuaLife.Net
Organizational Unit Name (eg, section) []:IT Department
Common Name (e.g. server FQDN or YOUR name) []
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

The first command will generate a private key (key.pem) that we will use for our request, the second command will actually create a request file signed it with the private key we just created.

The request file (horizon.csr) can be opened as a text file and it should look like this:


This will be correctly interpreted by the CA as a valid request but we won’t be able to read it. If you want to check if everything is ok you can do it like this:

openssl req -text -noout -in horizon.csr

You will see plenty of info and among that you will find those you inserted in the request:

Certificate Request:
        Version: 0 (0x0)
        Subject: C=IT, ST=Lazio, L=Roma, O=MyVirtuaLife.Net, OU=IT Department,

Note: The common name value is what your browser checks to be the same of the website you are trying to access, if different it will throw an error.

To pass the request to a Microsoft CA just access the web portal of your CA and click “Request a certificate” -> “advanced certificate request” and then paste your request as follows:


Select “Web Server” then click “Submit” and download the Base 64 encoded certificate:


You should get a file called “certnew.cer” that i normally rename in “horizon.pem”.

You should also get the CA certificate file, to download it go back to the homepage of your CA and click on “Download a CA certificate, certificate chain, or CRL”, the you should be here:


Select “Base 64” and then “Download CA certificate”.
Whenever you download a certificate from a Microsoft CA it will be called “certnew.cer” so you can see why it’s a best practice to rename them, i usually call this “ca.pem”.

At this point we should have the following:

  • key.pem (private key)
  • horizon.pem (the horizon workspace certificate)
  • ca.pem (the certification authority certificate)

Clarifying the certificate formats chaos
Every guide you will find out there that instructs you how to generate certificates will most of the time do a bad job explaining the various kind of formats, the difference between them and when to use one kind or another. Since i don’t want to take credit for something i didn’t do i want you to know that the following is taken from this webpage where you will also be able to convert different types of certificates if you need.

When you are dealing with certificates you will find different formats such as pem, der, p7b, and pfx. A Windows server for example exports and imports .pfx files while an Apache server uses individual PEM (.crt, .cer) files. The following is a definition of the various formats i mentioned.

PEM Format:
The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extensions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.

DER Format:
The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms.

PKCS#7/P7B Format:
The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extension of .p7b or .p7c. P7B certificates contain “—–BEGIN PKCS7—–” and “—–END PKCS7—–” statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

PKCS#12/PFX Format:
The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

How to install Horizon Workspace using an external database

In the previous posts we’ve taken care of all the preparation steps so now we should be ready to get down to business and install Horizon Workspace.

First of all download the Horizon Workspace OVA from the VMware website and get a product key; trial is good if you didn’t purchase one yet and it should be ok for proof-of-concept.

Once you have the OVA file you can import it in vCenter using the usual “Deploy OVF from template” menu.

While we wait for the upload to complete we need to create records in our DNS server for every virtual appliance. Here’s how i configured mine in my lab:			cofigurator.vsphere.lab			service01.vsphere.lab			connector01.vsphere.lab			data01.vsphere.lab		        gateway01.vsphere.lab

You also need to create PTR records, if you have a Windows based DNS this can be done simply by selecting a flag while creating A records:


Note: You must have created the reverse zone in DNS before using this flag. Otherwise you can manually create PTR records in the reverse zone.

Go through the wizard, once you get to setting up the network for the virtual appliances fill gateway, DNS, subnet mask and pick a port group:

Ova network

If you followed previous posts you should have no problems filling up all the information. Make sure all virtual appliances are on the same network segment.

Now let’s assign IP addresses to different virtual appliances according to the DNS records we created:

Ova network 2

During setup the name of the virtual appliances will be assigned based on reverse lookup query of every IP address so it’s important to also to create PTR records because A records are not used for DNS reverse lookups and if they are missing the setup process will fail.
In my case i don’t have a specific timezone for my country but since i live in GMT+1 i can choose Paris. If you don’t know what to choose or make the wrong choice here you can change it later on and you will also have more options to choose from.

In case you want to change the timezone later, just finish the whole setup and before starting configuration ssh to all VAs, get ‘root’ prompt and run these commands:

rm /etc/localtime
ln -s /usr/share/zoneinfo/Europe/Rome /etc/localtime

The date command in the beginning and end are useful to see if the operation was successful.

Note: When you get to the end of the wizard remember to check the flag so that the vApp is powered on after deployment.

After the deployment you’ll notice that only the configurator-va will be powered on as this is where we will setup the whole Horizon Workspace solution, so let’s start by connecting to the console of the configurator-va with the vSphere Client or Web Client as you prefer. You will be asked to press enter to start setup and here is where your DNS reverse records will be checked:

Config 1

Make sure there is correspondence between what you see here and the names and IP addresses you wanted to assign. If everything is correct you can confirm and go ahead; you will be asked for ‘root’ password do be assigned to all Vas plus a bunch of settings we described when we compiled the checklist in previous posts:

Config 2

The interesting thing to note here is that the suggested FQDN would be the same name of the gateway that we set in the DNS records, but we want to put this out on the internet so we are choosing “”.

Remember: the FQDN cannot be changed after deployment. The only supported option to change it is redeploying the whole thing from scratch.

Note: You need to use a valid SMTP server or setup will stop.

After answering to all questions, which include SMTP and vCenter parameters, you will see quite a few things happening:

  • turning on and preparing VMs
  • setting root passwords
  • setting timesync
  • generating self-signed ssl certificated
  • setting workspace FQDN
  • configuring virtual appliances firewalls
  • starting webapps

Grab something to drink, make phone calls… this takes a while. At the end you will be instructed to press enter and connect to the configurator-va via HTTPS.

Config 4

Admin user is a local user that can access the configurator appliance in case of problems, but it’s not the Horizon Workspace administrator.

Fill up licensing details and click “Next”.

In the Database Connection Setup let’s pick the External Database option and use the vPostgres instance we created earlier:


click “Next”:

Db 1

Error while testing DB connection. I/O error:; nested exception is

Now, this is where it gets interesting!
We get an error, so we must have made some mistake in the vPostgres database… well, no we didn’t. The problem here is that the configurator-va doesn’t know the host “” because we didn’t create an A record for it in the DNS, so add it then try again:

Db 2

Error while testing DB connection. I/O error: No route to host; nested exception is No route to host

Ok, another error, we must have made a mistake. ACTUALLY NO. I pointed the Workspace record to the Load Balancer as suggested in the documentation but the setup doesn’t like this choice. After a while i figured it’s because in this phase we need to point it to the gateway-va ip address so it can correctly recognize itself, so go change the workspace record in DNS and try again:

Db 5

Error creating admin user. hostname in certificate didn’t match: !=

Crap. Error again. A different one.
I know it doesn’t look like it but we are making progresses here.
At this point i understood why the setup wanted me to use the gateway-va FQDN as Workspace FQDN. Our problem now is that the “” hostname doesn’t match with the common name of the certificate that has been generated for the gateway-va which in my case it “gateway01.vsphere.lab”, but we need something that can be used outside on the internet so what do we do now?

I found the solution in the VMTN communities which are always a great resource. First let’s connect to the configurator-va with the user ‘sshuser’ with the same password we chose for ‘root’ during setup, type “su -” and insert the ‘root’ password and once we have the “#” prompt the do the following:

cd /usr/local/horizon/lib/menu/secure
./wizardssl.hzn --makesslcert gateway-va 'workspace FQDN'

In my case:

cd /usr/local/horizon/lib/menu/secure
./wizardssl.hzn --makesslcert gateway-va

Now all certificates are generated again and pushed to all virtual appliances, but the gateway-va certificate will match to the Workspace FQDN, so now we should be set, let’s try again:

Db 3

Whooa! Finally. You don’t know how much it took me to figure this out. No really, stop guessing. You don’t WANT to know.
Another option i could think of is to configure the load balancer before setting up Horizon Workspace, and point “” record to it but it think it’s not practical to set up a load balancer if the application is not up yet because you would have no way to test it.

In other words what i do is:

  • standard setup
  • set internet FQDN as Workspace FQDN
  • temporary point Workspace FQDN to gateway-va
  • recreate certificates
  • complete setup

Later on we will complete the job configuring load balancers, changing DNS entries to point at them and generating new certificates that are not self-signed so all pieces fall into place. More on these activities in later posts.

Now it’s time to configure Active Directory integration:


Configure using your Active Directory LDAP structure.

The user ‘workspace’ is a user i created earlier in Active Directory and that is the user that will function as Horizon Workspace admin.

Click “Next”.

Accept defaults for user mapping.

Click “Next”.

Let’s discover the users:


Note: If you see an error tab it’s most likely because you didn’t compile fields Name, Last Name and Email for all users.

Now selecting groups:


Click “Add” next to the Active Directory groups that you want to add to the Horizon Workspace.

For SSL certificates just leave defaults and click “Next”.

In the “Select Modules” page enable all modules but the View module and click “Next”.


Click “Go to Horizon Workspace” and in the login screen use the credentials you’ve set during setup:


Note: The password was set on the user when it has been created in Active Directory.

You should get here:

Login 1

Congrats! You’ve setup Horizon Workspace and in the coming posts we will complete the job installing load balancers, taking care of SSL Certificates and so on.

Understanding Horizon Workspace components and installation prerequisites

In the last post i described in details how to prepare a vPostgres DB to host Horizon Workspace external database.

During the installation process, as we will see, you can choose to use an internal database or an external one but keep in mind that the internal database is ment only for testing purpose so if you are installing Horizon Workspace in a production environment you must have a VM with vPostgres installed as this is the only supported configuration, so you can understand why the first post was needed.

So now we are ready to install Horizon Workspace… well, not quite yet. It is very important to understand that to install this product there are number of preparation steps that need to be taken before actually getting our hands dirty and start having fun. Some of those steps include filling up some technical prerequisites and some are just decisions that need to be taken keeping in mind that during the installation phase there are some settings that cannot be changed afterwards unless redeploying the entire solution. This is something you definitely don’t want to find out after you’ve performed all the installation and configuration tasks and then have to start over again.

In this post we are going through all the prerequisites so with that out of the way we will be able to easily proceed with the deployment phase, but first let’s talk about the Horizon Workspace virtual appliances and their respective functions. The following is taken from the official documentation.

  • VMware Horizon Workspace Configurator Virtual Appliance (configurator-va): You start configuring Horizon Workspace with this virtual appliance, using both the Configurator virtual appliance interface and the Configurator Web interface. The configurations you make with the Configurator are distributed to the other virtual appliances in the vApp. Note: The configurator-va is the only component that cannot scale to multiple instances.
  • VMware Horizon Workspace Manager Virtual Appliance (service-va): Horizon Workspace Manager handles ThinApp package synchronization and gives you access to the Administrator Web interface, from which you can manage users, groups, and resources.
  • VMware Horizon Workspace Connector Virtual Appliance (connector-va): Horizon Workspace Connector provides the following services: user authentication (identity provider), directory synchronization, ThinApp-catalog loading, and View pool synchronization.
  • VMware Horizon Workspace Data Virtual Appliance (data-va): Horizon Workspace Data Virtual Appliance controls the file storage and sharing service, stores users’ data (files), and synchronizes users’ data across multiple devices.
  • VMware Horizon Workspace Gateway Virtual Appliance (gateway-va): Horizon Workspace Gateway Virtual Appliance is the single endpoint for all end-user communication. User requests come to the gateway-va virtual machine, which then routes the request to the appropriate virtual appliance.

System and Network Configuration Requirements
The preparation part is the longest and most important when deploying a distributed service such as Horizon Workspace, for this reason VMware prepared a detailed checklist to fill up before starting the installation process. The following is a list of all the things you will have to decide and mark down:

  • Horizon Workspace Fully Qualified Domain Name (FQDN)
  • Network Information for Configurator (configurator-va)
  • Network Information for Manager (service-va)
  • Network Information for Connector (connector-va)
  • Network Information for Data (data-va)
  • Network Information for Gateway (gateway-va)
  • Network Information for IP Pools
  • Active Directory Domain Controller
  • SMTP Server
  • vCenter Credentials
  • SSL Certificate (Optional)
  • Horizon Workspace License Key
  • Microsoft Windows Preview
  • External Database

Before getting into details let’s take a high level look at the architecture of Horizon Workspace as it’s meant to be in a production environment:


This picture (which is taken straight from the public documentation of the product) shows that every connection from users accessing the Horizon Workspace portal have to go through the Horizon gateway VM(s). The “(s)” easily shows how you can have one or multiple Horizon gateways, in which case you will also need some sort of load balancing mechanism in front of the gateways. The Horizon gateway virtual appliance runs nginx as web server that basically proxies every connection to the desired service so users actually need connectivity only to the gateways virtual appliances.

IMPORTANT: Placing the gateway VA in a separate network such as a DMZ network is not a supported configuration.

The following picture gives a better understanding of the network configuration requirements:


As you can see all communication go into the gateway VA and out to the other virtual appliances which are actually providing the services. Users will connect exclusively in HTTPS and the same is true also for most of communication between virtual appliances, so we will need to work a bit on SSL certificates at some point but it’s not mandatory in the setup phase as you can see form the above list since it is marked as optional in the prereqs.

Horizon Workspace FQDN
Choosing the FQDN is a tricky one because once you input it during the setup you can’t go back and change it, so it definitely deserves some thinking or you might find yourself redeploying from scratch. Most companies choose to have the same FQDN for both internal and external connections which makes it perfectly transparent for users to reach Workspace no matter where they are located; obviously the FQDN will resolve with a public IP for external users and with a private IP for internal users, hence the need of two sets of load balancers as you can see in the first picture.

Network configuration for virtual appliances
Just write down TCP/IP configurations that you intend to assign to the five virtual appliances, including DNS configuration. I encourage you to use consecutive addresses for simplicity.

IP Pools
Honestly this is a little obscure to me. IP Pools are used as a set of IP addresses that you define and assign to a network in vCenter so that they can be used when you deploy a vApp. Funny is the fact that those addresses must not be the ones you will use for setting up the virtual appliances. Even funnier is the fact that if you deploy the vApp from the Web Client you don’t even have to create an IP Pool. I have no problems admitting my ignorance here on the usefulness and meaning of this step.

Active Directory Domain Controller
Self explaining. Since Horizon Workspace integrates with your Active Directory you will need to have IP address, basic parameters and credentials handy during the setup. Just keep in mind that your users in AD will need to have Name, Last Name and email address compiled before importing them in Horizon Workspace or the import will fail.

SMTP Server
This is used by users when sharing documents. Note that you must specify a working SMTP since a check is performed during the setup and you won’t be able to proceed otherwise.

vCenter credentials
If you are deploying Horizon Workspace I’m pretty sure you have these. 🙂

SSL Certificate (optional)
I like to deal with this after the initial deployment and this is another tricky one, so during the setup we will use default self-signed certificates for simplicity.

Horizon Workspace Product Key
Yes, you need one. 🙂
For a proof-of-concept you can request a trial key that will work for 100 users.

Microsoft Windows Preview
When using Microsoft documents in Horizon Workspace web portal you can get a preview without having Microsoft Office installed. The preview can be generated with a LibreOffice add-on that runs directly on the data-va or they can be generated on a Microsoft Server with Microsoft Office installed; the first is a free option and it’s usually good enough, the latest will grant you a higher level of compatibility but you will have to pay Microsoft licenses.

External Database
If you read my last post you should know about this already.

Now that you have all handy you are ready to install Horizon Workspace.

Preparing vPostgres as external Database for Horizon Workspace

Since most of blog posts around the internet speak about how to make a basic installation of Horizon Workspace i decided to start a series of articles with the intention to show a full blown Horizon Workspace setup suited for production use.

A basic installation is good for a proof-of-concept or a lab environment but you will see very fast how it won’t scale and how it won’t even be supported by VMware itself since, for example, it uses an internal DB.

Even if the internal DB is based on VMware vFabric Postgres, or vPostgres, you still need to have a separate VM with vPostgres dedicated to be the Horizon Workspace database if you want a supported configuration in your production environment.

If you want to install vPostgres you have 2 options: download RPM packages and install them on a supported platform or download the OVA appliance and import it in vCenter.

I am no DBA and i find it not fun at all to learn database stuff if i don’t have to so it was a pretty easy choice for me. I also found that in the documents section of the Horizon Workspace page in the VMTN community there is a nice guide about that specific scenario.

The following is my experience deploying the OVA and preparing vPostgres for Horizon Workspace.

Install and Setup Notes
First thing first you have to download the OVA from the VMware website. There is a trial version to use which if i’m not mistaking last 60 days before expiring. Note that we will need version 9.1 even if there is a newer version simply because this is the version supported in Horizon Workspace at the moment of writing.

Once the download is complete we can use standard tools and procedures to import the virtual appliance in your environment:

Deploy ovf
Use vSphere Client or Webclient to deploy the OVF file.

Deploy ovf 2
The process is pretty straightforward all the way down to the network configuration.

Now we have to log in as ‘root’ and this can be sometimes tricky because we don’t get to choose what the password is since it’s randomly generated when the OVA is imported but no need to worry, the password is shown on the login screen. It’s tricky also because the password is really long and complex and sometimes i haven’t been able to type it in correctly, no matter what (there is also a time window for typing it which doesn’t help either). If this happens to you as well just redeploy the virtual appliance and hope for a more friendly password, i’m sure you won’t need to deploy it more than twice to successfully log in.

Root login

Once you are successfully logged in as ‘root’ we need to change the password as indicated in the login screen using the following command:


Note that the same password will be set to both the ‘root’ and ‘postgres’ users; this is worth noting because by default you can SSH into the virtual appliance only with the ‘postgres’ user.

If you want to change the network configuration you can run the following command:


While logged in as ‘root’ edit the following config file:

vi /var/vmware/vpostgres/current/pgdata/postgresql.conf

Find the “max_connections” value and change it from 100 to 600:

max_connections = 600

Add a line right under the “max_connections” line:

search_path = 'saas'

Save the file and change the directory into “/opt/vmware/vpostgres/current/bin” and su to the ‘postgres’ user:

cd /opt/vmware/vpostgres/current/bin
su postgres

Verify that you are indeed in the “/opt/vmware/vpostgres/current/bin” folder:


Now we are going to create a script that will take care of all the operations needed to prepare the database for Horizon Workspace, paste the following into a text file:

        PASSWORD '123456'

ALTER ROLE horizon;

WITH OWNER = postgres
TABLESPACE = pg_default

\connect saas;
SET search_path = saas;

Change the ‘PASSWORD’ to whatever you want to use when you will make a connection to this DB with the ‘horizon’ user and save the text into a file, for example “/tmp/”.

Now let’s execute the script:

./psql -f /tmp/

If all goes well you should get an output similar to this:

You are now connected to database "saas2" as user "postgres".

At this point the documentation states to reboot the appliance so go ahead.

Before installing Horizon Workspace we will use a tool called pgAdmin to check that all went as expected; pgAdmin is available for almost every platform so just pick what you prefer and install it on your management workstation.

Let’s open pgAdmin and check everything is all right:

Pgadmin 1
Let’s connect to the DB with the credentials we’ve set.

Pgadmin 2
Check the user ‘horizon’ attributes which should look quite familiar.

Pgadmin 3
Same thing for the DB properties.

All right! We are now ready to install Horizon Workspace and point it to this newly created database.

In the coming articles i’ll show you just how to do that.

Licensing Notes
vPostgres is not part of the Horizon Workspace product or the Horizon Suite so you will have to purchase it separately.

If you want to check the status of the trial license you can do it with the following command:

cat /opt/vmware/vFabric/vf.vpg.log

If you see the following in the log file it means you are running on trial license:

[Mon Jul 22 15:32:35 2013] WARNING getComponentLicenseState: No local serial numbers, and the server hasn't yet provided a license state, using default evaluation licenses, exception: No server license state available
[Mon Jul 22 15:32:35 2013] INFO getComponentLicenseState: No local serial numbers, nothing from server, using default evaluation licenses.

If you purchased a valid license you can use it by creating the following file and pasting your licensing information in it:

vi /etc/opt/vmware/vfabric/vf.vpg-serial-numbers.txt

Here’s a sample of what a valid license information should look like:

XXXXX-XXXXX-XXXXX-XXXXX-XXXXX    [quantity=20, expiration=Permament, addon=1]

After that we need to change permissions on the file so that vPostgres can read it:

chgrp vfabric /etc/opt/vmware/vfabric/vf.vpg-serial-numbers.txt
chmod 644 /etc/opt/vmware/vfabric/vf.vpg-serial-numbers.txt

Now a restart of the service is needed and then we can check the log again:

service aurora_mon stop
service aurora_mon start
cat /opt/vmware/vFabric/vf.vpg.log

You should be able to read that vPostgres found a valid serial number:

[Mon Jul 22 15:57:05 2013] INFO getComponentLicenseState: Using local serial numbers

Sizing Notes
In the community document i mentioned earlier you will also find some useful indications about how to size the vPostgres VM and how to edit the virtual appliance settings in details to support up to 30000 users with Horizon Workspace. You can also install a second instance of vPostgres and setup an HA configuration at the database level if vSphere HA is not good enough for your availability concearns.

Here’s a brief description of sizing requirements for 30000 users:


Supported Platforms for manual RPM installation
If you want to build your own VM and manually install vPostgres using RPMs keep in mind the following list of supported operating systems:

  • Red Hat Linux RHEL 6.2 (64 bit)
  • SUSE Linux SLES 11 SP 1 (64 bit)

Refer to the official documents for detailed instructions on how to manually install vPostgres on supported platforms using RPMs.

%d bloggers like this: