As said in previous articles, this series is only focused on VMware vSphere hence, VMware Horizon View is not contemplated (Linked clones are commonly used in that product).

What is a linked clone?

What can you see here?

Keanu Reaves has been linked cloned!

In the previous image, you can see 3 different characters but they share something in common…the actor!

Linked clones are the same! A linked clone is a type of clone (a copy of a virtual machine) where the parent VM shares virtual disks with their clones.

The resulting linked clone will be created from the parent’s VM snapshot and because of being a snapshot, it will have the same state that was the snapshot was taken.

When the linked clone is created, it shares his own virtual disk (.vmdk file) with the snapshot from the parent VM, this leads to some unique features:

The clone will be dependent from the parent VM because they are sharing their virtual disks. If you delete the parent’s VM snapshot, it will corrupt the clone’s virtual disk.

Even both VMs are sharing their storage, any changes performed in the clone won’t affect the parent VM and vice-versa.

The linked clone will have the exact same data as the source VM because it was created from a snapshot.

The save spacings are obvious because the clone will only write the new modifications in its own virtual disk. So, the clone’s virtual disk size will be only the amount of data that changed after it was created!

General process

Use or prepare a VM (Parent VM) that will be used as a master/parent to deploy the linked clones

Power-off the Parent VM (Recommended but not mandatory)

Perform a snapshot of the VM.

Time to create Linked clones referencing the snapshot we created previously.

Power-on the clones and customize them (apply customization specifications for example).

(Extra) Before powering-on the linked clone, perform another snapshot of the clone to use it as a rollback (if the end-user needs it).

(Extra) Power-on the clone and is ready to be delivered.

(Extra plus) If you decide to keep the linked clone for any reason, you can perform a full clone of it and it will become an independent VM!

In the next section, I will show you how to create a linked clone with PowerCLI from a Windows VM and in my case, I will use Custom Specifications within the script to launch the clone.

In this script, I am also using the OSCustomizationSpec parameter, while using the sentence to create the linked clone, to change the IP, name and join again to the domain the resultant clone. Also, I am changing the SQL instance name in my case because it’s a server with MSSQL server installed.

Once the script finished, a new linked clone is created and powered on with the name “SQL-LC1”.

We can see the amount of time that takes to create a Linked clone (5 seconds):

And now look at the storage allocated by the Linked clone (powered off), 750 MB approximately:

After the Linked clone is created and powered on, you can do whatever you want.

I had to wait some minutes (around 10 min. in my case) until the OS customization specification finish all the actions specified (power on the VM, join to the domain, reboot the VM, execute a script to update SQL instance, etc.)

Here is the “real” space allocated after the Linked clone has booted up and I logged in with a user, around 4 GB:

