This series of articles present our findings and processes as we performed them. These processes may not be optimal nor preferred in other installations, but they represent the best case for our particular assignment. As such, we certainly welcome feedback.

Part I – Building the Test Environment

Before performing the upgrade we wanted to ensure that our processes would work. Additionally, we have a deference for knowing what roadblocks we might run into ahead of time. When dealing with databases, most times I am going to bet that people or system will be impacted by the DB services being unavailable. Therefore, time is important. Testing before hand can shrink the outage windows and help keep customers happier.

As such, we decided to replicate the key pieces of the infrastructure into a virtual environment. We did this using the VMWare ESXi platform which we are familiar with from our own server infrastructure environment. If you are unfamiliar with ESXi, it is a free version of the VMWare virtual infrastructure product line. You do have to register with the VMWare.com website to download and obtain a license key, but you probably want to be able to review the knowledge base and community forums anyhow. For an SMB like us, it is a great virtualization platform.

Testing Environment ESXi Server Setup

First, we needed the VMWare ESXi server. So we downloaded the latest ESXi bootable ISO from VMWare.com, burned the disc and booted our test server up. We won’t go into all the setup screens, but you can find ESXi installation instructions in a variety of places including this one. Essentially we just took the default installation, rebooted and then configured the management interface with a static IP, mask and gateway. Finally we setup a root password.

Converting or Moving Production to Test

Now whether your production servers are already virtual machines on VMWare or are real, physical servers you are going to need to create an exact copy of them for your test environment. VMWare has a great little, free, tool that allows you to do this. Although they have bigger, better (not free) tools to do this, our needs are such that the free tools work. The VMWare Converter tool is the key. Download it from VMWare.com. Then, we simply install the converter application on the servers that we need to replicate to test. [Note: Just found out that version 4.0 of VMWare converter was released on 2/12/2009. We were using version 3.0]

The conversion process takes the current server and converts it to a compatible VM (virtual machine) on the test server. This include all O/S, network, disk, CPU and memory settings. One note, you’ll want to ensure you have enough disk space on the test ESXi server to accommodate all the disks you are converting for all the VM’s.

[Note: We learned the hard way, having to rebuild the array on the test ESXi server from RAID 5 to RAID 0 in order to get the last bit of disk space we needed. Lesson:  sum all your disk space needs for all the servers you will be converting, ahead of time.]

The process is quite simple but may take numerous hours depending on the data needing to be migrated. So let’s walk through one example of converting one of our production machines in the following video.

1) This is the VMWare converter. Start the converter and choose to start a new conversion.

2) This is the new conversion project wizard splash screen. Click Next.

3) We will be stepping through setting up the source for the conversion. Click Next.

4) Source type will be physical machine regardless if source is physical or another VMWare VM.

5) Choose "local machine" and the converter will convert the current machine using the current users credentials.

6) Choose the disks to be converted. Be sure you include the O/S drive and any data drives you might need.

7) We will define the destination VMWare ESXi server.

8) Our destination type will be VMWare Infrastructure Virtual Machine since we want to convert his server to a VM that will run on VMWare ESXi.

9) This is the destination VMWare ESXi server name or IP and the VMWare login credentials.

10) Type the name you wish to give the new VM when it is converted. This is not the O/S name but the VM name that shows up in the VM inventory.

11) The datastore where you want the converted VM files to be stored on the VMWare ESXi server.

12) The number of NICs that will be created in the destination VM.

13) Place checkmarks on these two options to ignore hibernation and page files and install the VMare tools on the destination VM.

14) Do you want to VM to automatically power on after the conversion is complete? Click finish to start the conversion.

When the conversion completes, pat yourself on the back as you just converted your first server. Now just repeat this process for each of the servers you need to complete your test environment.

Just a quick observation and statement of the obvious. The length of time that a conversion takes is primarily dependent upon two factors, network and disk space. On the network side, I would highly recommend using Gigabit networks for converting larger servers. We found a many fold reduction in conversion time simply by moving from 100 megabit to Gigabit networks. Additionally, the amount of used disk space on the source server will also play a role in the conversion time. The more disk space in use on the source server that is needing to be converted, the more time the conversion will take.

Keep in mind I said “used” space. Unusued space on the disks being converted seems to play very little into the conversion times. As such, clean out your temp files and such before doing a conversion. It might save you some time when converting.

Configuring the Isolated Test Network

