But that is a good thing.

Lot of cool stuff happening and hope to have some more time later this week to post some stuff.

lsb_release -a

This command is used to display the Linux Standard Base and Distribution info and the lsb_release man page can be found here.

Here is the information it displays:

user@srv:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick

Currently our vCenter is on a separate physical box running Windows 2003 with 4 GB RAM and a single 2.66 Ghz dual core processor. The vCenter database is on Microsoft SQL 2005 also running on the same physical box. The hardware we have in place would support running vCenter 4.1 but since 4.1 requires a 64 bit OS, and ours is currently running on 32bit, I am going to upgrade/migrate vCenter to a new guest VM running Windows 2008 R2 64. I am also going move the vCenter database to the new VM (I know it is not necessarily best practice to run the DB on the same box as vCenter but my environment is small and it should work out ok – if not I will move the database to another server at a later date) which is running Microsoft SQL 2005 x64.

The vSphere 4.1 Upgrade Guide available from VMware provides a detailed step-by-step process. This VMware KB article (5850444) also gives an overview of the process of moving vCenter and the SQL database from one host to another.

Here is my basic walk-through of upgrading to vCenter 4.0 to 4.1 while moving to a new server that happens to be a VM.

1. The new guest hardware is configured with 2 vCPUs, 4 GB RAM, and 2x20GB hard drives (1 for OS and 1 for data). I have installed Windows 2008 R2 and installed all the “important” updates from Microsoft. Microsoft SQL 2005 has been installed and Service Pack 3 has been applied to it. Microsoft .NET Framework 3.5.1 Features has also been installed using Server Manager.
    
2. Using the SQL Server Management Studio two new databases are created on the new server, one for vCenter and one for VMware Update Manager (VUM).
    
3. Set up a 64bit ODBC connection to the vCenter database and a 32 bit ODBC connection to the VUM database. Both connections are set up as System DSNs and use the SQL Native Client. To create the 32 bit ODBC connection use the application C:\Windows\SysWOW64\odbcad32.exe
    
4. Note what ESXi host the new 4.1 vCenter VM is running on so you can connect directly with the vSphere client if a console is needed. Stop the vCenter Server service in services.msc on the 4.0 vCenter server. (I also disabled the service).
    
5. Use SQL Server Management Studio to create backups of the 4.0 vCenter and VUM databases. Then restore the databases to the newly created databases on the new vCenter 4.1 server.
    
6. On both the 4.0 and 4.1 server copy the datamigration folder from the vCenter iso to C:\datamigration and unzip the datamigration.zip file within the folder. On the 4.0 server run the backup.bat script. This script will create a data directory in the C:\datamigration. Copy this directory (and its contents) to C:\datamigration on the 4.1 server. Note: If you are using the SQL 2005 Express database for vCenter the datamigration backup script will also backup the vCenter and VUM databases.
    
7. Since we wanted the new vCenter 4.1 server to have the same IP address as the old server, this is the point where we changed the IP addresses of both the 4.0 and 4.1 servers and verified DNS was resolving everything correctly.
    
8. Connect the CD on the new 4.1 server to the vCenter iso (you will need to connect to the host with the vSphere client to connect the CD to VM unless you did this before you stopped the vCenter Server service – live and learn). Run the install.bat file located in C:\datamigration on the 4.1 server to start the vCenter installation.
    
9. The VMware vCenter Server installation wizard will run. Follow the installation and make the necessary choices. When prompted for the database select the use existing supported database option and choose the ODBC/DSN (64bit) that was set up for vCenter. Select upgrade the database to 4.1.
    
10. Once the vCenter Server installation completes the VUM installation wizard will launch. Follow the same process for the VUM installation. When prompted for the database select the use existing supported database option and choose the ODBC/DSN (32bit) that was set up for the VUM database.
     
11. Once installation completes log in to the new vCenter Server using the vSphere Client install the updated VUM plugin. Check each host for a task – Upgrade vCenter Agent.
     
12. Test, test, and then test. – I checked the following: DRS/HA configurations for the cluster, perform a vMotion of a VM, Scan a Host for Updates, Check any scheduled tasks, Check logs for any errors, etc.
     

The update went without issue and our vCenter is now 4.1 on a Windows 2008 R2 64bit virtual machine. Will be upgrading the ESXi 4.0 hosts to 4.1 next week.

@jirahcox had sent me the following tweet the night before “@herseyc I had to uninstall Update Manager 4.0 then reinstall 4.1 with a clean db. UM 4.1 over 4.0 installed fine, but wouldn’t scan hosts.”

I did have to reattach my update manager baselines before I could scan hosts. Not sure why the baseline attachments did not carry over in the datamigration/database restore??? But after reattaching them all worked well without having to reinstall VUM. Thanks to @jirahcox for the heads up on a potential issue.

Here is a list of resources I used to research and prepare for the migration:

• vSphere 4.1 Upgrade Guide
   
• VMware KB: Migrating vCenter Server to a different host machine
   
