Now that we have moved HyperCore v5 to General Availability, let’s dive into some of the new features that are now available.
I write about these features together because they rely on the same underlying awesomeness built into the SCRIBE storage layer (Scale Computing Reliable Independent Block Engine). SCRIBE employs an Allocate-on-Write technique for snapshotting data.
Allocate-on-Write explained: At the time of a snapshot, SCRIBE updates the metadata to mark the blocks as being referenced by the snapshot (no change to the underlying data, so near instant). Then as changes to the snapshotted data are written, SCRIBE allocates new space within the cluster, writes the data and then updates the metadata of the original data. This eliminates the overhead penalty of the three step process (read, rewrite, then write) normally associated with a Copy-on-Write approach to snapshots.
To restore a snapshot, you simply clone it. This creates an immediately bootable, “thin” clone of the VM, meaning that you can instantly spin it up and consume no more space than the original VM. The unique blocks are tracked for each clone, so this is extremely space efficient. Whether it is a single VM or 100+ clones of that VM, the storage is thinly provisioned and only consumes the space of the original VM until you begin making changes to the individual VMs.
Cloning from a Template
We find that many users make template VMs. They take a Windows VM, customize it for their business with their specific tool set, etc., patch it and then sys prep it (Windows tool for preparing a master Windows VM to shorten the setup with just user specific settings going forward). When it comes time to spin up a new VM, they can then clone that template VM and have an immediately bootable clone ready to go. And going back to the “thin” clone concept…the common OS blocks are only stored once among all of the cloned VMs.
Cloning for Test/Dev
Another great use of the cloning technology is for testing changes to your production VMs in an isolated environment. Users take advantage of this for testing patches/making changes by cloning their running VMs (yes you can clone a running VM) and booting them in a “lab” network by either assigning a specific lab related VLAN tag or by disconnecting the NIC ahead of booting up the VM. Then they can apply and test out changes to their VMs knowing that there will be no impact to their production environment.
In the videos below, we demonstrate these features in more detail. Please let us know if there are any questions we can answer about this new functionality. Look for more updates related to the other new features coming soon to a blog post near you.
How to take a snapshot on HC3
How to clone a VM on HC3
Please complete the form below and someone from Scale Computing will be in contact with you within 24hrs.×