Convert VMware SQL Server Express to SQL Server

One of the things that I realized in having SQL Server Express installed with the vCenter server is that if the vCenter Server crashes (if it is a stand-alone physical server). You are stuck! You are trying like hell to get this server up. However, if you have a SQL Server 2008 Standard Edition Database server. Why NOT use it. Also, if you can convince your company, non-profit, or hospital to pony up on the SQL Server 2008 License. I would say go for it! Yes, you “can” install SQL Server 2008 Express on a server and have vCenter connect to this also. However, this tutorial is for an environment where you want a centralized SQL Server 2008 Database Server. This server will be the DB SVR for vCenter, VUM and whatever else you want to use it for.

Scenario is based on 2 Physical stand-alone Dell PowerEdge R310 Servers (DC/vCenter) and 5 Dell PowerEdge R710 Servers. Windows 2008 Server Datacenter Edition, VMware ESXi 4.1, vCenter Standard 4.1, and NetApp 3270.

40 VM’s consisting of 2K3, 2K8, 2K8R2, RHEL 5.5, SUSE11-4VMware, UBUNTU10.4 Templates, DHCP on VM, DC2, DC3, File Server Cluster (2 Clustered on iSCSI SAN drive), Print Server Cluster (2), AV, WSUS, SQLSRV2K8 DB SRV, PROXY RHEL Cluster (2), VUM, VDR, VSHIELD (5), vDistributed Switches for 1GB Ethernet Intel NICs, HA/DRS Clusters.

Here we go…Screenshots soon to come.

1. Make sure your ISO’s are on a share so that you can access them.  Use Virtual Clone Drive to kick off the ISOs. Virtual Clone Drive should be an ABSOLUTE MUST for your VMware Arsenal.

1. Stop all of the VMware vCenter Services (i.e. vCenter, VUM, etc).
—-> START >> Run >> services.msc (If it says vCenter stop it. Leave the VMware Tools alone).

2. Copy all of the VIM_VCDB.mdf Database Files to your SQL 2008 Server.
—->START >> Run >> \\SQLSRV2K8DB\c$\Program Files\Microsoft SQL Server\ and then hit
the enter key. You want to go to the “Data” Folder and drop the databases into this folder.

3. Login to your SQL Server. Launch SQL Server. Connect to the server and right-click on Databases and “attach” the database. (I created a database and imported the migrated DB to the new created DB. You may decide to use the attached DB, but I wouldn’t.)

4. Right-click on the database and Backup the Database with a Full Backup.

5. Open up ODBC (under Administrator Tools). Go to System DSN and Test Connectivity to the SQL Server Native Client. Make sure your DB is the default (I named mine VCENTER since you can’t jack this up and even Joe new guy will know not to touch this database.).  Make sure you can connect to the server because if you can’t guess what. vCenter won’t either.

6. Uninstall vCenter Server from the Server and just re-install it. Point the vCenter DB to the new SQL Server 2008 Server and make sure you DO NOT OVERWRITE THE DATABASE!!!

7. Launch vCenter and if it comes up. Your golden!

References:
http://www.vmware.com/files/pdf/vc_microsoft_sql_server.pdf
http://www.ntpro.nl/blog/archives/1423-How-to-migrate-the-vCenter-database-to-Microsoft-SQL-Server-2008.html
http://get-admin.com/blog/?p=646
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028601
http://www.sysadmintutorials.com/tutorials/vmware-vsphere-4/esx4/installing-vmware-view-4-composer/

The 4 Most Common Misconfigurations with NetApp Deduplication

Being a field engineer I work with customers from all industries. When I tell customers that the usual deduplication ratio I see on production VMware workloads is 60-70% I am often met with skepticism. “But my VM workload is different” is usually the response I get, followed by “I’ll believe it when I see it”. I do also get the occasional “Thats not what your competitor tells me I will see” I love those ones.

Consistently though when the customer does a proof of concept or simply buys our gear and begins their implementation this is exactly the savings they tend to see in their VMware environment. Quite recently one of my clients moved 600+ VMs from their incumbent array which were using 11.9TB of disk to a new NetApp array. Those 600 VMs of varied application, OS type and configuration deduped back to 3.2 TB, a 73% savings!

Once in a while though I get the call from a customer saying “Hey, I only got 5% dedupe! What gives?” These low dedupe numbers are almost always because of one of the following deduplication configuration mistakes.

Misconfiguration #1 – Not turning on dedupe right away (or forgetting the -s or scan option)

