P2V Migrations with GPT-Based Windows Servers

VMware Converter is a fantastic, free tool for performing P2V migrations. It does, however, have its limitations. One of them is being unable to convert GPT based disks. Most admins have no idea that they have built a GPT based disk. That’s due to Windows 2008 R2 detecting a UEFI firmware (which most servers built in the last 3-5 years have and enable by default) and creates a GPT disk without any options to change that. It’s not something that affects normal applications from running, so most admins don’t even think about whether their disk is GPT or MBR based.

If you run the VMware Converter against a GPT based disk, you’ll receive an error about EFI firmware not being supported. Here’s how to P2V a GPT based Windows server (for free!). What we’re doing is taking a cold image based backup of the physical server and restoring it into a VM. To do this, we’ll use a free and open source tool called Clonezilla. While you could power up the physical server while you get the VM built, it’s best to keep the physical server offline until you bring the VM up. This will prevent data changes between when you take the image and when you restore it.

1. Run Clonezilla against the physical box and image the server to an ISO
2. Create a VM with the production name of the server
   1. Make sure the VM’s disk is the same size or bigger as the physical server’s disk
3. Boot the VM from the ISO
4. Restore the image from the samba_server option
5. The following steps came from Andrew Cohon at Andrew’s Cheap Thrills
   1. If you get a STOP 0x0000007B error, follow these steps:
      1. Mount the Server 2008 R2 DVD to the VM and boot to it.
      2. At the first screen (Language Selection), hit Shift-F10 for a command prompt.
      3. Run Regedit.
      4. Load the system hive from the VM’s disk:
         1. Highlight HKEY_LOCAL_MACHINE
         2. File > Load Hive
         3. Select < c: > \Windows\System32\config\system
         4. Name it something like “asdf”
1. Expand HKEY_LOCAL_MACHINE\asdf\ControlSet1\Services\LSI_SAS
2. Change the data for value “Start” from “3″ to “0″.
3. File > Unload Hive.
4. Exit regedit.
5. Reboot the VM.
6. Install the VMware tools.
7. Remove the old network adapter
   1. Open a command prompt and type the following
      1. set devmgr_show_nonpresent_devices=1 (hit enter)
      2. start devmgmt.msc (hit enter)
   2. Go to the View menu and click “Show Hidden Devices”
   3. Go into Network Adapters and remove the greyed out adapters
8. Put the production IP on the VM’s NIC.

Hope this helps someone out!

How To Tell If Installing An Enabler On An EMC Array Requires A Reboot

I was about to install an enabler on a production array when a thought crossed my mind: “Does this require a reboot of the storage processors?”

I stopped, pondered and then Googled.

Documentation? Limited.

Forums? Informative.

I found the following post on the EMC Community forums on how to tell if an enabler requires a reboot. I call it the “peek behind the curtain” check. The enabler file (.ena) is really a ZIP file (.zip). Change the extension, open the file, and then open the TOC.txt file. In there, you’ll see the following:

That INSTALL_REBOOT_REQUIRED line will tell you whether or not a reboot is required.

It turns out that specific enabler did require a reboot. Saved my biscuits.

Changing The Admin Password of UCS

Thanks to Terrance Luk for this one. I do a lot of installs of Cisco UCS and I knew it was only a matter of time before I typed a password incorrectly as part of the setup. Sometimes I don’t let go of the shift key quick enough so typing something like “Password” goes in as “PAssword”. I couldn’t figure out why I couldn’t get into UCS from the command line, so I tried that and it let me in. This blog post from Terrance shows you what to do once you get in.

This could also be useful to set a temporary password during the install and then be changed later after the install is complete.

Cisco UCS Central 2.1: Installation and Configuration

I’ve been mentioning to customers who have more than one Cisco UCS fabric interconnect cluster that UCS Central is out and that it provides management of both clusters in one tool (editor: I really dislike the term “single pane of glass”). At its most simple level, UCS Central is UCS Manager for UCS Managers. It’s designed for customers who have UCS at different sites or multiple installations in a single site. I figured I’ve been mentioning it to customers so much that I should probably understand the deployment and real world capabilities of the product.

Before you go through the process of installing UCS Central, make sure all UCS clusters that you plan on adding to UCS Central are on the 2.1 firmware. Older firmware is not supported with UCS Central. From a deployment standpoint, there are two options. One is a clean build from an ISO, the other (and my preference) is a pre-built virtual appliance. Deploy the OVA into your virtual host and power it up. If you’ve ever configured a brand new fabric interconnect, the setup prompt will look very familiar. The only difference is the addition of the shared secret. The shared secret is the password you’ll use to register UCS domains (clusters) with UCS Central. It cannot be a dictionary word, and you’d be surprised what’s in the dictionary. I recommend doing a letter/number replacement. 0 for o, 4 for a, etc. After you apply the configuration, you’ll have successfully deployed UCS Central.

