Wayne Stallwood wrote:
Of course if the aim is just to minimise the time spent tinkering and you don't see value in turning this into more of a Disaster Recovery test then your proposed method may or may not save time depending on problems you encounter with different hardware, fixing the bootloader (in itself pretty easy) etc
This is a pretty good sum up, to be honest.
The RH9 server hosts a lot of old development versions of customer sites, which don't see much action these days. It also hosts some internal web applications which see regular use but run slowly due to the old hardware.
The "correct" solution would be to migrate the sites to another server and mothball the old server, although that would involve work on sites that don't really need it. The "bodge" is to migrate to a VM and then (as time permits) move anything that matters to a newer server. (The server has Apache 1.3, MySQL 3.23, PHP4; no further development will take place there, but also we can't just copy the sites over to a newer host and expect them to work without tweaking.)
With all that in mind, minimising my tinkering time matters, but also downtime of the server affects other (less important!) people than me.
Update: Overnight I left the drive imaging, and the image failed as it couldn't access parts of the disk. This makes it more important to get this done, and rules out one of the method of doing it. So my tinkering time might be about to increase regardless...
Since I do have standard /boot and / partitions I think I'll try the basic install and then rsync / as suggested. Or else just install a standard RH9 LAMP setup and migrate the sites (ie a new server but sticking with old PHP/Apache/MySQL versions). I've just remembered that yum is broken on this server so a fresh install does seem best.