VMware BIOS UUID, vCloud Director and Veeam Agent

Looking at the title it may seem a long and complicated story. Actually is a very simple one. While working in lab which is hosted by a vCloud Director (vCD) instance, I was testing a SQL Always ON Cluster and the Veeam Agent for Windows. I've created my 3 node cluster, installed the database, configured availability groups.  All went well until I tried to install the Veeam agent. This stopped with the error that  the same UUID was being utilized by all 3 nodes.

Well, all 3 VMs were deployed from the same vCD catalog VM. According to this VMware KB article, by default vCD keeps the same UUID value for cloned VM's. Since I did not have access to vCD to change the settings, the only choice was to actually modify the UUID of the VMs.

There are several ways of doing in it, from manual to programmatic (as can be seen in this KB article)

I've chosen PowerCLI variant. The steps are pretty straight forward:

• shutdown the VM
• get the current UUID
• change the UUID
• power on the VM

And the code to do it below. Do not forget to change the $newUuid (I used to modify the last digits from the current one).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

$vmName = "myClonedVm" $vm = Get-VM -Name $vmName $vm.extensiondata.config.uuid $newUuid = "00112233-4455-6677-8899-aabbccddeeff" $vm | Shutdown-VMGuest While ((Get-VM -Name $vmName).PowerState -ne "PoweredOff") { Write-Host -foreground yellow "... waiting for" $vmName "to power off" sleep 5 } $spec = New-Object VMware.Vim.VirtualMachineConfigSpec $spec.uuid = $newUuid $vm.Extensiondata.ReconfigVM_Task($spec) Start-VM -VM $vmName -RunAsync

vCloud Director 5.1 upgrade and missing sysadmin permissions

I`ve recently managed to crash my test lab. One of the rebuild tasks was to reinstall vCloud Director - the hard way: dropping the DB and recreating it. Next I was running the vCloud Director installation script (5.1.1), recreating the DB schema and so on. After a week I`ve decided to upgrade the vCD installation from 5.1.1 to 5.1.2.

After downloading the bin file (vmware-vcloud-director-5.1.2-1068441.bin) from VMware site and uploading it on my vCD cell , I`ve executed the bin and a long list of "Yes" ends up with an error:

Unable to update database statistics. Database user has insufficient privileges to update database statistics. To complete this step manually, run 'EXEC sp_updatestats' as the DBO or a member of the sysadmin fixed server role.

Next, I`ve been looking in the DB server (MSSQL) - logging in with vCD DB admin user (vcddbadmin) and checking if the rights are ok. And they were, since the user was dbowner. I`ve ran 'EXEC sp_updatestats' in query editor and ended up with another error:

Msg 15247, Level 16, State 1, Procedure sp_updatestats, Line 15
User does not have permission to perform this action.

It was stored procedure time: vcddb01 -> Programmability ->Stored Procedures -> System Store Procedures and after a few pages of scrolling down: sys.sp_updatestats. I`ve opened the stored procedure (Context menu - Modify) and on line 15 there was a check to see if the current user was sysadmin. Which, obviously it was not.

Below, a small SQL script that will display if the current user is sysadmin or not:

if is_srvrolemember('sysadmin') = 1
print  ' It is sys admin'
else if is_srvrolemember('sysadmin') = 0
print  ' It is NOT sys admin'

