Let me start off by saying that there are very few good reasons to do this. There is no real way to secure a Red Hat 6.1 server, especially when it is running on the Internet of 2007. A machine this old should be taken out back and shot, not converted into a virtual machine and run for who-knows-how-many years more.

That said, there may be a situation where this ancient OS is running some binary files that some other vendor made. If you’ve already tried to build a more modern system using the compat libraries and the old binaries will run, but not correctly. If the old system is using a custom-built, non-rpm, openssh, openssl, glibc, and apache. If the old hardware is failing, and you’re running out of the ability to purchase hardware that the 6.1 kernel will recognize. And, of course, if the client is paying you to do this and absolves you of any liability.

Oh yeah, and there is the added complication that the current live system can’t experience any downtime.

If that is your situation, here is what you need to do:

1. Start up VMWare and create a new virtual machine.
2. Under VMWare 1.0.2, you cannot create a machine with a virtual IDE disk, so you have to edit the machine you just made, remove the SCSI disk and add an IDE.
   • This is needed because the RedHat 6.1 kernel does not recognize the virtualized SCSI card.
3. While you’re at it, add another virtual CD drive. It’ll come in handy later.
4. Now, ideally, at this point, you would install a bare RH 6.1 system, but you can’t because the RH installer can’t see the virtual IDE disk, and the kernel doesn’t recognize the virtual SCSI card. You might think that you’re out of luck, but you’re not!
5. At this point, go into the virtual machine settings and link your primary virtual CD drive to a bootable Linux .iso image. I used Open SUSE 10.2
6. Power on the virtual machine and go into the boot menu, select CD, and go into whatever “rescue” mode your distro of choice has.
7. Now, for a nice flash from the past, you get to use fdisk. Run fdisk /dev/hda.
8. Manually set up your partitions to match the machine they’re coming from. You just have to match the “used” size, not the allocated. If you’ve not filled up the drives in the past 8 years, you’re not likely to do now.
9. Make sure that you change the partition type for the swap partition to type ’82’.
10. Make sure that you set the partition that will be /boot to bootable.
11. Now, use “mkfs.ext2” to create your filesystems. Remember that RH 6.1 does not support our modern file systems like ext3, reiserfs, xfs, or nss. You have to create what is there.
12. Do not format the swap file system. That has to be done later. I know it’s irritating.
13. Now, you’re ready for the fun copying part. If you’re like me, the ethernet card is not yet working, as rescue mode didn’t find the files it needed to start things up. That’s OK, you don’t need it.
    1. On the machine you’re copying, start making gzipped tarballs of each directory. Bear in mind that no tarball should exceed 600Mb in size.
    2. While you’re tarring things up, on the soon-to-be-live system, create your mount points and mount the new partitions that you’ve made. i.e., make the /boot directory, and mount the /boot partition onto it.
    3. Once all of the tarballs are made and copied to some host system (as you likely will not have space on the original machine to store them), start making them into .iso images.
    4. Now, for each .iso image you made, link the second virtual CD drive to them, and mount them on the new virtual server. Then, you can start restoring the tarballs onto the brand new filesystems that you created earlier. Repeat until done.
14. When that is done, change your directory to the mount point that will be / when the system is ready to be live again. Issue ‘chroot .’ If everything went well, the system will look like it should when it goes live.
15. While chrooted to the soon-to-be-live system, edit /etc/fstab and make sure that the partitions match what you’ve created. If you weren’t careful when running fdisk, things might be a bit off. Just correct them here.
16. Also while chrooted, issue lilo -v, to write the boot sector.
17. Now, if you did everything correctly, you can exit the rescue mode and reboot the virtual machine.
18. As it comes up, you will see a few errors and kudzu will almost certainly complain. Ignore them for now.
19. Once the machine is up, log in as root, and make the swap space. mkswap /dev/hd whatever* Also, you will likely want to issue chkconfig kudzu off. This will prevent the system from trying to reload drivers for the new hardware on boot. When I did this, kudzu core dumped on me, so instead of it complaining on every boot, I just turned it off.
20. Now, you can reboot the virtual server. Watch the screen as it comes up. Every line should be [OK]. If it is not, you will have to dig into logs and determine what is different for your system.