neon_revolution
asked on
Testing Windows Server changes and updates in lab VM environment
Hi all, i am now with a company with a ESXi environment, and 2 VMs located on a Lenovo PX400 SAN. There is a fair bit of maintenance that needs to get done as it has been neglected for some time. My question is, how should i go about testing updates and changes before deployment? I have heard varying opinions on the topic, but im thinking clones of the virtual servers that i can bring up and down at will to apply updates and then test? I could use some guidance here!!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi,
maybe everything is said, but here are my thoughts :
your options are :
- vmware snapshots
- vmware clones (if you have a vcenter)
- VM backup
snapshots are pretty good to test some updates
It does not create another VM, so inside the existing one it registers the changes you make on your VM disk on a (VMDK) temp file and gives you the option to keep your changes by deleting the snapshot or cancel your changes by reverting to the VM state when you took the snapshot.
But : you cannot do it with time sensitive application as Active Directory (so a Domain Controller) or Exchange for example ; and you don't want to keep the snapshot alive a long time because it will continue to register the changes since the snapshot and will take more space on your storage until you delete it.
Nevertheless, I think snapshots are a good option if you don't have enough space to make clones and most of all if you use it fine.
Clones (space consuming) and backup/restore (time consuming) are other known good options, but different ones.
maybe everything is said, but here are my thoughts :
your options are :
- vmware snapshots
- vmware clones (if you have a vcenter)
- VM backup
snapshots are pretty good to test some updates
It does not create another VM, so inside the existing one it registers the changes you make on your VM disk on a (VMDK) temp file and gives you the option to keep your changes by deleting the snapshot or cancel your changes by reverting to the VM state when you took the snapshot.
But : you cannot do it with time sensitive application as Active Directory (so a Domain Controller) or Exchange for example ; and you don't want to keep the snapshot alive a long time because it will continue to register the changes since the snapshot and will take more space on your storage until you delete it.
Nevertheless, I think snapshots are a good option if you don't have enough space to make clones and most of all if you use it fine.
Clones (space consuming) and backup/restore (time consuming) are other known good options, but different ones.
ASKER
Andrew, thats great, thank you. And yes, we have vCenter. Another quick but maybe stupid question though, can i use the same network on an isolated vswitch? ie. 10.0.0.0 as an example?
And Spravtek, as my environment is Server 2012 and Exchange 2013 (on separate vms), it looks like snapshotting wont work for me.
And Spravtek, as my environment is Server 2012 and Exchange 2013 (on separate vms), it looks like snapshotting wont work for me.
Yes, you can use the same network, on an isolated vSwitch (just make sure, there are no physical uplinks to a live network!)
ASKER
Marked as answered. Thanks for all the help guys, and kudos to Andrew!
Hey no problems...
Just make sure that if you want to upgrade something that exists out of multiple technologies (eg, a web server backed with a sql server) you clone both machines, pretty normal stuff, but sometimes people forget :-)
You'd put the cloned machines on a separate network, or for example, a non-connected vswitch (as in no physical nic), so that you won't interrupt your production environment by bringing up a similar server as what is running.
Now, you could keep these clones, no need to destroy them each time (if your resources allow for this of course). This way you'll always have an environment that is a copy of your production, ready to test new things.
Another thing you can do, is take a snapshot before the upgrade and roll-back if something isn't working, or remove the snapshot if everything seems to be working, but this is also not without risk and not always applicable ...