Monday, May 19, 2014

Upgrade VMWare from 5.0U1 to 5.1U2

We recently upgraded our vCenter and ESXi Hosts to 5.1 U2.

This pretty much consisted of:


  1. Creating an SSO database including usernames and passwords
  2. Upgrading vCenter
  3. Upgrading the ESXi Hosts

Creating an SSO Database including usernames and passwords

This was probably the easiest part if the upgrade once I realized the SQL scripts were already available on the CD. Since I am using SQL they were located here: 

D:\Single Sign On\DBScripts\SSOServer\schema\mssql

*Replace D:\ with your CD ROM Drive.*

The two files you need are:
  1. rsaIMSLiteMSSQLSetupTablespaces
  2. rsaIMSLiteMSSQLSetupUsers

All you need to do is open SQL Studio Management and open a new query. Drag and drop rsaIMSLiteMSSQLSetupTablespaces to the query and it will auto fill. Execute the query and it will create the SSO database (although it is really called RSA).

Do the same for the rsaIMSLiteMSSQLSetupUsers. Remember you will need to change the default passwords for the users. Remember the password as you will need those later.

Side note: Make sure you have a SQL version that is supported. I am using 2005 and had to update to the latest Service Pack. I have my SQL server on a separate server than my vCenter.


Upgrading vCenter

I did the simple install for upgrading vCenter. This installed everything, the SSO service, inventory service and vCenter itself. This was pretty straight forward. Since I had my SQL server on another server I had to supply the server name, usernames and passwords when it got to the point of installing SSO and upgrading vCenter database

Upgrading the ESXi Hosts

Even though this probably should have been the easiest part, it proved to be the most challenging. I'll explain why at the end. But first let me show you how to upgrade using the offline bundle:

First you will need to download the ESXi offline bundle for your version. This is usually a few hundred meg file.

Once you have the file, upload it to your local ESXi Host datastore. Once you do this, you will need to run:

esxcli software sources profile list -d /vmfs/volumes/4d810055-10da4bf6-16f3-f04da23d2982/5.1/VMware-ESXi-5.1.0-799733-depot.zip

This will list the files inside the depot zip file that are available to use for an update.It will look something like this:

 ESXi-5.1.0-799733-no-tools
 ESXi-5.1.0-799733s-no-tools
 ESXi-5.1.0-799733-standard
 ESXi-5.1.0-799733s-standard

You will need ESXi-5.1.0-20130402001-standard.

Side Note: you will notice i had to use 4d810055-10da4bf6-16f3-f04da23d2982 variation instead of the name datastore. to get this name all i had to do was change directory to the datastore. ie, cd /vmfs/volumes/datastore. when i hit enter to change to that directory it changed the folder datastore to the 4d810055-10da4bf6-16f3-f04da23d2982 variation. You may not have to but I did. For some reason it didn't like the folder name datastore when I ran the next command. Remember, that the filename will be different for you as well. 

Once you have the file name you will need to run:

esxcli software profile update -d /vmfs/volumes/4d810055-10da4bf6-16f3-f04da23d2982/5.1/VMware-ESXi-5.1.0-799733-depot.zip -p ESXi-5.1.0-799733-standard

Once you hit enter it will update the ESXi Host. It should take less than a minute.You will need to reboot the host once the update is done.

Seems pretty easy. What happened in my case was after a day the ESXi hosts started disconnecting from the vCenter and I couldn't install/update VMWare Tools on the VM's. I kept getting SCSILinuxAbortCommands for driver LSI Logic SAS based MegaRAID errors. After some searching I found out its because my Perc H700 RAID Controller Card needed a firmware update from 12.10.1 to something higher than 12.10.3.

I hope this helps someone out if they are updating vCenter and ESXi.



Wednesday, April 16, 2014

Tor and Tortilla

I was finally able to get around and test Tortilla. Tortilla allows you to send all traffic through TOR when using a virtual machine.No need for additional software or VPN's

Download the Tortilla software HERE

You will need TOR Expert Bundle. Download that HERE

When installing the TOR expert bundle i had to install it as an administrator. Right click the EXE and choose Run As Administrator.

Once you have TOR and Tortilla installed, run TOR and once it loads up, run Tortilla. The first time Tortilla runs it will take a couple minutes to install the adapter.

Once both pieces of software are running you will need to add or adjust your VMNET on your virtual machines. Those of you who have VMWare Player will need to somehow extract the vmnetcfg.exe and library file from VMWare workstation. Below are some helpful links:

Link 1
Link 2

Once you have the ability to edit the network configuration you can modify and exisitng VMNET or create a new VMNET and bridge the Tortilla adapter to it. Please note, I was only able to modify the VMNET0 since I did not have the option to select the Tortilla adapter when i created a new VMNET to bridge to. I am not sure why.



Once all of this is setup (Installing Tor expert bundle, Tortilla and modifying a VMNET to bridge to the Tortilla adapter) you should be able to select Custom in your VM network settings and select the VMNET that is bridged to the Tortilla Adapter. In my case this is VMNET0:



At this point in time power on your VM and all traffic will be sent to Tor using the Tortilla adapter.


Tuesday, April 1, 2014

Lexis Nexis Bridger Insight XG SmartClient MSI

We use a program from Lexis Nexis called Bridger Insight. Normally this software is a simple "ClickOnce" type of program that will update itself. However, since we are in a Terminal Services environment with roaming profiles we have to use the MSI version.

