Manually replicate Desktone Tenant Appliances

DB replication re init process
The following steps are to be performed on both tenant appliances in the HA set.
Also as a safety measure please verify time sync first and correct it if needed.

1. Stop the dtService service on both tenant appliances: service dtService stop

2.  Stop the slon daemons on both tenant appliances: killall slon

3.  Open a psql session to the fdb database on each tenant node: psql -U admin fdb

4.  Purge the _slony schema: drop schema _slony cascade;

5.  Exit from the psql session: \q

6.  Open a psql session to the edb database on each tenant node: psql -U admin edb

7.  Purge the _slony schema: drop schema _slony cascade;

8.  Exit from the psql session: \q

9.  Reinitialize the master DB by connecting to the JMX console of an SP appliance with a web browser:
https://<sp appliance address>/dt-console
Credentials can be determined by logging into service center and selecting ‘general’

10.  Click on the UpgradeManager MBean (under com.desktone)

11.  Invoke the initSlonyForOrg() method to the FDB, it takes 2 params as specified below (will return “true” when successful)

P1.  orgId ( The org ID is the number associated to the tenant and can be viewed from Service Center tenant page)
P2  * leave blank
P3.  “fabric” (without the quotes)

12.  Invoke the initSlonyForOrg() method to the EDB, it takes 3 params as specified below (will return “true” when successful)

P1.  orgId ( The org ID is the number associated to the tenant and can be viewed from Service Center tenant page)
P2  DC ID (run following command from tenant Desktone appliance:  cat /usr/local/desktone/.datacenter_id)
P3.  “element” (without the quotes)

13. Reboot both tenant Desktone appliances: shutdown -r now

After restart verify that a master DB is selected and that it is not stating both are master. In the deskone log you should find a message similar to the following.

2012-06-27 13:49:32,030 INFO  [com.desktone.elementmgr.datasource.EdbDatasourceOptimizer]-[timerFactory] Attempting to determine slony master datasource.
2012-06-27 13:49:32,030 INFO  [com.desktone.server.datasource.DataSourceRefresh]-[timerFactory] Datasource for edb at 169.254.6.107 already exists
2012-06-27 13:49:32,062 INFO  [com.desktone.server.datasource.DataSourceRefresh]-[timerFactory] Datasource for edb at 169.254.6.106 already exists
2012-06-27 13:49:32,091 INFO  [com.desktone.elementmgr.datasource.EdbDatasourceOptimizer]-[timerFactory] No changes to the master datasource will be made, the most optimal ‘169.254.6.107’ is already in use.
2012-06-27 13:49:32,091 INFO  [com.desktone.elementmgr.datasource.EdbDatasourceOptimizer]-[timerFactory] saveHostsToPropFile: masterHost = 169.254.6.107 allHosts = [169.254.6.107, 169.254.6.106]

Migrate static desktops to different Enterprise Manager in Horizon DaaS 6.1

I recently had to do a clean upgrade of our VMware Horizon Daas environment from 6.0 to 6.1.  I chose to go with the clean install at this point because when we first installed the product back when it was Desktone, there were a lot of tweaks done to the database by Dektone engineers to get it to work the way we wanted it to. Every time I did an upgrade from Desktone and eventually VMware it broke our production systems due to the tweaks they had done.  I was tired of going through that so now I have a nice clean install ready to put into production. I found out with a quick e-mail how to easily get the static desktops that were in the old Emterprise manager’s of our tenants into the new EM’s.

1. Assign DaaSold hosts and clusters to DaaSnew Desktop Manager
2. vmotion desktops over to DaaSnew hosts / clusters
3. Remove/unassign DaaSold hosts and clusters

Note: The desktops will be in the Imported Desktops pool they will just need to be moved to the pool of your choice in the new EM.

It was that easy and it worked!! Thanks Luke at VMware for that quick solution.

Install CA Signed SSL Certificate on ESXi 5.5 Host