Doing this allows us to connect to the management network on the ESXi. Once installed, point your browser to the IP address of the ESXi server via https and you can download the VMWare Virtual Infrastructure client. (https://192.168.1.134 or whatever IP you gave your ESXi server). This client application currently only runs on Windows, sorry Linux folks. This is what you will use to manage your virtual clients.

In our case,we wanted the virtual servers to be able to connect to themselves but not the “real” LAN so as not to cause duplicate IP and Active Directory issues. To do this, we created an isolated virtual network. From the client application, we created a second virtual switch. When we created the virtual switch, we did not link a physical network card to the virtual switch definition. This essential makes a virtual switch that can talk only to other devices on the same virtual switch.This is a plus for testing of an isolated network environment where you do not want the test servers to talk to your LAN.  On the downside, your servers on this new virtual switch can’t get to the Internet either. (at least not without some other fancy networking tricks).

Here’s some screenshots of the process.

1) Create new virtual switch.

2) Select the Create a Virtual Switch option and click Next.

3) Give your new network a name and click Next.

Again, congratulations. You just finished creating you own host only virtual network switch for isolated server testing. Now you need to move your VM’s to use this new network. You’ll need to edit each VM’s setting and change the network that the NIC connects to be your newly create host only network.

1) Edit the VM settings.

2) Change the network to your host only network you created above. Now Ok to save.

That’s the majority of it. Again, we used this setup to convert 5 of our production servers including SQL 2000, SQL 2005, Terminal Services, File Services and Domain Controller all to this isolated test environment. Then we made a snapshot of each converted server which allowed us to go back to the fresh conversion state as many times as we wanted.

From here, we embarked upon our SQL Server 2008 upgrade testing.

Blessings.

So, I was asked by my lovely spouse to move the home office to another room for a particular reason. Unfortunately, the new location did not have an existing outlet for the broadband internet line. Immediately my eyes widened and a grin broke across my face as I knew it was an opportunity to try something I had been wanting to for quite a while.

Rather than run wiring and such, let’s go wireless. Yes, a wireless bridge was going to be the ticket. As it happened, I already had two Linksys WRT54G wireless routers, so I was in business. After spending a bit of time on the DD-WRT website, I had the details I needed and downloaded the bits I needed.

DD-WRT is a free alternative firmware for many major brand wireless routers and access points. Now, yes this may void your warranty but if you’re like me, that limited warranty was out many moons ago. DD-WRT firmware provides for more features and functions to be available to you. You can make your wireless router or AP can then do tricks you never knew it could.

This video gives a good idea of how we did it.

How did we get this to work? Here is the process we used.

DD-WRT Installation Instructions on the wiki.

1. Download the proper firmware for our version of the WRT54G. Use the compatability matrix to determine the correct DD-WRT version for your device and device version.
2. Performed a full 30/30/30 hard reset of the router
3. Open your web browser and connect to the router at 192.168.1.1 and login with the default username/password.
4. You should be in the Web GUI of the router.
5. Click the “Administration” tab
6. Click the “Firmware Upgrade” sub-tab.
7. Click the “Browse” button and select the DD-WRT .bin file you downloaded and confirmed.
8. Click the “Upgrade” button.
9. The router will take a few minutes to upload the file and flash the firmware. During this time, the power light will flash.
10. A new page will open confirming that the upload was successful Now wait about 5 minutes before clicking “Continue”.
11. Lastly, do another hard reset on the unit.
12. If flashed successfully you will now be able to access the DD-WRT web interface at 192.168.1.1

Now, since we wanted to utilized a wireless bridge, we needed to repeat the above steps on the second router. After the firmware updates were complete, we individually tested each router, connected to our broadband service to ensure both were working properly.

Next we followed this post on the setup the wireless bridge.

One thing that was a problem initially was the lack of machines connected to the second router (bridged AP) getting IP addresses from DHCP. It wasn’t until we read completely and did a bit of searching that we found out that this is a known problem with DD-WRT v24. Some folks report that it worked fine in earlier releases, but it appears to be a bug currently.

This was a bit of a bummer, but easily worked around for our small setup. We just setup the desktop machines with static IP addresses outside of the DHCP scope of the primary router but on the same network subnet. The default gateway and DNS were setup to point at the primary router (192.168.1.1) as well.

Immediately we could browse the internet from the office desktop machine which was connected to the second (bridged) router. Success! Now of course, DD-WRT offers many other features that the standard Linksys firmware does not. We’ll leave that as an adventure for you until we report more on those specifics.

Blessings.

• 10 Useful RSS Tricks and Hacks for WordPress – Smashing magazine puts together a good list of WordPress tips to allow some useful RSS modifications. PHP snippets included.
• wpSEO – WordPress SEO optimization plugin. Interestingly this is a for purchase plugin.
• Top WordPress 2.7 Tips, Hacks, Plugins & Resources – A quick hit list for those new to WordPress 2.7
• WordPress Tutorial: Category Trick for WP 2.7 – Interesting idea for styling posts differently based upon categories. Could be used for site segmentation visually.
• Mastering Your WordPress 2.7 Theme & Admin Area – Good article that may just show you something you didn’t already know about managing WordPress 2.7

Blessings to you.