Best practice - Deploying from template/cloning

[wtfmatt]

Environment: ESX 4.1U1 / vCenter 4.1 / Cybernetics SAN storage

Scenario:  We have a sharepoint VM, it's used in our training center so after our  lead trainer has customized the site for her class, teaches the class,  she wants to be able to roll back to a base image so she doesn't need to  start completely from scratch.  I had her get the configuration to  where she wanted it, and then i cloned it to a template.  No problems  there.

Process:   She finishes class and lets me know to roll it back.  I power off the  current VM, then I 'Deploy from this template', i give it the same name  as the powered off machine,  I check to make sure everything looks right  and then i delete the previous powered off VM from disk, and most  everything is good to go from there.

Problem:  Once the new template is powered up, I notice some odd things like it  reverts back to DHCP, or a hidden vmxnet3 is now in the device manager  in addition to a new one.

Question:  What's the best way to handle this, I've tried creating a guest  customization that applies the static ip settings but upon power up it  still comes up with dhcp and a cached vmxnet vnic, but  when I created the template in the first place, there were no hidden  adapters, the ip settings were static and everything was right, so I'm not sure what I'm missing.

To  be honest, having to jump in and change the nic settings back to static  once a month isn't the end of the world, but I'd like to know if I'm  doing something wrong, or if there is a more efficient way to do what  I'm trying to do then deploying from template.

Thanks!

[chriswahl]

One option would be to not use a template, but rather get your golden image VM to a point where you are happy with it, and then power it off and make a clone for the trainer to use. The clone should be an exact copy, other than the UUID changing, without any modifications that you are experiencing from a sysprep.

The only caveat I can see here is that if the VM is part of a domain, rolling back to the golden image may cause a complication with the machine account password no longer matching the one in AD - the machine account password changes monthly (if memory serves). The resolution if this occurs is to rejoin the VM to the domain.

Another option is to perform a snapshot and then revert from the snapshot, with the same caveat as above.

[wtfmatt]

In the cloning scenario, I don't think I gain anything.  I'd rather just input the IP settings again then rejoin it to the domain, all other things being equal.

Snapshots are bad news, definitely don't want to go that route.

[chriswahl]

Why are snapshots bad news? They are only bad if abused (such as being used as a backup solution, or in conjunction with servers like domain controllers). In this case, it seems to fit the requirements nicely.

I'd suggest looking deeper as to why your specification customization is failing to assign an IP and adding phantom NICs. I've deployed quite a few VMs using a cust-spec without issue, so I know the technology works. Do you get the prompt asking you for an IP address? All of the sysprep files are loaded for the guest OS on the vCenter server? You should be able to watch the console of the newly deployed VM and see it reboot and sysprep after about 2 minutes.

Cheers.

[wtfmatt]

I just hate snapshotting.  Plus it runs a muck with our VEEAM backups if I don't stay on top of them.  Becomes too much overhead.

I'll do some more testing with my templates, it's quite possible I'm missing something obvious.

[mcowger]

I agree with Chris.  While snapshots can cause problems for certain use cases, this is the exact kind of case they are perfect for...

[wtfmatt]

I'm ok with giving snapshots another chance.

My issue previously with them, was that when i would roll back - I would always need to rejoin it to the domain even though it was snapped in a state where everything was functional.  Is there a slick way around this, or is it just the nature of the beast with snapshots?

Thanks