Recently (don’t ask me why, seriously) I had to migrate a physical Redhat 9 server to a virtualized platform (KVM).
Yes, ideally one rebuilds the deprecated server anew, but due to time-constraints and a number of other issues that wasn’t a possibility. Unfortunately, sometimes you just have no choice but to kick the can down the street.
The migration from physical to virtual is simple – create the virtual guest, create an LVM logical volume for the disk, format it and rsync the contents from the physical to the virtual drive. After that, install grub on the guest and voila – you’re done.
Keeping some consistency (although unnecessary), I went with an EXT3 filesystem on the “new” guest. Unfortunately, I came across the following snags:
- The inode size used in Redhat 9 is 128 bytes, but modern systems (ie: the host I formatted the partitions from ) use 256 bytes.
- There’s a number of attributes that weren’t present in Redhat 9.
Here’s the output of tune2fs on a Redhat 9 EXT3 partition:
# tune2fs -l /dev/hda1
tune2fs 1.32 (09-Nov-2002)
Filesystem volume name: /boot
Last mounted on: <not available>
Filesystem UUID: 9e6fa853-18bc-4c08-bb7c-51c74e0c11ae
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 8032
Block count: 32096
Reserved block count: 1604
Free blocks: 17451
Free inodes: 7982
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2008
Inode blocks per group: 251
Filesystem created: Tue Oct 26 12:48:49 2010
Last mount time: Thu Oct 28 15:58:10 2010
Last write time: Thu Oct 28 15:58:10 2010
Mount count: 11
Maximum mount count: 28
Last checked: Tue Oct 26 12:48:49 2010
Check interval: 15552000 (6 months)
Next check after: Sun Apr 24 12:48:49 2011
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 8
Journal device: 0x0000
First orphan inode: 0
The following is output from a Centos 5.5 formatted EXT3 filesystem:
# tune2fs -l /dev/mapper/VolGroup00-LogVol00
tune2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 7384cac8-b098-4c85-be6d-643443ae3d3d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6809088
Block count: 6807552
Reserved block count: 340377
Free blocks: 6204875
Free inodes: 6752521
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 32736
Inode blocks per group: 1023
Filesystem created: Thu Oct 28 13:31:34 2010
Last mount time: Thu Oct 28 17:43:57 2010
Last write time: Thu Oct 28 17:43:57 2010
Mount count: 2
Maximum mount count: -1
Last checked: Thu Oct 28 13:31:34 2010
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 42eb54b3-8f66-4aef-8578-388c9863423c
Journal backup: inode blocks
As you can see, some basic features and the inode size has changed in 10+ years. The solution: format the “new” guest to match the specs of the old:
#mke2fs -O has_journal,filetype,sparse_super,^ext_attr,^resize_inode,^dir_index \
-I 128 -j /dev/sda$disk
And that’s it- rysnc the files over to the guest VM, install grub, verify your fstab is good, and voila – you’ve transferred a physical server to a virtual one.