There are some things you’ll need to do before you register a UCS domain with UCS Central. First, configure NTP on UCS Central. This is located on the Operations Management tab under Domain Groups, Domain Group root, Operational Policies, Time Zone.

Next, configure NTP on the UCS domain. This is under the Admin tab, Time Zone Management:

Time synchronization is very important. If the time is off, a UCS domain will fail to register.

Wait for the System Time in the bottom right corner to match up. The hour may not match up, but that’s OK. If it doesn’t match, it’s the time zone difference between where you are and UTC. In my screenshots, that’s 6 hours (Eastern Daylight Savings Time). Once the time sync is complete, it’s time to register with UCS Central. Under the Admin tab, go to Communication Management, UCS Central.

Click “Register With UCS Central”. A new window will appear. Enter the IP or hostname of UCS Central in the Hostname/IP Address field and the Shared Secret you configured in the initial deployment of UCS Central.

The options in the window are to determine what has control, the local configuration or the global configuration in UCS Central. This can be changed later, so you can register it with everything on the local configuration being left alone. This could be used as a configuration tool for a new install if you had a standard build to use with it.

Click OK to kick off the Registration. If you want to see the progress (which isn’t much), click the FSM tab. When it’s done, you’ll see the following in UCS Central:

At this point, UCS Central is able to manage that UCS domain. At this point, UCS Central is limited to mostly view-only things. It can see service profiles, templates, pools, etc. but can only make limited changes to them. In later versions, you’ll be able to create global service profiles and templates. This will allow you to move service profiles between domains, which is an amazing idea.

Here’s Cisco’s data sheet on all of the features of UCS Central. You can build this in your home lab (like I did), using the UCS Platform Emulator. It’s a fantastic tool for playing around with UCS and testing out the features of new products like UCS Central.

Get in there and dig around. Let me know what you think in the comments.

Started From The Bottom

Shameless plug for Dan Weiss’ “Fried Chicken Builds Character” post.

After reading it, I started thinking about where I (and my family) came from. My dad loves to tell this story, so I figured I’ll tell it here. My dad grew up in the Hawkins Village projects of Rankin, PA, just outside of Pittsburgh. It wasn’t a nice place then, it certainly isn’t a nice place now. Growing up in the Steel City, it was almost a guarantee that you got a job in one of the mills. Rankin happens to be next door to Braddock, the home of U.S. Steel’s Edgar Thomson Works. After high school, he went across the street (literally) into the employment office of the mill. After doing some random maintenance jobs, he decided enlisting in the military was a better idea (it was 1969, he was sent immediately to Vietnam).  After coming back, he went back to the mill for a few years before using the GI Bill to go to college. He knew he wanted to get out of Pittsburgh and raise a family that wouldn’t have to work in the mill. He became a lawyer and gave us every opportunity to succeed. Fast forward to my senior year of college. A professor mentioned that I should take the internship test for the U.S. Steel. At the time, they had a math test for IT positions. I almost didn’t go because it meant getting up at 8 AM on a Saturday. No, I’m not kidding. I took the test and passed. Got through the interview process and into a well paying internship for a large company that generally hired its interns upon graduation. My dad was proud of me and thought it was great that I was going to work in the office instead of the mill. Before I started, I got a phone call asking if I would mind changing locations and working in the mill. Not just any mill though, the Edgar Thomson Works in Braddock, PA. I accepted. I told my dad and his first words were, “I worked my tail off to make sure you kids didn’t end up in the mill. What’s your first job out of college? A job in the mill…” I could hear the smile on his face. He recognized the hilarity of the situation and thought it was fantastic that I was working in the mill. He thought I should move into Hawkins Village and wondered if his old building was still there (it wasn’t and had burned down 15 years ago). 

I look back on that story and realize the phone call to go work in the mill was a complete blessing in disguise. Headquarters was siloed. I would have been stuck in desktop support effectively forever. In the mill, I did desktop, network, server and application support. I got a far wider experience in the field compared to the interns at headquarters. I worked so hard that they felt forced to hire me because they couldn’t lose the effort I put in. I was on call 24/7/365 from the second year of my internship (I did a 5 year program in school, so I had an extra year of internship) through the last day of work 3.5 years later. I learned more in that job both professionally and technically than I learned in 5 years of school. The people there took chances on me and I feel it paid off. I’m forever grateful to them for giving me an amazing start to my career. Hard work makes the dream work. 

Changing the IP of vCenter 5.1

Some quick backstory: I’ve been having issues with wireless internet at my house for a bit and decided to swap out the router to see if that was the issue. It was. This introduced a new problem, which was a completely new IP scheme (192.168.x.x from 10.0.x.x). This is not something you would normally run into in a production environment, but you could run into this issue when your network administrator wants to move stuff to a newer, bigger VLAN (or something of the like).

Changing the IP of vCenter in the past wasn’t a terribly hard thing to do. Change the IP, modify the proxy.xml file (if needed), restart services, done. You may run into an issue on the DB side (See my previous post on changing the IP of vCenter here), but other than that it’s easy peasy. Enter Single Sign On (SSO). It’s a crucial piece of the puzzle that gets overlooked when you’ve changed IPs on a vCenter box.