A look inside the Guest OS of the linked clone (new hostname, IP and has the same storage as the Parent VM:

Use cases

It’s commonly used in VDI and DEV environments but here are some examples:

Desktop Deployment

QA

Bug testing

DB server testing

File server testing

General testing

Benefits and limits

Let’s summarize which are the benefits and limits that we can find in linked clones:

Pros

Super fast cloning compared to a Full/Normal clone, it takes seconds instead of minutes to clone large VMs.

Space savings due to changes are stored in a separated disk (clone’s flat disk).

Useful for development environments or if you want to keep the clone just, perform a full clone of it!

Deploy as many linked clones as you want, they will reference the snapshot in the Parent VM hence, there is no disk chain on that (except for the snapshot you created of course) and the benefits of replicating .

Ongoing changes made in the virtual disk of the source VM don’t affect the linked clones and changes to the disk of the linked don’t affect the parent.

It can be performed with the parent VM powered on but, it will have some performance degradation and probably inconsistent data (if for example, the parent VM hosts a DB).

Cons

Recommended but not mandatory that the parent VM has to be powered off.

There is a storage/disk dependency as the linked clone is created from the parent’s VM snapshot then, if you delete that snapshot, inconsistencies will occur in the clone (and at the end you will delete it).

Performance on the destination clone will be impacted (as virtual machines are sharing storage)

To conclude

Linked clones have multiple benefits compared to full clones and it has many use cases as we saw before.

You can easily replicate the status of a VM (snapshot) and deploy linked clones to your end-users with all the benefits as for example space savings or the deployment speed.

To end this series, we will look at instant clones, another type of clone that is even faster than linked clones but, with some particularities.

Continuing with the cloning virtual machines in vSphere series, today I am going to write about the full clone, how it works and some useful information about it.

So, let’s talk about clones… but just full clones.

How does it work?

As you probably know a full clone is an exact copy of a source VM, meaning that, everything from the parent VM is copied (VM settings, disks, files, etc.).

This action can be performed if the parent VM is powered off or powered on and, if it has snapshots it will consolidate them once the clone is done.

When you clone a VM be aware that, all data will be identical so, if you power on the clone without performing any customization, probably you will have conflicts with IPs, MAC addresses, SIDs (Windows), etc.

The great thing about a full clone is that, after the cloning operations are performed the clone will be an independent copy of a virtual machine that doesn’t share anything with the parent virtual machine (we are talking about from a compute and storage perspective within vSphere).

Ways to do it

First of all, you will need VMware vCenter to do it.

There are other ways (not official) like copying all data related to the virtual machine (.vmdk and .vmx files) and then register the “new” VM with another name.

Let’s continue with the usual ways:

vSphere Web Client

You can do it through vSphere Web Client, as simple as, right-click a VM -> “Clone to Virtual Machine…” :

Once it finishes, it takes some time (depends on the storage that the source VM has allocated) but in the end, you will have your new clone.

Likely you are more familiar about deploying templates…

Deploying a template is the same as cloning but. aside from copying the same data from the parent virtual machine, vSphere lets you customize the deployed VM for creating many clones and with different configurations as you wish.

PowerCLI

Of course, you can do it with PowerCLI. These are the minimal parameters needed to perform it (Disk Storage Format parameter is optional but recommended because, by default, it will convert all disks to Thick Provision Eager Zeroed):

In the previous screenshot, you can see the minimum parameters required to perform a full clone, if you want to see more options you can check it here.

As you can see in the code, it’s similar to deploying a template, isn’t it?

Use cases

The main use case is deploying from a template, maybe we are not aware but, deploying from a template is just cloning our source VM (Master template) and then customizing it.

I saw many customers use it as a “rollback” when they have to perform a destructive task within the Guest OS. In this way, just shutting down the parent VM and powering on the clone.

If you think a snapshot can do the same as a clone well, not always… some applications don’t handle well doing a quiesced snapshot.

This is why, as a solution, you can create a full clone when the virtual machine is powered off and then, have a copy that will be consistent and without corruption.

Another use case could be to perform a full clone to use it in other environments. Although there are better ways to do this (with other products), when the Guest OS has many customizations, this can be an alternative solution of re-creating the entire virtual machine.

Benefits and limitations

The benefits of a full clone were mentioned before:

If the cloning operation is executed when the source VM is powered off, it can be used as a rollback in many cases (there are better options like a VM backup but, it can help a lot).

Creation of an independent VM that shares nothing with the source VM.

Used in templates, so, they are very useful!

These are some limitations instead of disadvantages that we can find:

It takes some time to create a full clone (it depends on the allocated storage) as it has to copy all storage from the source VM.

It can only be performed with VMware vCenter (there are other ways as I explained before but they are not official).

If done when the VM is powered on, it has an impact on the source VM that can be noticed by the business so, isn’t the best option to do it while the virtual machine is in running.

Conclusion

To sum up, a full clone is a great way to have an identical copy of another VM to use it as a permanent virtual machine once you configure it accordingly.

As said before, is the same as deploying a template because you are just cloning a VM (deploying a template) and then customizing it.

It usually takes some minutes to finish the clone (depending on the storage allocated in the parent VM), this is why there are other ways to deploy clones in a faster way (on the next posts!).