A question from Matt Vogt prompted this, where he wants to go from the BusLogic SCSI controller to the LSI Logic SAS controller. It’s actually a straightforward conversion if you have the right steps. This is based on Red Hat Enterprise Linux 3, 4, and 5, but the principle should be the same for everything. It’s basically: snapshot, change config files, change hardware.
Red Hat Enterprise Linux 6, in contrast, appears to have all the LSI Logic, parallel & SAS, drivers, as well as the paravirtual SCSI drivers, so all you need to do is shut the VM down and change the type of SCSI controller you’re using.
I always recommend trying this on a test VM before you try it on something big and important. :) As always, while I strive for 100% accuracy I assume no responsibility for this b0rking your whole setup. There are parts to this that require you to find your own information and substitute it for the example I’ve given. Please do that, don’t copy the commands by themselves. Some of them will look like they work fine… until you reboot.
Step 1: Take a snapshot of the VM in question. Did you know that VMware snapshots archive the VM hardware configuration, too?
Step 2: Copy /etc/modules.conf (for RHEL AS 3) or /etc/modprobe.conf (for RHEL 4 or 5) to /tmp, just in case.
cp /etc/modules.conf /tmp cp /etc/modprobe.conf /tmp
On RHEL hosts that have tmpwatch installed files that haven’t been accessed in 10 days will be removed from /tmp. In this case that’s my desired behavior, as you won’t need the original after the conversion operation, and I always discourage people from leaving cruft sitting around on hosts, cluttering them up. Besides, if you do need the original file after 10 days just pull it out of your file-level backups.
Step 3: Open the original file in an editor. If you’re new to Linux try to use the ‘nano’ or ‘pico’ editor, it’s more straightforward than vi. Remember to use sudo or do this as root, which will be true of all of the rest of the directions here.
sudo nano /etc/modprobe.conf
Step 4: Find the line or lines that say “alias scsi_hostadapter.” There may be more than one of them, they may have numbers, and they may not all pertain to the controller you want to replace (there may be lines for ata_piix, for example). Remove the lines pertaining to your old SCSI adapter. In Matt’s case there would be a line saying “alias scsi_hostadapter BusLogic”
Step 5: Add the correct lines to /etc/modules.conf or /etc/modprobe.conf:
RHEL AS 3, /etc/modules.conf for LSI Logic SAS:
alias scsi_hostadapter mptbase alias scsi_hostadapter1 mptscsih
RHEL 4, /etc/modprobe.conf for LSI Logic SAS:
alias scsi_hostadapter mptbase alias scsi_hostadapter1 mptscsi alias scsi_hostadapter2 mptscsih alias scsi_hostadapter3 mptfc alias scsi_hostadapter4 mptspi alias scsi_hostadapter5 mptsas
RHEL 5, /etc/modprobe.conf for LSI Logic SAS:
alias scsi_hostadapter mptbase alias scsi_hostadapter1 mptscsih alias scsi_hostadapter2 mptfc alias scsi_hostadapter3 mptspi alias scsi_hostadapter4 mptsas
Step 6: Fix the numbering so that it’s consistent. This is pertinent if you have other scsi_hostadapter lines, like for ata_piix or something. Just alter the number to be right, sequentially. Then save the file and exit the editor.
Step 7: Rebuild your initial RAM disk. The initial RAM disk is the thing that the kernel loads drivers from, so it can find the rest of the OS. We want the new drivers to be in there, too. This process is kernel-specific. First, look in /etc/grub.conf:
and note the line that says “default=”. Starting from 0, count the entries in the file for kernels (the sections start with “title”). Find the entry in the file that corresponds to your default= setting. In my case it’s default=1, so I take the second section, which looks like:
title Red Hat Enterprise Linux Server (2.6.18-194.3.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-194.3.1.el5 ro root=/dev/Volume00/LogVol00 divider=10 elevator=noop notsc initrd /initrd-2.6.18-194.3.1.el5.img
You can confirm this with the ‘uname –a’ command. The third field should be your running kernel version. Back in /etc/grub.conf, the “initrd” line will show you the file you need to update. It’s in /boot, so the file in my case is:
Confirm that the file is there using ‘ls’. Once you know the filename, issue the command:
/sbin/mkinitrd –f /boot/initrd-KERNEL_VERSION.img KERNEL_VERSION
Substitute the right string for KERNEL_VERSION. For example, in my case it’d be:
/sbin/mkinitrd -f /boot/initrd-2.6.18-194.3.1.el5.img 2.6.18-194.3.1.el5
Your kernel version might have “smp” in the name, too, like “2.4.21-63.ELsmp.” If you get any warnings from this process stop and fix them. Remember, worst case, you have a snapshot. You also have a copy of the original files in /tmp.
Step 8: Use ‘ls’ to confirm that the RAM disk has been updated recently (like right now).
$ ls -l /boot/initrd-2.4.21-63.ELsmp.img -rw-r--r-- 1 root root 553772 Sep 7 12:38 /boot/initrd-2.4.21-63.ELsmp.img
Step 9: Shut the VM down. Edit the hardware settings. Select the SCSI controller and click the ‘Change Type’ button. Pick the one you set the VM’s drivers up for. Save your changes.
Step 10: Power the VM on. Bask in the glory of a new SCSI controller. Realistically, this should be anti-climactic. :) Hopefully everything went as planned, and you don’t need to restore the snapshot.
Step 11: Remove that snapshot when you are sure everything is fine! (Thanks for the reminder, John Walsh!)
Please let me know via the comments if there are mistakes or clarifications that could be made. Like I said, I strive for accuracy, despite the continually changing world of virtualization. :)
Comments on this entry are closed.
And now the files you stored in /tmp are gone
That’s by design, at least when I do it, since RHEL hosts with tmpwatch installed will delete files in /tmp not accessed within a certain time period (which the default is 10 days, IIRC). Rather than keeping a copy of a file around forever to clutter a host, I let tmpwatch remove it automatically for me. Besides, you won’t need it again once the conversion is done, and if you do need it for some reason you should be able to get it from your file-level backups of the system, right?
Any idea how to do this on RHEL 6?
Doh! I just realized you mentioned it already. Thanks.
Thanks for this, spent two days on trying to get this done on RHEL3.