• VMware KB: vSphere 4.1 upgrade pre-installation requirements and considerations
   
• VMware Migrate vCenter 4.0 Database to New vCenter 4.1 Server
   
• Virtualizing vCenter With vDS Catch-22
   
• Design Challenges Of Virtualized vCenter With A vNetwork Distributed Switch

Still have some work to do and this is probably not the last change, but it would be great to hear what you think.

Thanks!

Google’s new 411 service is free, fast and easy to use. Give it a try now and see how simple it is to find and connect with local businesses for free.

Just call 1-800-466-4411

Merry Christmas!!!

As part of this process we had to failover to our standby datamover. Thought these commands might be useful later so here they are.

server_2 – Primary datamover
server_3 – Standby datamover

Fail over to standby mover

# server_standby server_2 -a mover

Faults server_x and renames it to server_2.faulted.server_3
Renames server_3 to server_2
server_3 is now online as server_2

During the time it took to failover I dropped 3 pings to the datamover.

Fall back to primary mover

# server_standby server_2.faulted.server_3 -r mover

Renames standby server to server_3
Renames server_2.faulted.server_3 to server_2
server_2 is now back online as the primary mover.

Again I dropped 3 pings while the datamovers switched.

Here are a couple other useful Celerra commands.

Listing your datamovers and their status from the command line:

# /nas/bin/nas_server -l
id type acl slot groupID state name
1 1 0 2 0 server_2
2 4 0 3 0 server_3

You can get this info from the GUI but this is quick if you are logged into the Control Station CLI.

View the nas version running on your datamovers:

# server_version ALL
server_2 : Product: EMC Celerra File Server Version: T5.6.46.410
server_3 : Product: EMC Celerra File Server Version: T5.6.46.410

Basic stuff but it might be useful to have on hand later.

If you are running RedHat 9.0 and want to run “headless” (no monitor, keyboard, or mouse) but still want to have a console to receive console messages or login, here are the basics of what I did to get it working.

This example will set up a serial console on Com 1 (ttyS0) at 38.4K Baud, Data bits 8, Parity None, 1 stop bit.

Requirements:

* agetty – alternative Linux getty – agetty is included in the RedHat 9.0 Installation (unless you chose not to install it)
* A Null Modem Cable – To connect to your PC, laptop, or terminal. You can make one yourself or pick one up from Radio Shack for a few bucks.
* Running lilo as your boot loader.
* Support for console on serial port must be compiled into the kernel (not loaded as a module) This option is located under Character devices – it is compiled in by default on Redhat 9 installations.
* Root access.

Make sure you set up your BIOS to continue on Keyboard or Mouse errors. Some machines will allow you to ignore these errors specifically, on others you may have to configure it to continue on any error.

In /etc/lilo.conf add this to the global section:

serial = 0,38400n8

Then add this to the append line in the kernel section:

append = “console=ttyS0,38400n8″

If you are already using an append for other options just add console=ttyS0,38400n8 to the end of those. Once you have made the changes to /etc/lilo.conf remember to run /sbin/lilo to set the new configuration for the next boot.

To enable the ability to login on to the machine using the serial console add the following line to /etc/inittab:

s0:12345:respawn:/sbin/agetty -i -h -L 38400 ttyS0 vt100

Connect the null modem cable to Com 1 and then to your PC, Laptop, or Terminal. Configure the connection (terminal program) for 38400 baud (38.4k), 8 data bits, parity none, and stop bits 1. (On windows you can connect using Hyperterminal, TeraTerm, or any other terminal program that supports serial ports. On a Linux machine you can use minicom).

Now reboot the linux box that you configured the serial console on and monitor the connection. You should see the kernel decompress and then the boot messages over your serial connection. Once the machine has finished booting you should receive a logon prompt on the console.

If you receive a bunch of garbage on the terminal check your baud and parity settings. If you do not receive a logon prompt check you inittab configuration and make sure agetty is running on ttyS0 (ps -ef | grep agetty).

For more help check out the man pages for agetty, lilo, lilo.conf, and inittab.

You can also try a google search for linux serial console, there are a lot of other similar ways to do this.

Use the Stage wizard to download the patches before using remediation. This downloads and prepares the patches while the host is still online. This decrease the amount of time the host is off line (in maintenance mode) will applying patches.

Stage and Remediate in Upate Manager

You can stage at the cluster and Data Center level to prepare all hosts in the cluster for remediation.

Update Manager Stage Wizard

Shortcuts in Home-Inventory-Hosts and Clusters

Stage and Remediate Host - Cluster and Data Center

Just updated to ESX 4.0.0 build 175625. Staging took about 3 1/2 minutes total and remediation took about 12 minutes per host (this include Entering maintenance mode, VM migration, patch installation, reboot, exit maintenance mode). Three and a half minutes of savings may not seem like much, and across three hosts it really isn’t that big of a deal, but across 20 hosts that would make a huge difference.

Awesome new vSphere feature!