I made the normal changes, including changing the IP that SQL Server (also running on the vCenter VM) was using. I start the VirtualCenter Server service……no bueno.

Let’s start with the logs. Tracing the vpxd log under C:\ProgramData\VMware\VirtualCenter Server\Logs finds the following error:

 

It was failing making the connection to Single Sign On for the STS Root certificates. Here’s the fun part: SSO starts regardless of what IP it has. I’m staring at the VMware Single Sign On service and seeing it’s started and wondering why nothing can connect to it. Checking the logs at C:\Program Files\VMware\Infrastructure\SSOServer\logs shows the following:

SSO had the wrong IP for the database server (all on the same box, it’s a lab) and couldn’t connect to LDAP for AD authentication. That’s not cool. Enter this VMware KB (2033516): http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033516

Performed the changes, ta-da vCenter started.

Installing vCenter Single Sign On with SQL Server

In the wake of my post on the introduction of Single Sign On, I noticed many people were searching for installation help. So I figured I’d write up how I did it in my lab.

There are two ways to go about this. The installer gives you the option of SQL Express or using a supported database (MS SQL, Oracle, DB2, or Postgres). In this post, I’ll show you how to install SSO with an existing SQL Server instance. The easiest way to install SSO is to use the SQL Express as the installer handles the DB creation and connectivity. From a backup perspective, an existing SQL Server instance is far better.

For this, you’ll need an existing SQL Server instance. This can run on either the vCenter itself or as a separate server. I won’t bog through installing SQL Server, we’ll just assume you’ve installed it and have it running.

Step 1: Create the database.

Inside [vSphere 5.1 Install Media]\Single Sign On\DBScripts\SSOServer\schema\mssql is a set of scripts that will build or change the Single Sign On database. Open SQL Server Management Studio, connect to your SQL Server instance and drag rsaIMSLiteMSSQLSetupTablespaces.sql into Management Studio.

This will open a new query window in SQL Server Management Studio. We need to change the file locations for the database.

Change this to the location you wish to save the file into. Do this for the other two file location lines. These should all stay together unless you specifically (and in production, should) separate log files from data files. In this case, this is in my lab so I kept them in the same location.

Execute the procedure and a new database called RSA will be created.

We will also need to enable Mixed Authentication. The installer uses a built in user to the database (RSA_DBA) to connect to the database. Right click on the SQL Server in the left pane and click Properties. Click Security in the left pane of the new window and select SQL Server and Windows Authentication mode.

You can close SQL Server Management Studio now.

Step 2: Install Single Sign On

Run the installer from the install media. This can be done via the “Simple Install” (which installs SSO, vCenter Inventory Service and vCenter Server) or by installing just SSO.

Create a new primary node for a vCenter Single Sign On Installation

In this instance, we’ll create a primary node for a new installation. Because we’re doing this, you could add another node later for high availability. Without this, you’re stuck with one node. If that node fails, so does vCenter. If you set up basic, I would suggest running it on the same machine as vCenter as it eliminates a point of failure. The only failure points are the service  failing or the backend database not being available.

Create a password. Make it a good one and save it somewhere safe (like KeePass or LastPass).

Because we’ve already run the SQL script to create the database, we’ll select the Use an existing supported database option. The SQL Express option is far easier, but doesn’t scale up as well and backups are a bit trickier.

Here’s where the fun begins. Set the database type to Mssql, insert the database name of RSA (which is the database the script creates), enter the IP or hostname of the SQL server, and check Use Windows Authentication. Make sure you’re an admin on the SQL server or you’ll get an authentication failure. If you knew a SQL user that had admin rights, you could enter those credentials here.

Click Next on the Fully Qualified Domain Name or IP Address of the host. If it can’t resolve the hostname, that’s OK.

Next, select a user account to run the Security Support Provider Interface server as. I took the default in my lab. If you have an application-only user you prefer to use, here’s where to enter it. I would make sure it has rights to the Single Sign On database. In my case, I was running it on the same machine as Single Sign On so the default was sufficient.

Select the location you wish to install the Single Sign On service to

Select the port you wish to use for the service. Taking the default is preferred here.

Click Install. If you get any errors, run them through the VMware KB. The documentation is well done on common errors. I got a “Error 29115: Cannot authenticate to DB” error, which was resolved by setting up SQL and Windows authentication on the database server.

That’s it! Install the Inventory Service and vCenter Server and you’ll have an up and running vCenter 5.1 install.

If you’re upgrading your existing vCenter and will run SSO with it, I would HIGHLY recommend adding memory to the VM or machine running vCenter. It works with 4 GB but is much more responsive with 6 GB at a minimum, 8 GB if you can spare it. The other option is to split SSO off onto its own VM or machine. You could build a multi-node install for availability this way.

Leave comments below and I’ll try to answer your questions!