To solve the problem, I`ve added sysadmin role to the vCloud Director DB admin user (vcddbadmin) and ran again the stored procedure:

This time it worked ok and updated database statistics. I`ve checked back the installation procedure for vCloud DB and I`ve taken a look at KB 2034540 to see if I`veforgotten anything while creating the user for vCD DB. But it seems I did not. The only reference is to db_owner role. Since I am not a DB guy, I`ll just leave it as is, happy to have solved my problem. 

vShield Edge configuration and operational issues

In this post I will cover some of the aspects of using vShield Edge (vSE) devices at vApp level, mostly things I have learnt the hard way. I am currently using vCloud 1.5 and the aspects herein are related to this version. However, I will specify changes that appear in vCD 5.1. 

In vApp diagram, vSE is represented interposed between the vApp network and the organization network:

The symbol displays a firewall, if firewall services are active. vSE offers the following services:

• DHCP
• firewall
• routing 
• NAT

All configuration is done using vCD portal. DHCP services can be created for vApp network and the configuration is basic:

It is not possible to create MAC reservations, but basic service functions are available.

Firewall configuration has by default Deny policy enabled and allows any traffic going outbound:

vSE can be configured to send syslog messages to a central server, and it is highly recommended to do it if you want to debug anything. But the syslog server can only be configured globally at vCD level, not separately for each organization. If you are an organization admin, it will be difficult, if not impossible to get access to syslog server.. Other issue is that the graphical interface does not allow copy or clone rules.Which means a lot of manual work. To make things worse, you cannot add two different hosts or subnets in the source or destination field - no possibility to group more objects. More manual work. I do not know why they have provided such a bad interface to vSE.

Next service is NAT - by default vSE is configured in IP translation mode. VMs are assigned IPs from Organization network and vSE does the rest: source and destination NAT. 

Org network IPs can be statically assigned or automatically. But, they cannot be unassigned from a VM. If there are 10 VMs connected to the vApp network, then all 10 will be assigned IPs from the Organization network even if only 1 VM needs such an IP (simple use case - one arm load balancing topology). Adding the 1 IP used by vSE, a total of 11 IPs will be used. This is a problem since you might get into situations where you run out of IPs at Organization level (I did).

The only solution is to change NAT mode of vSE to Port forwarding. In which case you are limited to the IP of vSE. All requests are sent to vSE`s IP and it vSE does basic port forwarding:

Do not think of publishing in the vApp two services on the same port. You will not be able to do it.

A difference in 5.1 is that you can specify source and destination NAT separately.

Last feature that vSE provides is static routing. There is not much to talk about it - it allows adding of static routes:

One more limitation of vSE in 1.5 is that it has only 2 interfaces: one external and one internal. In 5.1 there are multiple network interfaces provided to external networks.

vCloud Director 5.1 brings other changes from 1.5:

• IP masquerading setting was removed
• there is no default rule on the firewall

More details about these two changes can be found here

Unfortunately, vSE brings too many technical limitations to be a useful firewall and in many cases architectural decisions have to be made to not use vSE. Changing vSE with other technologies that provide better firewall, NAT and routing functions also brings its own technological challenges.

Guest customization - vCloud Director and vSphere

One nice feature that VMware Tools brings is the possibility to inject and run scripts directly in the virtual machine - be it bash or batch. I`ve been using this feature called guest customization when deploying new virtual machines in either a vCloud organization or directly in vSphere environment.

Guest customization in vSphere using PowerCLI

I`ll start with vSphere, since I`ve done more customization in this environment than in vCloud. The task is simple: deploy a linux VM from a template and provide ssh connectivity. After template deployment, the VM runs and empty OS - no IPs, no routes, DNS, repositories... nothing. The solution is the following PowerCLI cmdlet: Invoke-VMScript. I will not explain the syntax since it can be found here. I`ll just show what it can do in next piece of code:

Start-VM $vmname
 
### check VMtools status 
$vmtoolsstatus = ""
do {
Start-Sleep -Seconds 5
$vm = Get-VM $vmname
$vmtoolsstatus = $vm.Guest.ExtensionData.ToolsRunningStatus
echo "Tools not running... waiting 5 seconds"
} while ($vmtoolsstatus -ne "guestToolsRunning")

echo "configuring hostname"
$hostnamecfg = "sed 's/HOSTNAME\(.*\)/HOSTNAME=${vmname}.${domain}/g' -i /etc/sysconfig/network; hostname $vmname"

Invoke-VMScript -VM $(Get-VM $vmname) -GuestUser $GuestUser -GuestPassword $GuestPassword  -ScriptType bash -ScriptText $hostnamecfg

First the VM is started. Then a loop checks that VMware Tools have started. After, the script is being build in text variable $hostnamecfg - in this case a sed in /etc/sysconfig/network file (RedHat based distro). Last, Invoke-VMScript cmdlet injects $hostnamecfg script in the guest OS and runs it. This way you can set up all network interfaces, routes, yum repositories, ntp, dns, ssh, start-stop services. For example changing yum repo for CentOS to a local repository:

echo "configuring YUM repo"
if ( $template -eq "template-CentOS6") {
$yumcfg = " sed -i '/mirrorlist=http:\/\/mirrorlist\.centos\.org/s/^/# /' /etc/yum.repos.d/CentOS-Base.repo;"
$yumcfg += " sed -i 's/#baseurl=http:\/\/mirror\.centos\.org/baseurl=http:\/\/yumlocal\.vmlab\.local/' /etc/yum.repos.d/CentOS-Base.repo;"
}

Invoke-VMScript -VM $(Get-VM $vmname) -GuestUser $GuestUser -GuestPassword $GuestPassword  -ScriptType bash -ScriptText $yumcfg 

