A few months ago we took over the IT support for an insurance firm in the City, but with the contract we inherited a problem the previous IT company couldn't resolve. Part of the firm's business still ran on a ten year SCO Unix server which was barely clinging to life and hadn't been backed up for three years. They still had a support contract with the original suppliers of the SCO system but they had quoted over £10k to migrate their data to the current platform. The system was running on borrowed time and every reboot could have been its last so we had to come up with a solution.

The client had already agreed to a complete network upgrade so we were migrating them to SBS 2008 with all new Vista client desktops, but part of the deal was that we solved the SCO problem. Our first priority was to get some form of backup as the integrated tape drive had last worked about three years ago, meaning any data they had on the tapes was probably irretrievable. To make things worse the server had no RAID array, the entire system was stored on one disk which was making unpleasant sounds. Since any solution was going to require rebooting the server we decided to risk removing the drive and powering it up in one of our lab servers so we could then create an image of it. The process was successful, the entire disk image was only 3GB and so we now had working backup.

Although we now had a disk image our options still seemed limited, the server was SCO Open Server Release 5 of 1997 vintage and there was no feasible upgrade path to any current OS. This meant any replacement hardware would have to be compatible with 1997 era Unix drivers, not something manufacturers are too bothered about supporting nowadays. We would have to source secondhand components which wouldn't really be solving the problem at all. The ideal solution would be to convert it to an ESX VM - we were already installing an ESXi 3.5 Server as part of the new infrastructure project and there was plenty of capacity for SCO's minimal resource requirements.

Unfortunately SCO OSR5 isn't on the list of ESX compatible operating systems so some research was required which turned up a couple of relevant blogs and forum posts. One very useful source of general SCO information is the A.P.Lawrence site, which included a page on "SCO 5.0.4 on VMware", at first this appeared to be exactly what we needed. The problem was that all the information available was installing SCO from scratch, not converting an existing installation. Whilst it probably wouldn't be too challenging for a SCO expert to copy the required LOB application from the old system on to a new virtual install this wasnt an option for us as we didnt have the OS install disks, or much SCO expertise. However the articles did at least prove it was technically possible to run SCO on ESX so we decided to have a crack at it anyway.

The first problem was to transfer the disk image onto the ESX server, our preferred tool for disk imaging is Acronis but in this case it didn't work. We established that this was because SCO is particularly picky about the disk geometry, its from the days of heads, cylinders and sectors, and it expects to boot itself from a specific disk location. Instead we used the VMware Converter BootCD to create a virtual disk image (see my Petri article here about how to do this) which we then imported to the ESX datastore. All the other VM properties were set to match the original system as closely as possible and this time it looked like it was going to boot, well at least it came up with the familiar SCO "Boot:" prompt. That was as far as it got though, trying the default bootloader option threw a rather unpromising system not found error.

The A.P.Lawrence page and other articles all specifically mentioned the need to update the BDC driver on the SCO system so it will recognise the ESX virtual SCSI adaptor. Interestingly it seems that if you virtualise to VMware Server you can avoid this problem by using the IDE adaptor instead, which would suggest the same applies for XenServer and Hyper-V environments too. IDE wasnt an option here so the "BLC BTLD" driver was downloaded, whereupon an unexpected problem was encountered. The driver in question is a small .exe which creates the bootable floppy from a disk in the floppy drive. As usual with modern systems we didn't have a floppy drive (or disk either), so instead used the handy VM Back application to mount a virtual floppy so the driver could create its "disk". After some experimentation we found a reliable method to boot the server using this floppy:

1. Allow the server to boot from hard disk and throw an error, then connect the boot floppy (you can't connect it until the VM is running)
2. Do a soft reboot of the VM so the floppy stays connected, then at the "Boot:" prompt enter defbootstr hd=Sdsk link=blc btld=fd(64) Sdsk=blc (0,0,0,0)
3. When prompted for the floppy press return and the server should boot
4. ESX is quite flakey with virtual floppies it seems, if the VM tells you there is no BLC on the disk then try reconnecting the floppy until it works

Obviously its not practical to have to do this every time the VM boots so we had to install the BLC driver into the kernel properly. This was more complicated as the scsi config file had to be edited to reflect the new drive layout but after a few attempts (VM snapshots helped a lot here) it worked and the server booted without intervention.

That was pretty much all the hard work over, the network config had to be updated but this was easily done from the SCOadmin menu - it recognised the ESX AMD virtual NIC without needing a new driver. All the users accessed the LOB application via a telnet based terminal client so nothing had changed as far as they were concerned. The only other problem was with printing, previously they had used an old parallel port HP LaserWriter which was also on its last legs. Fortunately one of their new network printers was an HP laser with a JetDirect module and the SCOadmin menu had an option for HP network printing. Following the menu instructions actually worked and the printer was added in less than five minutes, although it took somewhat longer to work out how to change the printing options in the LOB application.

Conclusion 

From the end user's point of view little has changed, their LOB application works in the same way as it always used to, albeit somewhat faster but speed was never a problem anyway. The main benefit they appreciate is that they can now print to the printer in their office, whereas before they had to go down several flights of stairs to the basement to coax the paper through the old HP LaserWriter.

For the disaster recovery scenario the situation has improved 100%, the entire VM image is backed up as part of the daily backup routine. Now it is virtual it is effectively hardware independant so the backup can be quickly restored to any ESX environment should the need arise. This has also enabled them to include the SCO server in our VHS-DR system; in the event of their office being out of action their key servers will be restored in our datacentre with a full terminal environment so they can continue to work remotely until they have an office again.

Finally, the client saved over £10,000 which they had been quoted for upgrading their LOB application to a current system, which covered the cost of the rest of their infrastructure upgrade.