When using the MSI version Lexis Nexis pretty much wipes their hands of any technical support saying you assume any risks when using this product. That's all good and dandy as I understand everybody's environment is different and trying to troubleshoot something can take a long time.

Over the weekend they had an update. Normally all that needs to be done is to run the new MSI. The MSI will usually uninstall the old version and then install the new version. This time it was throwing out "ERROR 1714. Call Tech support." when trying to remove the old version. I even tried uninstalling it using Add//Remove Programs.

Tech support wasn't much help, suggestion something I already did and then of course reiterating that I assume all responsibility when I went into the agreement for the MSI version...blah blah blah.

After some digging and using a 3rd party uninstaller I found 2 registry entries that are not removed when uninstalling the program:

HKEY_CURRENT_USER\Software\Microsoft\Installer\Features\ODBA2711A9D468F4A9E21433FF2120B0

HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\ODBA2711A9D468F4A9E21433FF2120B0

HKEY_CURRENT_USER will be whatever user you used to install the program. In my case, Administator.

Once you delete that folder under Features and Products you can install the new MSI.

This now brings me to another subject (I'll be quick, I promise): Why don't software vendors support their products or at least try and make the install/uninstall smooth? It seems to me that no one wants to troubleshoot anything anymore. I competently understand that its getting harder to troubleshoot with so many different pieces nowadays but that's part of the job.

Tuesday, March 25, 2014

New Private Search Engine

I came across a new seach engine called Disconnect. It's a plugin that allows you to use several search engines without giving them your personal information.

ESXi 5.0, LUNS, SANs and Mulitsessions

We recently installed and configured new Overland S5000 SANs for our virtual environment. In doing so we noticed tons of errors once we added the SAN IPs to our iSCSI Software Adapter. The vmkernel.log was saying that the SANs were offline and then online and then offline and then online constantly.

The issue turned out to be that our new SAN doesn't support Multisessions. It doesn't like seeing the same subnet connecting to the SAN network cards and controllers.

What we ended up doing was putting each NIC on the two controllers in their own VLAN:

Controller 0, NIC 0 - VLAN 2
Controller 0, NIC 1 - VLAN 3
Controller 1, NIC 0 - VLAN 4
Controller 2, NIC 1 - VLAN 5

With this setup you will need 4 NICS on each host, one for each VLAN to ensure redundancy and multipathing. Each ESXi NIC would go to one VLAN.




Sunday, March 16, 2014

Intstalling Python easy_install

I'm posting this is case anyone gets confusing search results like I did. If you want to install easy_install type this at a command prompt:

sudo apt-get install python-setuptools

If for some reason you get an error you may need to do:

sudo apt-get update
sudo apt-get upgrade

Once it's installed you can use easy_install like this:

sudo easy_install web.py

or whatever program you need to install.


Removing LUNS and Datastores on ESXi Hosts 5.0 and above

We had a need to remove the LUNS from one of our SANS. If you go to your iSCSI Software Adapter and remove the SAN IP's from the properties (Dynamic and Static tabs), you will have issues when the ESXi host rescans the HBA's and VMFS stores. The reason is because you didn't remove the datastores from the host. The proper order to do this is:


  1. Unmount the datastore from each host
  2. Detach the LUNS from each host
  3. Remove the iSCSI IP's of the SAN from your iSCSI Software Adapter (or appropriate adapter)

Unmount The Datastore From Each Host
To do this you will need to go to the Datastore view and find the datastores attached to the LUNS. Right click and select unmount. A screen will come up letting you know if you can unmount the datastore. You should remove all VM's and it can't be part of a datastore cluster.

When you unmount the datastores it will ask you which hosts to remove them from. This saves time from having to go to each host and unmount.


Detach The LUNS From Each Host
To do this you will need to go to your configuration tab and then select Storage adapters. Select your storage adapter (mine is the iSCSI software adapter).

When you select your storage adapter you will see all of the LUNS on the bottom. Find the LUNS that you want to remove and right click and then select detach. Make sure you are selecting the right ones.

I had to to this for each host and each LUN. It took me a few minutes. I don't see an option to do this for all the hosts at the same time like we did with the unmounting of the datastore.


Remove The iSCSI IP's of the SAN From Your iSCSI Software Adapter (Or Appropriate Adapter)
Still inside your Configuration tab and Storage Adapter, right click your iSCSI Software Adapter and select properties. Go to Static entried and remove the IP's one at a time of your SAN. Do the exact same for the Dynamic tab. Once you do that click CLOSE and have it rescan.

The reason you want to go through all of this is because the datastores that are still mounted on those LUNS will cause issues if you just remove the IP's from the storage adapter. When it rescans it will take forever and could cause it to lose connection to the vCenter. Since the datastores were not unmounted the ESXi host doesnt know what to do and keeps trying to access it.

If you don't have any datastores on those LUNS, then you should be able to remove the IP's from the storage adapter and rescan.

Thursday, February 27, 2014

Importing Certificates with Watchguard

I came upon an interesting problem while trying to set up SSL VPN on a Watchguard XTM 5 series firewall. Every time I would import the certificate I received from my CA, the firewall would simply say Error in importing certificate.

What I ended up doing was grabbing the root certificate and Intermediate certificate from the CA's website and importing it into the firewall first and then importing my SSL cert.


User unable to login to RDP Farm after you re-enable them?

We had a strange issue. We had a user leave and since we knew when she was leaving i set the account to expire at a certain date. A couple d...