IMO, cloning systems is a hacked-up way to approach installing servers (same with images for installing workstations). It's the quick and dirty way to do things, but doing things the dirty way often leaves a mess you need to clean up. And rarely if ever can it handle upgrades to newer versions gracefully.
Using a combination of kickstart and Puppet ensures that you always know the configuration of a system, instead of having some black box the guy in the next building did some magic to get working and now you just clone it 100 times without knowing *how* it's working. These days, a "proper" kickstart solution should be considered: Kickstart does your OS install and gets a puppet agent installed. Everything after that should be done by puppet. There shouldn't be much in the %post script doing config changes beyond what you need to get puppet working. If you put your effort into something like Puppet, at least you could clone a RHEL6 clean install and then let Puppet configure the rest, so you wouldn't necessarily need the kickstart. ❧ Brian Mathis On Thu, Jun 28, 2012 at 12:05 PM, Mathew Snyder <[email protected]> wrote: > Our virtual platform is currently hosted with a company that strangely still > uses ESXi 4.0. We have the ability to install RHEL5 from their supplied > templates and can make copies of existing VMs with customization such as > hostname and IPs; things one would expect a robust hypervisor to support. > Unfortunately, this support is not extended to RHEL6. We can make identical > copies and then modify them to the configuration we need, but the > modifications aren't made during the copy. > > Needless to say, this adds overhead and time to the creation of new VMs. > It's faster to just create blank VMs and kickstart them. Our kickstart > solution is only half of what it could be, though. > > We are in the planning stages of a move to a more dedicated stack of > hardware with the wonderful upgrade to...wait for it...ESXi 4.1. I don't > have a great deal of VMware experience, but I suspect that a minor version > number isn't going to introduce the functionality that we are looking for. > Am I correct in this assumption? > > The deployment of a proper kickstart solution rests in the knowledge I'm > provided here. I don't want to spend time designing a solution that will > never be used if 4.1 supports proper RHEL6 VM copies. However, if it > doesn't, I need to get in gear and get that solution in place sooner rather > than later. > > -Mathew _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
