0

I have ESX free (most recent version 5.X) installed on a standalone server with an internal datastore in a RAID 5 setup. The VMs will be Windows mostly with some Linux and will be dedicated to performing Software builds using Visual Studio and GCC respectively.

Sometimes a branch VM will need to be created, for instance when a certain build requires an SDK update, we will need to have a snapshot of all revisions of the SDK/machine state combination. Sometimes we will need to be able to revert to a VM state as of a particular SDK version. Snapshots would be acceptable for this, except for the fact that we will need to revert a VM to a snapshot, AND keep a running version of the current VM/SDK state, so essentially creating a clone VM for each "snapshot"/SDK version that can be run at the same time as the original VM. At any given time we should not need any more than 2 versions of any VM running at the same time, but at least one of the 2 would need to have a snapshot tree of all the different versions of the SDK, so that one VM is always at the most recent state, and the other one can be brought to any historic state for the purpose of rebuilding an old software package if need be.

What is the best practice here with the time it takes to snapshot/revert to a specific VM state being a factor?

2 Answers2

2

You really don't want to keep snapshots around for long periods of time. After a certain point, your snapshot becomes so large that your performance goes into the sewers and you can't get anything done. I'm not entirely sure a "best practice" question like this is appropriate for this site, but were I in this situation, I would simply create a clone VM for each new SDK required rather than mucking with snapshots. Delete the VM when you decide to no longer support that SDK version.

John
  • 9,070
  • 1
  • 29
  • 34
  • I used the term snapshot as kind of a placeholder for any potential solution. Cloning is a perfectly acceptable answer to the question, but then I ask: Is the best move then to simply power down the VM, and copy the vmx and vmdk files to a new folder in the datastore, then create a new "I copied it" VM from that one? –  Jul 19 '13 at 14:30
  • No. Use VMware's cloning functionality. Just copying the files like that could lead to duplicate data. Most of that should be mitigated by answering "I copied it" to the question you get asked, but I wouldn't trust that method in my environment. – John Jul 19 '13 at 14:34
  • Does that cloning functionality exist in ESX free without a vCenter server? –  Jul 19 '13 at 14:41
  • No. Cloning and templates are only supported in licensed ESXi installations. You can copy the VM folders and create manual copies that way, but as John mentioned, you can run into issues with duplicate SIDs, IP conflicts, etc. Be careful. – Jim G. Jul 19 '13 at 14:44
  • It should. I don't really know since I've never used ESX free, but it should be avialable in the GUI, whether you're going to a vCenter server or directly to the ESX host. – John Jul 19 '13 at 14:44
  • I sit corrected, Jim. – John Jul 19 '13 at 14:45
  • OK thanks. I dont think I have too much to worry about with SIDs as there is just going to be one local user on these VMs, and they won't be bound to AD. –  Jul 19 '13 at 14:47
0

Cloning is easy with vCenter Server only. With ESXi free edition, you can clone virtual disks using vmkfstools CLI utility (check KB http://kb.vmware.com/kb/1027876). It is able to handle snapshots as well.

But then, you need to create virtual machines somehow or their VMX configuration files and to change related directives defining virtual disk location, MAC address of NIC and similar unique parameters per virtual machine (this could be possible to do with simple script).

Finally, you can import new vmx files from CLI with vim-cmd solo/registervm PATH_TO_VMX_FILE

dsmsk80
  • 5,817
  • 18
  • 22