Guest customization in vCloud Director

vCloud Director brings guest customization directly in the portal. After the VM has been deployed from a vApp template in virtual machine properties - Guest OS Customization, Customization Script field:

#!/bin/bash

if [ -f /etc/sysconfig/network-scripts/route-eth0 ]

then

sed -i 's/\.5\.1/\.52\.1/g' /etc/sysconfig/network-scripts/route-eth0

else

echo "192.168.60.0/24 via 192.168.52.1" >> /etc/sysconfig/network-scripts/route-eth0

fi

In the example above, a bash script checks to see if route file for eth0 exists. If it does, then it changes gateway for existing route (sed), if it does not it creates route-eth0  and adds the route. Upon Power on (or Power on and force recustomization) the script will be run inside guest OS. 

Adding a route for Windows OS will replace the bash script with a batch script:

@echo off

(

route add 192.168.60.0 mask 255.255.255.0 192.168.52.1 -p

)

The same rule as for vSphere applies: you can customize guest os (Linux or Windows) with whatever configuration you need and how much scripting allows it. I am not discussing workflow automation tools (vCenter Orchestrator), nor configuration management software (Puppet). It is just about making life easier for some repetitive tasks using basic scripting. 

vCloud Director storage calculation and allocation

A couple of days ago, my colleague trying to deploy a new vApp in an Organization vDC hit the storage limit. Because on paper he should have got enough space, he started to calculate the total size that VMs occupied on the storage and to compare it with what vCloud Director reported. After doing the math, he told me that vApps take 417 GB while vCD reports 451 GB. Where did 34 GB go? My first thought was the swap file for each VM:  Swap file size = Total VM RAM - Reserved Memory.   

But the swap file is created at run time and most of the VMs were stopped. Even if vCloud Director would reserve whole space from the beginning, regardless of VM power state, it would mean that all memory is reserved by default. Which was not the case for the Allocation pool. 

vCloud Director allocates space using the following formula:

Storage size allocated = Total storage of virtual machines + Total memory of virtual machines + Storage of templates/media

 
Equivalent storage of memory is allocated disregarding the power state of VMs and memory reservations - covering a scenario in which 0% memory guarantee is configured for vDC. Memory of VMs in template is not included in space allocation. 

Why is this important? It is because there is a misunderstanding of resource usage and allocation in vCloud Director, especially regarding storage. A vDC with 10 vCPU, 10 GB vRAM, 100 GB HDD will never be able to accommodate 10 VMs with 1 vCPU, 1 GB vRAM, 10 GB HDD.

Next time you calculate necessary storage space, be sure not to forget vRAM (or templates).

vShield Edge Gateway "IP Masquerading" in vCD 5.1

vCloud Director 5.1 comes with some changes from 1.5, in the sense that IP masquerading setting was removed and there is no default rule on the firewall. Since at office I work on 1.5 and since there is a glitch in the way NAT is implemented, it took me a bit of troubleshooting to figure it out.

My problem was simple - pass traffic out of the organization from a VM 192.168.20.100 to an external server at 192.168.1.200:

This is done in 3 steps:

• sub allocate the IP pool on the external network
• configure NAT rules
• configure firewall rules

First thing to do is sub-allocate external network IP pool. Go to vCD GUI, Edge Gateway, select the gateway, Properties menu - Sub Allocate IP Pools tab. Choose the external network and sub-allocate the Pool:

Second, configure NAT rules. Go to Edge Gateway, select the gateway, Edge Gateway services menu, NAT tab, Add SNAT. In the rule select the external interface - the one connecting to the external networks, fill in IP address or subnet of the source VMs and choose as destination IP one of the external IPs from the sub-allocated pool:

Third step is to configure the firewall rules (remember, no default rules in 5.1). Go to Firewall tab and add the rule. I have also added an incoming rule to make the Edge Gateway respond to ping.

Finish the configuration, go to your VM and test the connectivity. You may read about the changes in the following VMware KB.

However, if the test does not work, you can do a bit of troubleshooting: go to vSphere Client, open a console to Edge Gateway, enter admin/default credentials and use the following debug command:

debug packet display interface vNic_0 host_192.168.1.200

vNic_0 being the external interface and 192.168.1.200 the destination host, you should see echo requests from 192.168.1.61 to 192.168.1.200. If, by any chance, you see the original IP address not being NAT-ed, then try a restart of the Edge Gateway. And please let me know if you see such behavior.

