What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
To create a linked clone in Virt-Manager, make a new qcow2 volume, choose the existing qcow2 image as its Backing Store, and then create a virtual machine by importing that new child volume. The child stores changes separately while reading unchanged blocks from the base image, so it starts quickly and avoids an immediate full duplicate. The trade-off is permanent: every child depends on the backing file being available, unchanged, and moved or backed up with it.
The labels below follow a recent graphical walkthrough. Virt-Manager’s exact menus can vary by release and distribution, so use the equivalent storage-volume controls if your installation names a control differently.
As an Amazon Associate I earn from qualifying purchases.
What a linked clone is—and what it is not
A linked clone is a virtual disk with a backing image. In this procedure, the child and the base are qcow2 images. The child begins with metadata that points to the base and records only new or changed blocks. Reads for unchanged data come from the base; writes go to the child’s own allocation. The result is a lightweight delta disk rather than a second, immediately complete copy.
“Linked clone” describes the disk relationship, not a special guest operating-system feature. You can use the child volume for a new VM, but the VM still needs its own name, virtual hardware, network settings, and guest configuration. The amount of space saved is workload-dependent: a guest that writes many blocks will make the child grow, and storage format and host configuration also affect the result. There is no fixed percentage that can be promised in advance.
#1 Best Overall
Do not confuse it with virt-clone
The virt-clone utility is a separate command-line workflow for cloning an existing inactive guest. It copies disk images and defines another guest with new identity details. Creating a qcow2 volume with a backing store creates a child disk; it does not, by itself, perform all of the identity and guest-definition work that virt-clone handles.
Checks to complete before opening the wizard
Confirm the connection and pool
Virt-Manager manages guests through libvirt. Open the connection that owns the VM and make sure it can see both the destination storage pool and the existing base volume. A pool is the source of volumes allocated to VM disks. If the base belongs to a different libvirt connection, an inaccessible directory, or a pool that is not active, it may not appear in the browser and the child cannot resolve its backing path.
Identify a suitable base image
Use the exact qcow2 image you intend to share. Record its path and filename before creating children, and check that it opens through the same connection you will use for the new VM. Treat the image as a template: do not boot the master directly for ordinary work and do not allow routine guests to write to it. Keeping the template unchanged preserves the assumptions made by every child.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Plan room for growth
A linked child is small only at creation. Every guest write that differs from the base can allocate space in the child. Check free space in the destination pool, and leave headroom for the guest’s expected changes, package updates, logs, and temporary files. The child’s apparent virtual capacity and its current host allocation are different concepts; monitor the host pool rather than relying on the initial file size.
Plan the dependency and backup set
Back up the base and all dependent children as one chain. A child without its base is not a self-contained disk, and restoring only the child can leave a VM unbootable or missing data. Keep a written inventory of which children use which base, especially if several pools or hosts are involved. Protect the base from accidental edits, renames, and deletion.
How to create the linked volume in Virt-Manager
The following sequence uses the storage interface first, then imports the resulting child disk into a new VM.
- Open Connection Details. In Virt-Manager, select the target libvirt connection and open Connection Details.
- Open Storage. Select the Storage section. You should see the pools available through that connection and the volumes each pool contains.
- Select the destination pool. Choose the pool in which the child volume should live. Use a pool with enough free space for the child’s future growth and with a path that the libvirt service can access.
- Start a new volume. Use the pool’s control to create a new storage volume. Enter a distinct name so operators can tell the child from the template and from other guests.
- Choose qcow2. Set the new volume’s format to
qcow2. The GUI example uses qcow2 for both the child and the base, which keeps the backing relationship explicit. - Expand Backing Store. Open the Backing Store section of the volume dialog. Browse to the existing base qcow2 volume, select it, and verify that the displayed path is the intended template rather than another child.
- Finish the volume. Confirm the new volume. Virt-Manager creates the child metadata and its relationship to the selected backing image; it does not copy every block from the base at this point.
- Recheck the pool listing. Return to the pool’s volume list and confirm that the new child appears with the name and format you chose. If it is missing, stop here and resolve the pool or permission problem before defining a VM.
Create a VM that uses the child disk
- Start a new virtual machine. Use Virt-Manager’s new-VM workflow for the same libvirt connection.
- Select “Import existing disk image.” Choose the import option rather than an installation-media workflow. This tells the wizard that the operating-system disk already exists.
- Choose the child volume. Browse to the qcow2 child you just created. Do not select the master template by mistake; importing the base would bypass the linked-clone relationship you intended.
- Provide guest details. Select the operating-system type and version that match the installed guest on the base, where the wizard asks for them. Choose CPU, memory, network, and firmware settings appropriate for that guest.
- Review before finishing. Check the VM name, disk path, network attachment, and boot firmware. A unique VM name prevents management confusion even though several guests can share one template.
- Finish and boot the child. Start the new VM only after confirming that the child volume is present and the base remains at its recorded path. The first boot should be treated as a validation of the guest and the disk chain, not as a test of the master image.
Validate the chain before putting the VM into service
Confirm that the VM points to the child
Open the VM’s hardware or disk details and verify that its disk source is the new child volume. The child should be the file attached to the VM; the base should appear only as the child’s backing relationship in the storage metadata. If the VM points directly at the base, power it off and correct the disk source before making changes.
Perform a controlled first boot
Watch the guest’s boot process and check that its expected filesystem and applications are present. A linked clone can boot normally while still being operationally unsafe if the base path is fragile, so also confirm that the host can keep the pool mounted after a restart and that the libvirt service has permission to read the base.
Rank #3
Make a harmless write test
Create a small, disposable file inside the guest, shut the guest down cleanly, and start it again. The file should persist in the child. This confirms that writes are reaching the child rather than the template. Remove the test file afterward if it is not needed.
Rules for operating a linked-clone fleet
Keep the base stable
All children expect the base image to remain readable and semantically consistent. Do not mount it read-write for routine administration, do not rename it casually, and do not replace it with an unrelated image under the same filename. If you need a new operating-system baseline, create a new template and make new children from that template instead of changing the old one underneath running guests.
Track the chain explicitly
Maintain a simple inventory containing the base path, each child path, the VM using it, and the host or pool where the files live. This matters when a pool is migrated, a VM is retired, or an administrator is asked to restore one guest. A filename alone is not enough if the same name exists in more than one pool.
Recommended Free Tools
Back up base and children together
A usable backup contains the backing image and every required child, with their paths and relationship preserved. Schedule backups around guest shutdown or an application-consistent method suitable for the workload. Test a restoration on a separate location: restore the base first, place the child where its backing reference can resolve, and then attach the child to a test VM.
Move or migrate the complete set
When transferring a linked VM to another host, copy or otherwise make available the base and child as a coordinated set. Reproduce the storage paths expected by the child, or use the destination’s volume-management tools to preserve the backing reference. Moving only the child leaves the destination without the data it needs for unchanged blocks.
Retire children carefully
Deleting a child removes that VM’s delta, but it does not make the base disposable if other children still depend on it. Before deleting a template, search your inventory for every dependent child and confirm that each guest has been converted to an independent copy or retired. Never delete a base merely because no VM currently appears to be running.
Linked child or full copy?
Both approaches are valid; the right choice depends on whether shared storage efficiency or independence is more important.
| Decision factor | Linked qcow2 child | Full disk copy |
|---|---|---|
| Initial storage use | Starts with a dependency on the base and stores the child’s changes; actual allocation grows with guest writes and the underlying storage setup. | Duplicates the disk contents, so the copy is immediately self-contained but consumes storage for the duplicated blocks. |
| Dependency | Requires the backing image to remain available and correct. | Does not require the original image after the copy is complete. |
| Backup and restore | Base, child, and relationship must be preserved together. | Each disk can be backed up and restored independently. |
| Portability | Moving the child alone is insufficient; the backing file must travel or be reachable at the expected location. | Simpler to move as one disk file. |
| Best fit | Repeated environments that share a stable, protected template. | Independent guests where operational simplicity outweighs shared storage. |
| Failure impact | A missing, changed, or damaged base can affect every dependent guest. | Damage to one copy generally stays isolated to that guest’s disk. |
A full copy is therefore not automatically “better”; it exchanges the linked chain’s storage advantage for larger, more independent disks. Choose before deployment, because converting an established fleet later requires a planned copy and validation window.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshooting common failures
The base image does not appear in Backing Store
- Confirm that you opened the correct libvirt connection and selected the pool containing the base.
- Check that the pool is active and that the libvirt service can read the directory and file.
- Verify that the base is the expected qcow2 volume and is not hidden behind a different pool definition.
- If the GUI still lacks a backing-volume control, your Virt-Manager build may not expose the libvirt capability. Use the equivalent storage-volume function available in your installation or administer the volume through libvirt’s documented backing-volume interface.
The new VM boots the template instead of the child
- Power the VM off and inspect its disk source.
- Select the child volume in the VM hardware details, not the base path.
- Check that you imported the child created in the previous steps and that similarly named volumes are not being confused.
The VM fails after the base was moved
- Restore the base to the path recorded by the child, or recreate the storage arrangement so the backing reference resolves.
- Do not “fix” the problem by creating an unrelated file with the same name; the child expects the original backing content.
- After the path is repaired, boot a test VM and verify the guest before returning it to production use.
The pool fills unexpectedly
- Measure free space in the destination pool and the allocation of each child.
- Look for guests performing large updates, generating logs, or writing temporary data; linked disks grow as those changes accumulate.
- Keep headroom and define an operational threshold at which a child is copied into an independent disk or rebuilt from a fresh template.
A restored child will not open
- Check that the matching base image was restored, not merely a file with a similar name.
- Restore the directory layout or adjust the volume arrangement so the backing relationship resolves through the libvirt connection.
- Validate the restored chain with a disposable VM before attaching it to the original guest definition.
Version and interface differences
The Virt-Manager project’s release page lists version 5.1.0, released August 26, 2025. Distribution packages can lag behind that upstream release or carry interface changes, so your labels may differ. Look for the same concepts—connection details, storage pool, new volume, qcow2 format, and backing store—rather than assuming every dialog is identical.
Libvirt can gain storage features faster than Virt-Manager exposes them in its graphical interface. Consequently, a host may support backing-volume operations even when a particular Virt-Manager build does not show the corresponding control. This is a capability and packaging issue, not evidence that the child relationship itself is invalid. Verify the installed versions and use the storage controls your connection actually provides.
When linked clones are the right tool
Good candidates
- Training or test guests that share a stable operating-system template.
- Short-lived development environments where rapid provisioning matters and the base can be protected.
- Labs in which administrators can inventory the chain and monitor pool growth.
Choose a full copy instead when
- The VM must be moved between hosts or sites without coordinating a shared base.
- Backup operators require one-file restore units.
- The workload writes a large portion of its virtual disk, reducing the practical benefit of a delta.
- The template cannot be kept stable or the organization cannot track dependencies reliably.
Operational checklist
- Use the same libvirt connection for the pool, base, child, and VM unless you have deliberately arranged shared access.
- Keep the base qcow2 image unchanged and protected from direct guest writes.
- Give every child and VM a unique, documented name.
- Confirm free space for growth before creating the child.
- Back up and migrate the base and children as one dependency set.
- Test a child boot and a harmless write before relying on the VM.
- Recheck the interface after Virt-Manager or distribution upgrades because menu labels and exposed capabilities can change.
Final decision
Use Virt-Manager’s storage workflow when you need several guests to start from one protected qcow2 template and you can manage the resulting dependency chain. Create the child under Backing Store, import that child—not the template—into the new VM, and treat the base as part of every backup, migration, and recovery operation. If independent movement and restoration matter more than shared storage, make a full disk copy instead.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
