Hi guys,
I'm setting up a kickstart environment for our ESX 3.5 to ESX 4 migration.
My kickstart script is fine and tested to be OK on one server without san connectivity.
My question is...
How can I be sure the kickstart does not wipe my datastores? I know therecommendation is to pull the fibre cables out when doing a re-install.
But this is not practical for us and we might as well revert to manual reinstall or if we need to mess around with the san infrastructre.
We want to do a complete re-install to make sure all hosts are configured the same way.
Here's the "part" partof our kickstart script. Any help much appreciated, thanks!
I need the overwritevmfs since there is a local vmfs on each esx. Nothing worth saving here.
bootloader --location=mbr --driveorder=cciss/c0d0
clearpart --overwritevmfs --drives=cciss/c0d0
part /boot --fstype=ext3 --size=1100 --ondisk=cciss/c0d0
part none --fstype=vmkcore --size=110 --ondisk=cciss/c0d0
part local --fstype=vmfs3 --size=8764 --grow --ondisk=cciss/c0d0
virtualdisk esxconsole --size=7764 --onvmfs=local
part swap --fstype=swap --size=760 --onvirtualdisk='esxconsole'
part /var/log --fstype=ext3 --size=2000 --onvirtualdisk='esxconsole'
part / --fstype=ext3 --size=5000 --grow --onvirtualdisk='esxconsole'
One way could be to remove the SAN drivers from the initrd.img and rebuild it. That worked for me with ESX 3.5.
Maybe this will help : http://lubatti.eu/index.php/lang-en/tipsandtricks/1-esx/3-stoploosingyourvmfs
-- Pedo mellon a minno --
looks like upgrade through kick start is not possible
That's alright, we will be doing an "install"
For upgrade you can probably use the new host update tool.
Thanks, I've read it...
Doesn't make me feel safe though 😃
One way could be to remove the SAN drivers from the initrd.img and rebuild it. That worked for me with ESX 3.5.
Maybe this will help : http://lubatti.eu/index.php/lang-en/tipsandtricks/1-esx/3-stoploosingyourvmfs
-- Pedo mellon a minno --
Ah, nice! Thanks, I'll try it out.
There is an option to disable the cards in BIOS as well.
Could there be some configuration that the installer normally would do that we'll loose if we disable the cards or the kernel modules?
AfaIk this shouldn't be a problem. After the install process the host will start with another (installed) initrd that contains the drivers. So the HBAs should be recognized during boottime. I would try the rebuild-initrd-method because I don't have to edit any BIOS settings during deployment process. And that is what I call an unattended installation
But keep in mind - that worked for 3.5. I didn't try it for ESX 4 yet.
-- Pedo mellon a minno --
Alright... I followed your Howto... I guess it's a bit different in ESX4.
I couldn't mount the initrd through loopback, it wouldn't recognise the filesystem. It's a cpio file.
So basically here's how to remove the qla och lpfc drivers:
Suppose your initrd is in /tftpboot/linux.install/esx-4.0.0
mkdir /tmp/workdir
cp /tftpboot/linux.install/esx-4.0.0/initrd.img /tmp/workdir
cd /tmp/workdir
mv initrd.img initrd.gz
gunzip initrd.gz
cpio -ivh < initrd
rm initrd
rm ./usr/share/hwdata/pciids/qla* ./usr/share/hwdata/pciids/lpfc* ./usr/lib/vmware/vmkmod/qla* ./usr/lib/vmware/vmkmod/qla*
find ./ |cpio -H newc -o > ../initrd
cd ..
gzip initrd
mv initrd.gz initrd.img
cp initrd.img /tftpboot/linux.install/esx-4.0.0/
Thank you very much for your help, I hope others will benefit!
Actually, you are probably quite safe as long as you are using HP SmartArray controllers for the local disk. SAN-attached disks will never show up as a /dev/cciss device, so using those in your kickstart file should be safe.
Yes, you're right...
But the "probably quite safe" wasn't good enough for me. 😃
I tried these steps and they did not seem to work 100%, my initrd.img loads, bootstrap executes, but then I get a /dev/root error? Double checking, I realized when I did the steps above, on a ESX 4 classic host, cpio -ivh did not work but cpio -iv did. On ESX 4, h option does not appear to be supported?
OK, I did it on a RHEL5 server.
Got it working! Using cpio -ivd, on ESX 4, not cpio -ivh, worked for me. Other than that minor change, the original procedure is fine. In my case I needed to add files not remove, we add DMI decode tools to an additional directory in initrd.img, so that our pre and post scripts in kickstart can query additional hardware information not otherwise easy to get.
Good to hear. Thanks for posting!
May I ask what information you're fetching from dmidecode annd how you're using it?
Can this be used to identify which server we're currently installing?
I was faced with another tasks a few months ago when installing RHEL5 on a big number of new servers.
At that time I used the HP PSP tools to fetch what ILO address the server has to identify which server it is and use this information to set specific settings for the server.
The ILO address is set from the bladechassis and can the used to identify where the server is placed physically, switchports, etc.
fyi, when installing 3.5 U4 on a HP G6 blade with a P410i the controller shows up as /dev/sda. /dev/cciss is no longer used by the driver that supports this controller. Not sure how it is in 4.0 but I'd guess it's also /dev/sda for the P410i.
Ben
Yes, same goes for the BL495 G5 with sata controller.
Hi kalleanderson,
You can use the various options available with clearpart --firstdisk option like:
clearpart --firstdisk=local --overwritevmfs (This will wipe out the first local disk and not touch your remote disks)
clearpart --firstdisk="mptsas" --overwritevmfs (This is the systemdriver for my local controller, meaning the controller handling local disks, so this will not touch the remote disks)
clerapart --firstdisk="mptsas,qla2xxx" --overwritevmfs (Here it will give preference to the harddisk associated with the driver mptsas, if it is not found, it will check the luns associated with qla2xxx.)
Many examples can be found in the Installation Guide.
Hope this helps.
Thanks