Hi all,
I've done some research on these forums and have read the section in Installation and Upgrading pdf about "remote and scripted installations", but I have a situation that has not really been addressed (or I missed it if it is already in these forums).
I understand how to create a basic installation script using kickstart from an ESX server installation, but I am trying to gather some info about disaster recovery and proper steps to take. It has been recommended by many in these forums to use a scripted installation for quick turnaround of an ESX host rebuild and I think this is the route I would like to take as well.
Here is the problem...I was not a part of my environments original build of our ESX servers. I have no idea what the different configurations are and was wondering if there was a quick way to take an ALREADY EXISTING ESX host and make a complete script that will include everything like partition sizes, port groups, NIC setup, switch info...everything. I would like it so detailed that if one of my ESX servers crashed, I would be able to run this script and have the host back up and running as it was (except of course any data that would need to be restored).
Can anyone tell me:
1- If this is possible
2- If it is possible, where can I go to read more about this
To clarify, I am asking if there is a command or something else I can run that will gather this info into a script for me...or if I have to just use the initial kickstart script and manually add all my unique settings in manually.
The most simple way to do this is to rebuild the hosts that were not built with scripted installations. If you have vMotion running this should be trivially simple. If you don't have vMotion this could take some work, but then again probably less work than creating all of the scripted installations and then hoping that they all work on disaster day.
Agreed. Come up with your best practice design & implement it with an automated install. You can easily have many servers installing from the same PXE, nfs, USB locations with a specific config for each.
Basically all you need to document is how your networking is configured and provide the same portgroup names to the VMs on the expected vlans. Of course you need to customize the firewall and what other packages are installed & configured depending on your operations guidelines, but to keep the vms turning it comes down to access to shared storage and networking.
Couple of things...
a file in /root called "anaconda-ks.cfg" contains the installation parameters of the ESX host. This is also true for any Linux system. You can use that as a base.
run vm-support or export the diagnostic data from within VC. This will give you a tgz file for each ESX host with ANYTHING you need to know about it.
Use KS_QuickConfig from http://www.xtravirt.com/ to doctor up your kickstart scripts. There are a few samples on http://www.rtfm-ed.co.uk/?page_id=366
Finally, use Ultimate Deployment Appliance on a VMWare Server, Workstation or Player - http://www.ultimatedeployment.org/
Good luck!
Hello,
the /root/anaconda-ks.cfg file generally does not contain the VMware specific settings but will contain everything else.
The VMware Specific settings are pretty easy to add using one of the listed tools.
Best regards,
Edward
Thanks all,
this is good information. So, I have two ESX servers in my cluster that utilize both DRS and HA. Would a good practice be to create two scripts? One for each server and just have them ready in case of OS crash or something of the like?
Yes, typically I think most folks will have one kickstart per host. It's pretty easy to create a menu to choose between host configs. To create a new host you copy the config that's most similar, edit that, and update the menu.
Thanks all,
this is good information. So, I have two ESX servers
in my cluster that utilize both DRS and HA. Would a
good practice be to create two scripts? One for each
server and just have them ready in case of OS crash
or something of the like?
Why not move all of the VMs to one of the ESX servers, rebuild that server, move the VMs to the newly rebuilt server and rebuild the other server. It will also give you a chance to patch and/or upgrade to 3.0.2