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!

Here is how I set up my vDS. I basically used the 3 host configuration example in What’s New in VMware vSphere 4: Virtual Networking white paper as a guide.

First I created a new vNetwork Distributed Switch in Inventory->Networking.

I configured it for 8 dvUplink ports. Why 8? Well I have 8 NICs in each of my host, and I would like to be able to use and manage all eight of them across one vDS.

I added each of my host to the vDS but did not add any physical adapters yet.

After the new vDS is created I created my port groups. One port group for the Service Console, one for vmotion, and one for each of my production VLANs.

When creating these port groups I just used the defaults except for changing the VLANs where needed.

Now that I have my vDS set up, time to migrate the host networks to the new switch. In Inventory->Hosts and Clusters select the host Configuration tab then Networking and the Distributed Virtual Switch button.

First i migrated the Virtual Machine networks to the new vDS. I took one NIC out of the port channel on the physical switch and added that physical NICs to the vDS. I did this for each of my hosts.

Then I use the Migrate Virtual Machine Networking wizard to move all of my VMs from the vSwitch port groups to the new vDS.

After this is done I add the rest of the physical NICs associated with my VM network to the vDS and recreate the port channel on the physical switch.

Now on to the vmkernel ports. I used the Manage Virtual Adapters wizard to migrate my VMotion VMKernel adapter to the new vDS.

I then did the same to my service console. Before I started making changes to the Service Console I put the host in maintenance mode. I created a new service console with a new IP address on the same subnet on my management port group and made sure I had connectivitiy (OK I did not do this the first time, messed up and lost the Service Console connectivity to my host – had to go CLI to fix it, but that is a completely different multi-page post in itself – very thankful for the spare NIC I have in each host).

Since my vMotion vmkernel port and Service Console are now on the vDS I attached their physical NICs to the new vDS and then added them to the port channel on the physical switch.

vNetwork Distributed Switch Screenshot

The only issue I had was with the iSCSI vmkernel ports. I was not able to get them to work on the vDS so they are still configured on a vSwitch on each hosts.

Not sure why I could not get it to work, but I will tackle that another day.

After I verified everything works, I deleted the old Virtual Switches from each host.

Just a quick overview of how I set up my vDS. Hope you find it helpful.

TGIF!

HAVE A GREAT WEEKEND!!!

Unfortunately the turn out was not that great only a handful of folks showed up. Traffic was terrible and it took a little over an hour to make the 30 minute drive from Chesapeake to VA Beach, probably a reason for the low turn out.

Despite the small crowd it was still a great event. Tom Lennon from RSA Security did a presentation on some of their current and upcoming offerings. RSA’s log collection and analysis product – enVision – looks pretty interesting, definitely something to get a little more info on. I got to say a little bit about my experiences at EMC World (I am still working my blog post about it – so much good stuff, so little time). Chatted with a couple of other EMC customers and partners about technologies they are planning on or currently using – AVAMAR, VMware, Celerra, etc.

The appetizers were good, the drinks were cold, and Stephanie & Joe from EMC were great hosts.

A couple of folks from Varrow out of NC were there and it was pretty cool chatting with them. Check out their community blog at http://www.varrowblogs.com/ – some good info there.

The local EMC folks are planning to have User IT Group meetings once a quarter. I’ll be sure to post when the next one is, hope you can make it.

f_cache = N * 40MB

N = Millions of Files
So for 3 million files:
f_cache = 3 * 40MB
f_cache = 120MB

p_cache = DB Size in GB/Average Chunk * 20MB

Average Chunk Sizes:
Exchange DB: 16
Microsoft SQL DB: 24

For a 100GB Microsoft SQL DB:
p_cache = 20/24 * 20MB
p_cache = 83.3MB

http://blogs.vmware.com/kb/2009/05/resolution-paths-published.html
–
Many common tech support issues in VMware products can be solved using what we call Resolution Paths. Resolution Paths are collections of modular steps that can be used to solve tech support issues.

These can be very handy and can save you having to make that call into Tech Support. Click the links below. There’s one for each potential problem area.
http://blogs.vmware.com/kb/2009/05/resolution-paths-published.html