While I was upgrading our vSphere to 5.5 I was put to the task of going the extra step to replace the self generated SSL certificates on our ESXi hosts with certificates  generated by our internal CA.  This was going to help us pass various security audit requirements so I wanted to put it into the upgrade plan. I found various posts about it and this VMware KB2015499. I followed the KB article and when I tried to restart the services the host would not connect back to vCenter.  After a little more research I found that the KB was missing a very important step that converted the certificate issued by our CA into a x509 certificate.  Here are the steps that I used to finally get the certificates to work.  Some of these steps are taken directly from the VMware KB.

You must have OpenSSL installed on your computer to complete these steps.

Launch a command prompt and navigate into the OpenSSL directory.  Mine is C:\OpenSSL\bin>

Execute the command:
C:\OpenSSL\bin>openssl genrsa 2048 > rui.key

Answer all of the prompts and at the Common Name prompt make sure you enter the fqdn of the host you are configuring the certificate request for. (hostname.company.com) Note: You can change the 2048 to whatever size certificate you want, I wanted 2048 bit.

Execute the command:
C:\OpenSSL\bin>openssl req -new -key rui.key > rui.csr

Now that you have your certificate request you will need to log into your Microsoft CA server and get the certificate.
1.    Log in to the Microsoft CA certificate authority web interface. By default, it is http://<servername>/CertSrv/
2.    Click Request a certificate.
3.    Click advanced certificate request.
4.    Click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
5.    Open the certificate request in a plain text editor. This is the rui.csr file.
6.    Copy from —–BEGIN CERTIFICATE REQUEST—– to —–END CERTIFICATE REQUEST—– into the Saved Request box.
7.    Click Web Server when selecting the Certificate Template.
8.    Click Submit to submit the request.
9.    Click Base 64 encoded on the Certificate issued screen.
10.    Click Download Certificate.

Now for the important part that the KB is missing.

Copy the certificate file that you downloaded, to your openssl directory that you have been working in. The file is usually certnew.cer and run the following command.
C:\OpenSSL\bin>openssl x509 -in certnew.cer -out rui.crt

Now the final step is to copy the certificate and the key to the ESXi host.  I prefer using WinSCP but you can use any method you like to get the files to /etc/vmware/ssl.
1.    Log in to vCenter Server
2.    Put the host into Maintenance Mode.
3.    Enable SSH on the host from the host configuration tab.
4.    Log in to the host with WinSCP and navigate to the /etc/vmware/ssl.
5.    Rename the existing rui.crt and rui.key to .old
6.    Copy the newly created rui.crt and rui.key to the directory.
7.    Log onto the host with Putty and restart the management agents. (services.sh restart)
8.    Reconnect the host in vCenter. You will need to use the root password and accept the new certificate.
9.    Exit the host from Maintenance Mode.

Steps to resolve HA firewall issues in vCenter 2.5

HA

If after enabling HA on a vCenter cluster you get the above configuration error, check in event log. if error is “Could not enable firewall ruleset:vim.fault.NotFound”

a.Disconnect host from vCenter
b. Log into host with PuTTy
c. Run the command esxcfg-firewall -e aam
d. service mgmt-vmware restart
e. Wait about 5 minutes
f. Connect host in vCenter
g. Open the configuration tab for the host in the VIC and go to “Licensed Features”
h. Edit License Source
i. Configure license server on host to Your license server
j. Right click on the host in the VIC and select “Reconfigure for VMware HA”

Changing the MAC Address on a VM to a Non VMware MAC Address

I recently had to P2V a server where the application that was running on it was bound to the MAC address of the physical server NIC. This was not going to work with the VMware assigned MAC address 00:50:56:ae:46:27. I had to set the NIC on the VM to the same as it was on the physical server.   Since I am still in the dark ages and working with VIM 3.5 this was not going to work. After finding a couple of old posts online http://jasonnash.com/2008/08/30/disabling-mac-address-checking-in-vmware/

http://www.networknet.nl/apps/wp/archives/787

 I was able to get the VM to use the MAC address from the physical server and have the VM power up. Without the error

 Mac1

Here is what I did