Installing vCloud Director on CentOS and MS SQL Express - part 3

This is part 3 of a 3 part post that presents installation of vCloud Director 5.1 on CentOS 6.3 and MySQL Server 2012 Express

• part 1 presents Configuration of MS SQL 2012 Express Database for vCloud Director installation
• part 2 presents Configuration of CentOS 6.3 for vCloud Director
• part 3 presents Installation of vCloud Director 5.1

Installation of vCloud Director 5.1

Download the bin package from VMware site (vmware-vcloud-director-5.1.1-868405.bin) and transfer it on the server. Change permissions on the file and run it. Answer "yes" the when Linux distribution is checked and stop the installation at the second question.

[root@vcd5101 ~]# chmod u+x vmware-vcloud-director-5.1.1-868405.bin
[root@vcd5101 ~]# ./vmware-vcloud-director-5.1.1-868405.bin
Checking architecture...done
Checking for a supported Linux distribution...
You are not running a Linux distribution supported by vCloud Director.
Would you like to proceed anyway? [y/n] y
….
Would you like to run the script now? (y/n)? n

We stop the installation because VMware KB 1026309 states that the keytool to be used when generating SSL certificates is the one shipped by VMware which can be found at /opt/vmware/vcloud-director/jre/bin/keytool. It is time to generate SSL certificates (one for http and one for console proxy). 

[root@vcd5101 ~]# mkdir /opt/vmware/vcloud-director/certs

[root@vcd5101 ~]# /opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks -storetype JCEKS -storepass password -genkey -keyalg RSA -validity 365 -alias http

[root@vcd5101 ~]# /opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks -storetype JCEKS -storepass password -genkey -keyalg RSA -validity 365 -alias consoleproxy

[root@vcd5101 ~]# chown -R vcloud.vcloud /opt/vmware/vcloud-director/certs/

Setup transfer server storage /opt/vmware/vcloud-director/data/transfer (NFS share) - not mandatory for single cell installation, but all bloggers recommended it.

[root@vcd5101 ~]# vi /etc/fstab
192.168.X.X:/mnt/vol1-nfs /opt/vmware/vcloud-director/data/transfer nfs rsize=8192,wsize=8192,intr 0 0

[root@vcd5101 ~]# mount -a -t nfs

Now the installation can continue by running  /opt/vmware/vcloud-director/bin/configure. Choose the IP addres for HTTP, Console and enter path to certificate store. Add Syslog server IP (I am using rsyslog instance on vCD Cell).

Enter information for DB connectivity

 

After DB configuration is finalized, start services

Configure Sysprep

Create sysprep packages structure for Windows Server 2000, 2003 and Windows XP transfer sysprep files in it.
[root@vcd5101 ~]# mkdir vcloud-sysprep
[root@vcd5101 ~]# cd vcloud-sysprep
[root@vcd5101 vcloud-sysprep]# mkdir win2000 win2k3 win2k3_64 winxp winxp_64

After sysprep files have been transfered in the strucutre for each guest OS run the following command

[root@vcd5101 ~]# /opt/vmware/vcloud-director/deploymentPackageCreator/createSysprepPackage.sh /root/vcloud-sysprep/

Restart vcd service
[root@vcd5101 ~]# service vmware-vcd restart

Setup vShield Manager

Open VM console and login to vShield manager using admin/default. execute enable and enter default as password. Run setup command and configure networking. Login on HTTPS to the IP address configured previously and connect vShield Manger to vCenter Server. Finish the configuration by setting DNS, NTP and syslog server information.

Login to vShield Manager first configuration wizard and start configuration of vCloud Director cell.

Installing vCloud Director on CentOS and MS SQL Express - part 2

This is part 2 of a 3 part post that presents installation of vCloud Director 5.1 on CentOS 6.3 and MySQL Server 2012 Express

• part 1 presents Configuration of MS SQL 2012 Express Database for vCloud Director installation
• part 2 presents Configuration of CentOS 6.3 for vCloud Director
• part 3 presents Installation of vCloud Director 5.1

Configuration of CentOS 6.3 for vCloud Director

The media kit used for this installation is Cent OS 6.3 64 bit minimal release (CentOS-6.3-x86_64-minimal.iso). My first vCD install was on Cent OS Live CD release, on which I spent too much time to deactivate Network Manager, configure a simple IP alias, change the init level and so on. That`s why this one is Cent OS minimal.

Before starting any configuration check that you have access to a local/remote Cent OS repository and that you have downloaded Java Runtime Environment 32 bit minimal 1.6 update 10. It is a 32 bit JRE, as it is the only version supported by VMware. I have used version 1.6 update 38 ( jre-6u38-linux-i586-rpm.bin)downloaded from Oracle`s site.

