Mission Penguin

Disk imaging has come a long way in the past ten years or so. The Symantec “Ghost” line of products used to be the preferred way to snapshot images, so much so that techs would often refer to cloning or imaging as “Ghosting.”

There have always been manual methods of pushing an operating system to multiple machines. You could use DriveCopy or PartitionImage to manually move hard drives and copy volumes, there were also hardware devices that would take a source drive and push its’ data (very quickly) to one or more destination drives installed on the same device. To get your image across a network you could use tools like ImageCast or RIS and answer files to perform full remote installs, but this was often hard to setup, time consuming to perform, and a royal pain in the butt if you had multiple machines that needed different exotic drivers.

Brief History of Ghost

Ghost was a great tool for streamlining the imaging process. It is a godsend for anyone who needed to roll out machines because it supports multicasting. Multicasting is critical for machine roll outs. Pushing a network image file from one server to one client works very well. However, concurrently pushing the same image to 10 or more clients will not only stress your network congesting it with image traffic, but the imaging process will potentially take many hours. Multicasting is a type of image distribution where a single source pushes the client to multiple machines. A simple analogy would be holding 10 conversations at once, each conversation having its’ own time line verses speaking to a group of 10 people.

I’ve been using Ghost for many years. It was first introduced to me by a college instructor back in 1998. I’ve grown accustomed to not needing a multicast solution, rather manually configuring boot media to load the appropriate drivers and network protocols then launch into a DOS or DOS-like environment where the ghost.exe menu system takes over and choices are made concerning what is to be imaged and where. Newer versions of Ghost allow for “Live” imaging where the locally running OS is imaged, and they allow peeking into a compressed image file to make adjustments for things like swap file removal (to reduce image size) and to make changes to things like host names, domain membership, and SID.

Where Ghost Fails

As I mentioned earlier, traditional Ghost requires a DOS-Like environment. DOS and similar environments have drawbacks with hardware support, memory management, and processor utilization efficiency which is important if you plan on using encryption or compression for your image file. This also means you need DOS drivers for your NIC, as well as any drive controller for what you intend to image. If for example, you have an exotic NIC or crazy fast fiber channel RAID controller, you may be out of luck where network imaging is concerned. There are also issues of network speed. Yes, multicasting is faster than single machine images when performing a large scale machine rollout, but what if you need to image just one machine? What if the source file for the machine to be imaged spans your network WAN? What if you would like to secure the transfer of your image via SSH? And of course there is the cost. During a recent conference call with our software vendor and his local “Symantec Expert” I was told I would have to purchase a copy of Ghost for every machine to be imaged. Granted, this was only $1200 for the small 30 machine roll out I was doing, but it was $1200 I don’t think I wanted to spend.

Like taking away a childhood blanket, I believe it's about time we begin to seriously consider the potential of alternative products for enterprise scale image deployment.

Potential Options – All the usual disclaimers

For the sake of Mission Penguin, I’ll limit the potential non-Ghost options to OpenSource solutions. I also feel that now would be a good time to disclaim the information I’m about to give. My Linux “Newbie” status prevents me from being responsible for the accuracy of anything that follows :-)

I feel I fall into the same crowd as the majority of network administrators. I’ve got a strong background in Microsoft products, I’ve been Microsoft certified since forever and I have various other degrees/certs/etc... but my experience with Linux thus far can only be described as hobbyist. If you want good information go to the source, DON’T RELY ON THIS DOCUMENT.

In looking for a Ghost alternative I’ve come across quite a few open source solutions. Some of them include:

PING
Clonezilla
G4U
MIDS
GParted LiveCD (Clonezilla via GParted)

There are many other solutions available. Most will in one way or another cobble together existing OpenSource utilities in an effort to become a one stop shop for your disk imaging needs. You could of course build your own bootable media with your favorite Linux distribution and throw these same tools on it, as well as any additional tools that you may require to diagnose, fix and repair computers on your network. I’ve done this with Feisty Fawn on a USB thumb drive and found it to work great, but that exceeds this project scope.

PING

PING is a tool developed by SYS Angel, a computer consulting firm that specializes in machine roll outs and client management. As a side note about SYS Angel, they are very competent with the Linux platform and OpenSource products but unlike other companies with similar strengths (Linux Box) they make Microsoft products the focus of their support. This is a rare dynamic to see a consulting group combine the benefits of both Linux and Microsoft products.

From the SYS Angel site:

“PING (Partimage Is Not Ghost) is the perfect
choice to backup and restore whole partitions,
an easy way (DVD or Network).”

I can’t say that PING is perfect, but it is a pretty slick product. After reading the manual you’ll notice that the intended audience for PING is the Windows administrator, who may not have a deep understanding of the Linux platform. Think of it as a product for those who don’t already have all the answers.

The most notable features of PING are the support for PXE boot environments, DVD based drive images, and splitting large images across multiple bootable DVDs. Unfortunately PING does not currently support multicasting. While these features are all pretty cool, I’m only interested in how well PING images a single Windows XP client from an image file saved on a Windows 2003 server.

Getting PING started for my scenario is a simple 3 step procedure:

1. Make a share on your Windows server that will hold the disk images.

2. Download and burn the PING iso.

3. Boot from the iso, follow the prompts to push or pull the image to or from your network share

Seems simple, no? Well, no actually. The kernel, or rather kernel configuration used by PING did not recognize the Broadcom NetXtreme NIC used in our IBM clients. After sifting through forums I found that this problem was very common, not just with IBM, but also HP and Dell. It seems the Broadcom NIC is supported by the Linux kernel, but depending on the kernel version and build options the NIC may not be recognized.

Broadcom has apparently given a big thumb in the nose to the Linux community. The occasional NIC failures and poor performance has been blamed on the vendor not keeping the NIC chipset consistent between NIC destinations. Meaning, the Broadcom NetXtreme NIC may work great in an IBM machine with Ubuntu, but the same platform will not recognize the NIC integrated on a Dell machine, or fail with the same kernel version on a different Linux distribution.

This may be an issue with something totally unrelated to Broadcom and their NIC, but that doesn’t really matter to me. The bottom line is PING doesn’t recognize my NIC.

The solution? Build another kernel, choose different options, and replace the kernel in the ISO with the kernel I built. I’ll let you know how it goes, as well as add benchmarks for the various solutions in part II.