First I found that changing the MAC in the vSphere Client would not work.  I was working in ESX 3.5 and it does not allow you to change the MAC to anything but VMware generated.  This is not the case in vSphere 5 where you are able to change the MAC within the vSphere Client.

 Mac2

So I opened up the .vmx file and made a couple of changes.

I changed:

ethernet0.addressType = “vmx”

ethernet0.generatedAddress = “xx:xx:xx:xx:xx”

 

To:

ethernet0.addressType = “static”

ethernet0. Address = “xx:xx:xx:xx:xx”

Then I added:

ethernet0.checkMACAddress = “FALSE”

 

After making these changes and saving the .vmx file back to the host, the VM powered on successfully with the correct MAC address.

 

Another thing that I noticed was that after these changes were made I was no longer able to make any edits to the NIC via the client.  It would give the “MAC address is not valid” error.  This was ok with me, I will just make any future changes to the NIC such as port group changes via the .vmx file.

Storage vMotion (SVM) in vCenter 2.5

Storage vMotion in vCenter 2.5

Storage vMotion was introduced in VMware Virtual Infrastructure 3.5
Storage VMotion (SVM) enables live migration of virtual machine disks from one datastore to another with no disruption or downtime. Just as VMware VMotion allows IT administrators to minimize service disruption due to planned server downtime, Storage VMotion allows them to minimize disruption by reducing the planned storage downtime previously required for rebalancing or retiring storage arrays. Storage VMotion simplifies array migration and upgrade tasks, and reduces I/O bottlenecks by moving virtual machines while the VM remains up and running. It provides a hot migration of the storage location on which the vmhome resides.

SVM can only be done via the Remote Command Line Interface (RCLI), vSphere Command-Line Interface (vCLI) or PowerCLI.  For this guide I will only illustrate the PowerCLI method.

The assumption will be that you already have PowerCLI installed.

Start a PowerCLI session.

PowerCLI_1

 

Connect to the vCenter you are going to do the SVM on.

[vSphere PowerCLI] C:\> Connect-VIServer <vCenter_server_name>

When prompted log in to vCenter just as you would if you were using the VIClient.

Run the following command substituting the VM that you want to move and the datastore you want to move it to.

> Get-VM <VM_To_Move> | Move-VM -Datastore <Datastore_to_move_to>

 PowerCLI_3PowerCLI_2

You will see the progress bar in the PowerCLI window as well as the VIClient as noted above. 

If you add the parameter  –RunAsync at the end of the command, it will not wait for the progress to complete and will allow you to move on to another task immediately.

>  Get-VM <VM_To_Move> | Move-VM -Datastore <Datastore_to_move_to> -RunAsync
I am glad that this has been added to the GUI for all later releases of vSphere, but at my day job this is what I have to work with. 

 

 

 

My Home Lab N40L

I just recently got a good working home lab up and running to help me with study for the VCP5 and VCAP5 VMware certifications. I have found it extremely helpful with studying as well as testing some theories for the production environment at work since they will not give me a good lab to play with there.

So I started with a HP N40l Micro Server.  It shipped as HP ProLiant N40L MicroServer Server System AMD Turion II Neo N40L 1.5GHz 2-Core 2GB (1 x 2GB) 1 x 250GB LFF SATA 658553-001.  I knew that the 2gb memory was  not going to be enough so I followed this great post by Chris Wahl and changed the memory to 16gb. The server has 2 CPU and one onboard NIC.  I am sure that I will be needing to add another host soon.

N40L_Summary

I installed ESXi 5.1 to get started then installed Autolab 1.0.  I am having trouble installing ver 1.1 so I will leave that for another post.

As I started working with the lab I found that storage was keeping me from doing some of the things that I wanted to do so I got a 1TB Western Digital Green HD to add to the server.  Now I am finding that I have the storage to do what I wanted to do but the IO is horrible! So the next step is to start rounding up some stuff to build a cheap NAS.  Hmmm another post.  The more I work with my new lab the more things I start thinking about to post.

Till next time.