I have an old (but still in use) RH9 system I want to migrate to a virtual machine. One of the main reasons for doing this will be performance: a database query on an internal website which is used regularly is taking 15s on the old hardware, where the same query on the same database on a virtual machine takes well under a second...
The server is only used internally but all the same I want to minimise downtime. The "normal" method I'd use would be to shut down the hardware, take an image of the drive, restore it into a virtual machine, boot it, fix any problems (eg driver issues) as necessary. Depending how long that last step takes this could mean the system is offline for quite a while.
I could create an empty VM, boot it to a live CD, and rsync the whole OS data from the old system to the new one, but I'm not sure which rsync options I'd need to use to make sure the user permissions copied across correctly (I assume that since /etc/passwd will be copied across it doesn't matter that the users don't exist initially), then make the VM's disk bootable, and take it from there; all of that I could do with the other system online and then fix the problems in the VM with the old system still online, ready to re-rsync later to catch up with any changes after shutting down all services like the database etc. But (a) I'm not sure how to make the VM boot and (b) I'm not sure what else would go wrong.
Any suggestions?
On Wed, 2008-01-02 at 11:50 +0000, Mark Rogers wrote:
The server is only used internally but all the same I want to minimise downtime. The "normal" method I'd use would be to shut down the hardware, take an image of the drive, restore it into a virtual machine, boot it, fix any problems (eg driver issues) as necessary. Depending how long that last step takes this could mean the system is offline for quite a while.
It is a pity that vmware converter is a. only currently offering experimental support for linux source machines b. only currently works in offline mode on linux source machines and c. offline mode is afaik only available in the paid for version. Otherwise it would be the perfect tool for the job :)
I could create an empty VM, boot it to a live CD, and rsync the whole OS data from the old system to the new one, but I'm not sure which rsync options I'd need to use to make sure the user permissions copied across correctly (I assume that since /etc/passwd will be copied across it doesn't matter that the users don't exist initially), then make the VM's disk bootable, and take it from there; all of that I could do with the other system online and then fix the problems in the VM with the old system still online, ready to re-rsync later to catch up with any changes after shutting down all services like the database etc. But (a) I'm not sure how to make the VM boot and (b) I'm not sure what else would go wrong.
You could do that and then fix grub/lilo which *should* give you a bootable system. But personally if rebuilding the system from scratch isn't an option then I would do a minimal installation of RH9 and get it up to the same versions with respect to kernel updates and then do as you say with rsync but avoiding /boot.
I have produced perfectly functional DR twins of legacy unix and linux boxes by this method where modifications and customisation over time has been left undocumented, to prove that even without the documentation we could produce a complete and functional system from the backup tapes (which were archiving everything). However I would strongly consider building the system from scratch in your case as although you are trying to minimise downtime you can spend time getting a mirror system built before you migrate the data and this would equip you better with the knowledge to recreate it on a newer OS later on
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
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.
-
Mark Rogers -
Wayne Stallwood