I totally agree. However, I'm in a position of dealing with perceived efficiency by the people who spend the money. I prefer to leave the build to a kickstart server than copy/customize VMs. Especially after the effort I've gone through to write scripts for our post-installation configuration.
Puppet is already in our sights. We have been tossing about the idea since we are dealing with multiple projects with unique requirements and overzealous admins who seem to think they know more about how our configuration should look than we do. It simply hasn't reached the point of installing a proof-of-concept yet. I will say that copying the RHEL5 VMs that are supported has never sat well with me and has often left a bad taste in my mouth. Ensuring that these are properly configured even though they should already be is more of a PITA than it's worth. At this point I'm tempted to just use as gospel the response a friend provided: " I'm 99% sure you have to go to vSphere 5 to get 'full' RHEL6 support." At this point I'm simply doing due diligence. -Mathew "When you do things right, people won't be sure you've done anything at all." - God; Futurama On Thu, Jun 28, 2012 at 12:52 PM, Brian Mathis < [email protected]> wrote: > 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/ >
_______________________________________________ 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/