As Dr. Dedupe pointed out in a recent blog, NetApp recommends dedulpication on all VMware workloads. You may have noticed that if you use our Virtual Storage Console (VSC) plugin for vCenter that creation of a VMware datastore using the plugin results in dedupe being turned on. We recommend enabling dedupe right away for a number of reasons but here is the primary reason why;

Enabling dedupe on a NetApp volume (ASIS) starts the controller tracking the new blocks that are written to that volume. Then during the scheduled deduplication pass the controller looks at those new blocks and eliminates any duplicates. What if, however, you already had some VMs in the volume before you enabled deduplication? Unless you told the NetApp specifically to scan the existing data, those VMs are never examined or deduped! This results in the low dedupe results. The good news, this is a very easy fix. Simply start a deduplication pass from the VSC with the “scan” option enabled or from the command line with the “-s” switch.

Above, where to enable a deduplication volume scan in VSC.

Below, how to do one in Systems Manager;

For you command line guys its “sis start -s /vol/myvol” note the -s, amazing what 2 characters can do!

This is by far is the most common mistake I come across but thanks to more customers provisioning their VMware storage with the free VSC plug-in it is becoming less common.

Misconfiguration #2 – LUN reservations

Thin Provisioning has gotten a bad reputation in the last few years. Storage admins who have been burned by thin provisioning in the past tend to get a bit reservation happy. On a NetApp controller we have multiple levels of reservations depending on your needs but with regard to VMware two stand out. First there is the volume reservation. This reserves space away from the large storage pool (the Aggregate) and insures whatever object you place into that volume has space. Inside the volume we now create the LUN for VMware. Again you can choose to reserve the space for the LUN which removes the space away from the available space in the volume. There are two problems with this. First, there is no need to do this. You have already reserved the space with the volume reservation, no need to reserve the space AGAIN with a LUN reservation. Second, the LUN reservation means that the unused space in the LUN will aways consume the space reserved. That is, a 600GB LUN with space reservation turned on will consume 600 GB of space with no data in it. Deduping a space reserved LUN will yield you some space from the used data but any unused space will remain reserved.

For example say I had a 90GB LUN in a 100GB volume and the LUN was reserved. With no data in the LUN the volume will show 90GB used, the unused but reserved LUN. Now I place 37 GB of data in the LUN. The volume will still show 90GB used. No change. Next I dedupe that 37 GB and say it dedupes to 10GB. The volume will no report 63 GB used since I reclaimed 27GB from deduping. However when I remove the LUN reservation I can see the data is actually taking up only 10GB with the volume now reporting 90GB free. [I updated this section from my original post, Thanks to Svetlana for pointing out my error here]

In these occasions, a simple deselection of the LUN reservation reveals the actual savings from dedupe (yes this can be done live with the VMs running). Once the actual dedupe savings are displayed (likely back in that 60-70% range) we can adjust the size of the volume to suit the size of the actual data in the LUN (yes, this too can be done live)

Misconfiguration #3 – Misaligned VMs

The problem with some guest operating systems being misaligned with the underlying storage architecture has been well documented. In some cases though this misalignment can cause lower than expect deduplication numbers. Clients are often surprised (I know I was) at how many blocks we can dedupe between unlike operating systems. That is, between say Windows 2003 and 2008 or Windows XP and 2003. However if the starting offset of one of the OS types is different that the starting offset of the other than almost none of the blocks will align.

In addition to lowing your dedupe savings and using more disk space that required, misalignment can also place more load on your storage controller (any storage controller, not a NetApp specific problem). Thus it is a great idea to fix this situation. There are a number of tools on the market that can correct this situation including the MBRalign tool which is free for NetApp customers and included as part of the VSC. As you align the misaligned VMs, you will see your dedupe savings rise and your controller load decrease. Goodness!

Misconfiguration #4 – Large amounts of data in the VMs

Now this one isn’t really a misconfiguration, it’s more of a design option. You see, most of my customers do not separate their data from their boot VMDK files. The simplicity  of having your entire VMs in a single folder is just too good to mess with. Customers are normally still able to achieve very high deduplication ratios even with the application data mixed in with the OS data blocks. Sometimes though customers have very large data files such as large database files, large image file repositories or large message datastores mixed in with the VM. These large data files tend not to deduplicate well and as such drive down the percentage seen. No harm is done though since the NetApp will deduplicate the all the OS and other data around these large sections. However the customer can also move these VMDKs off to other datastores which can then expose the higher dedupe ratios on the remaining application and OS data. Either option is fine.

So there it is, the 4 most common misconfigurations I see with deduplication on NetApp in the field. Please feel free to post and share your savings, we always love to hear from our customers directly.