VMware Cloud Community
kalleandersson
Contributor
Contributor
Jump to solution

Kickstart paranoia... How can I be sure it doesnt wipe my datastores?

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'

0 Kudos
1 Solution

Accepted Solutions
davidhaase
Enthusiast
Enthusiast
Jump to solution

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 --

-- Pedo mellon a minno --

View solution in original post

0 Kudos
17 Replies
mudha
Hot Shot
Hot Shot
Jump to solution

looks like upgrade through kick start is not possible

0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

That's alright, we will be doing an "install"

For upgrade you can probably use the new host update tool.

0 Kudos
mudha
Hot Shot
Hot Shot
Jump to solution

there are many ways to install 4.0 through ks check this doc and goto ESX scripted install

0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

Thanks, I've read it...

Doesn't make me feel safe though 😃

0 Kudos
davidhaase
Enthusiast
Enthusiast
Jump to solution

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 --

-- Pedo mellon a minno --
0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

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?

0 Kudos
davidhaase
Enthusiast
Enthusiast
Jump to solution

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 Smiley Wink

But keep in mind - that worked for 3.5. I didn't try it for ESX 4 yet.

-- Pedo mellon a minno --

-- Pedo mellon a minno --
kalleandersson
Contributor
Contributor
Jump to solution

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!

0 Kudos
oschistad
Enthusiast
Enthusiast
Jump to solution

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.

0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

Yes, you're right...

But the "probably quite safe" wasn't good enough for me. 😃

0 Kudos
Schorschi
Expert
Expert
Jump to solution

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?

0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

OK, I did it on a RHEL5 server.

0 Kudos
Schorschi
Expert
Expert
Jump to solution

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. Smiley Happy 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.

0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

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.

0 Kudos
BenConrad
Expert
Expert
Jump to solution

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

0 Kudos
kalleandersson
Contributor
Contributor
Jump to solution

Yes, same goes for the BL495 G5 with sata controller.

0 Kudos
admin
Immortal
Immortal
Jump to solution

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

0 Kudos