Create the VM for CentOS: 1 vCPU, 2 GB RAM (VMware recommended size), 10 GB HDD thin provisioned, 1 Gigabit interface. vCloud Director requires minimum 2 IP addresses - one for portal and one for remote console. However, the addresses can be configured on the same interface in the same subnet (alias) - this is my case. If your network setup is different, then configure 2 interfaces.

Next, open the console of the VM, power on the VM, connect the cdrom to CentOS iso and start installing the OS. During the install modify the default partitioning in the following way: reduce lv_swap to 1024 GB and increase lv_root to maximum (almost 9GB). For the rest of the install, follow defaults.

After the system has been installed, it is time to start the preparation for vCD installation. First thing first... configure the network interfaces and DNS  (we need network connectivity in order to install other packages such as perl):

• configure eht0 and eth0:0 interfaces

[root@vcd5101 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"

BOOTPROTO="static"

NM_CONTROLLED="no"

ONBOOT="yes"

TYPE="Ethernet"

IPADDR="192.168.X.X"

NETMASK="255.255.255.0"

[root@vcd5101 ~]# cp -p /etc/sysconfig/network-scripts/ifcfg-

eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:0

[root@vcd5101 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0:0

DEVICE="eth0:0"

BOOTPROTO="static"

NM_CONTROLLED="no"

ONBOOT="yes"

TYPE="Ethernet"

IPADDR="192.168.X.X"

NETMASK="255.255.255.0"

• configure default gateway and restart the network service

[root@vcd5101 ~]# vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=vcd5101
GATEWAY=192.168.X.X

[root@vcd5101 ~]# service network restart

• configure DNS (my lab domain is cr.vmlab)

[root@vcd5101 ~]# vi /etc/resolv.conf

nameserver 192.168.X.X

domain cr.vmlab

[root@vcd5101 ~]# vi /etc/hosts

192.168.X.X vcd5101 vcd5101.cr.vmlab

Test connectivity to both IP addresses, DNS servers and gateway. Next we need to prepare the system for VMware tools installation. Being a minimal Cent OS we have to install perl:

[root@vcd5101 ~]# yum install perl

Perl is needed for our next step, VMware tools installation. In vSphere client choose Install/upgrade tools, open the console, mount the cdrom and install the tools:

[root@vcd5101 ~]# mount /dev/cdrom /media/[root@vcd5101 ~]# tar -zxvf /media/VMwareTools-9.0.0-782409.tar.gz
[root@vcd5101 ~]# ./vmware-tools-distrib/vmware-install.pl

During the configuration, chose default values. At the end, unmount the cdrom:

[root@vcd5101 ~]# umount /media/

Since the version used is minimal, there are some dependencies to be fulfilled.  The list of packages can be found in the official VMware documentation - I got mine from vCloud Director course manual. Run the following command, while -y will take care of the long list of dependencies: 

[root@vcd5101 ~]# yum install -y alsa-lib libICE libSM libX11 libXau libXext libXi libXt libXtst redhat-lsb

Side thought - while deploying on Cent OS Live CD installation, the only missing package is redhat-lsb.

The last package needed is JRE. Transfer JRE rpm to the system and install it:

[root@vcd5101 ~]# yum install ld-linux.so.2

[root@vcd5101 ~]# chmod u+x jre-6u38-linux-i586-rpm.bin

[root@vcd5101 ~]#./jre-6u38-linux-i586-rpm.bin

Running the bin will extract the rpm and also install jre. When installation is finished with the message "Done" it is time to start vCloud Director installation - part 3.

UPDATE 11.01.2012 - Iptables
By default, CentOS comes with iptables enabled. It is a good practice to keep the firewall on. I have configured the following ports (based on VMware documentation). However, it is possible to need new rules and the post will be updated accordingly.

[root@vcd5101 ~]# vi /etc/sysconfig/iptables

# vCloud Director Ports

# vCloud HTTPS

-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

# NFS

-A INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT

-A INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 920 -j ACCEPT

-A INPUT -m state --state NEW -m udp -p udp --dport 920 -j ACCEPT

#ActiveMQ

-A INPUT -m state --state NEW -m tcp -p tcp --dport 61611 -j ACCEPT

-A INPUT -m state --state NEW -m tcp -p tcp --dport 61616 -j ACCEPT

#Syslog

-A INPUT -m state --state NEW -m udp -p udp --dport 514 -j ACCEPT

[root@vcd5101 ~]# service iptables restart

Installing vCloud Director on CentOS and MS SQL Express - part 1

Before it all starts

In the past 3 months I have been involved in projects using vCloud Director. The necessity to have a test environment appeared naturally. So I started working in my home lab on deploying vCloud Director. I had the help of some other blogs (about which you will hear in the post below) but I have also done it different by using CentOS 6.3 and MS SQL 2012 Express (both not supported by VMware).

The following post presents installation of vCloud Director 5.1 on CentOS 6.3 and MS SQL 2012 Express and will have 3 parts:

• part 1 presents Configuration of MS SQL 2012 Express Database for vCloud Director installation
• part 2 presents Configuration of CentOS 6.3 for vCloud Director
• part 3 presents Installation of vCloud Director 5.1

Before starting anything make a little IP planning and check that you have a local DNS server and make sure that all infrastructure can be resolved properly (hosts, vcenter server, databases, vcloud cells and so on). I am using an AD (since I`ll  be testing LDAP integration ) integrated with MS DNS server. Other prerequisites: do not forget to deploy the vShield Manager appliance - each vCenter Server needs to have a vShield Manager. We will talk a bit later about basic configuration of vShield Manager.

 

Configuration of MS SQL 2012 Express Database for vCloud Director installation

First create the VM: 1 vCPU, 3 GB RAM (2GB recommended by MS), 25GB HDD thin provisioned (thin provisioning on SSD works great). Install Windows Server 2008  and VMware Tools. Configure the server (IP, hostname), if AD exists, join the server to the domain.

Next, download MS SQL 2012 Express from Microsoft site, the version that includes management studio (SQLEXPRWT_x64_ENU). Installing the DB is pretty straight forward - make sure to choose mixed mode authentication and configure sa user password. If you miss this step, it can be done after the install ( SQL Server Management Studio - Server properties - Security). During the configuration choose an instance name (VCDDB for example).

After SQL server is installed, open SQL Server Management Studio connect to VCDDB instance with sa user and add a user for vcloud director - vcddbadmin (Security - Logins - New)

Now it is time to create the DB: Database - New - vcddb01 (you can give it any name). Change the owner to user vcddbadmin.

Sizing the DB: VMware documentation offers the following parameters: data file (mdf) size = 100MB, filegrowth= 10% and for log file (ldf) size = 1MB, filegrowth= 10%. In lab environment these should suffice.

A very interesting post about vCloud director database can be found on Erik Bussink blog. Based on that post , I have decided to make the following configuration on my DB:

• data file size = 1024MB, growth = 512 MB, limit = 3072 MB
• log file size = 128 , growth = 128 MB, limit = 1024MB 

The actual limits are determined by both SSD space and VM size in my lab environment.

On Options page from database properties the proper collation sequence will be configured to Latin1_General_CS_AS. Default values for recovery model and compatibility level will be left unchanged ( Simple, SQL Server 2012 respectively)

The last action on the database is to prepare the DB. Again, I have used the information from Erik Bussink. Open query editor and execute the script below:

USE [vcddb01]
GO
ALTER DATABASE [vcddb01] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [vcddb01] SET ALLOW_SNAPSHOT_ISOLATION ON;
EXEC sp_addextendedproperty @name = N'ALLOW_SNAPSHOT_ISOLATION', @value = 'ON';
ALTER DATABASE [vcddb01] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;
EXEC sp_addextendedproperty @name = N'READ_COMMITTED_SNAPSHOT', @value = 'ON';
ALTER DATABASE [vcddb01] SET MULTI_USER;
GO

Form the original script I have removed the first line ALTER DATABASE [vcddb01] SET RECOVERY SIMPLE since the DB has default recovery model set as simple. Check that the extended properties were added: database Properties - Extended Properties.

To finish the installation, a couple of more things have to be done. First, configure MSSQL server to listen on TCP/IP. Using Sql Server Configuration Manager go to SQL Network Configuration and enable TCP/IP. In Properties tab chose the IP address and set the following parameters:Active YES,  Enabled YES, TCP Port 1433,  TCP Dynamic Port 0.

Then, restart the service and check that the server is listening on port 1433 (netstat -van).

Finally, configure Windows Firewall to allow incoming connections on TCP 143 and test that communication with the server on TCP 1433 is ok from another VM using the command telnet ip_addr_db 1433.