What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use virt-clone to make a new libvirt domain and copy or arrange its disks, then use virt-sysprep while the clone is powered off to remove guest-specific identity such as the old machine ID and SSH host keys. The two commands solve different problems: cloning changes the host-side definition, while sysprep edits files inside the guest image.
The source domain must be inactive for cloning. The selected image must remain shut down and free from other disk-editing tools while sysprep runs, because sysprep modifies that image in place.
What virt-clone changes—and what it leaves untouched
A clone has a new libvirt identity, but it initially contains the source guest’s operating-system data. That distinction explains why a newly cloned VM can still have the original hostname, static address, machine ID or SSH host keys.
| Layer | What happens during virt-clone |
What requires virt-sysprep or guest configuration |
|---|---|---|
| Libvirt domain name | A new name is assigned with --name. |
Nothing inside the guest changes automatically. |
| Libvirt UUID | The new domain receives a different host-side UUID. | The guest’s own identity files are not rewritten. |
| Virtual NIC identity | The clone can receive a new MAC address, or you can provide one explicitly. | Network-manager profiles, static addresses and policy inside the guest remain as they were. |
| Virtual disks | Disks are copied or otherwise arranged according to the storage options you select. | Files stored on those disks are initially identical to the source. |
| Machine ID and SSH host keys | Not changed. | Use sysprep operations that clear the machine ID and remove or regenerate SSH host keys. |
| Passwords, host name and users | Not changed. | Reconfigure them after sysprep and the first boot. |
The virt-clone manual summarizes the boundary clearly: it “does not change anything inside the guest OS, it only duplicates disks and does host side changes.”
#1 Best Overall
Prepare the source and protect your template
Power off the source cleanly
Shut the source guest down from its operating system, then confirm in virt-manager that its state is Shut off (not paused or suspended). The cloning command requires an inactive source. Do not begin sysprep until the clone is also shut down.
Preserve a reusable source
If the source is a clean template or must remain recoverable, take a storage snapshot, copy the disk, or create a separate disk clone before running any cleanup. Sysprep edits the chosen image in place; without a snapshot or backup, its changes are not automatically reversible.
Match the libvirt connection
Run the command against the same libvirt connection that virt-manager displays. The examples use qemu:///system. If your virt-manager connection uses another URI, substitute that URI consistently so the new domain appears in the expected connection list.
Create the VM with virt-clone
With the source inactive, create a named clone and an explicit destination disk:
virt-clone --connect qemu:///system --original SOURCE --name CLONE --file /var/lib/libvirt/images/CLONE.qcow2Replace SOURCE with the existing domain name and CLONE with the new libvirt name. The --file path is the destination disk for the clone; choose a directory that the libvirt service can access and that has enough capacity for the selected copy method.
Rank #2
Let virt-clone choose names and paths
--auto-clone asks virt-clone to generate a new name and storage paths from the source definition. This is convenient for a quick copy, but an explicit --name and --file make automation, inventory and later sysprep commands easier to audit.
Check the result in virt-manager
Refresh the connection in virt-manager and verify that the new domain is listed separately from the source. Before booting, inspect its virtual disks and network interfaces. Confirm that each destination path is the one you intended and that the clone is still powered off while you prepare the guest image.
Choose storage and device behavior deliberately
The current virt-clone interface supports more than a simple full copy. Select the behavior that matches your storage backend and recovery plan.
| Need | Relevant virt-clone capability | Decision to make |
|---|---|---|
| Independent destination disk | Explicit destination files with --file |
Use a new path for every clone and verify permissions before starting it. |
| Thin or sparse destination | Sparse image creation (the default behavior can depend on the source and options) | Use sparse storage when overcommit is acceptable; monitor the backing filesystem because allocated space can grow. |
| Fully allocated destination | --nonsparse |
Choose this when you want allocation up front rather than a sparse file. |
| Fast copy on Btrfs | --reflink |
Use a Btrfs reflink where supported. It shares physical extents initially, so later writes still consume additional space. |
| Destination already exists | --preserve-data |
Allow an existing destination to be preserved only when you have verified its contents and ownership; otherwise choose a new path. |
| Selected device handling | Skip or force individual device copies | Skip devices that should remain external, or force a copy when the default would leave required data behind. |
| Predictable network identity | Explicit MAC address with --mac |
Assign a unique address from your inventory. Never reuse a MAC on two active guests. |
| Firmware variables | Separate NVRAM destination with --nvram |
Provide a new NVRAM path for guests that use UEFI variables; do not accidentally point two VMs at the same variable store. |
Use virt-clone --help on the installed version to confirm the exact option spelling and device selectors available on your host. The important distinction is whether storage is fully copied, reflinked, preserved or skipped; that choice affects isolation and recovery.
Understand identity before the first boot
After cloning, two identities coexist. Libvirt knows the new domain by its new name and UUID, and its virtual NIC can have a different MAC. The guest filesystem, however, still contains the source’s machine ID, host name, network profiles, user accounts, passwords and SSH server keys until you change them.
- Host-side identity: domain name, libvirt UUID, virtual hardware definition and MAC address.
- Guest-side identity: machine ID, host name, static IP configuration, DHCP client state, SSH host keys, users, passwords, certificates and application-specific identifiers.
This is why changing only the name in virt-manager is not sufficient for a fleet deployment. The clone may boot successfully yet appear to monitoring, DHCP, configuration management or SSH clients as the original machine.
Generalize the clone with virt-sysprep
Inspect operations supported by your build
List the operations before choosing what to remove:
virt-sysprep --list-operationsThe list is version-dependent. Select only the cleanup operations appropriate for your image, especially those that clear the old machine ID and remove or regenerate SSH host keys. Deliberately selecting operations is safer and more repeatable than relying on an implicit default set.
Run sysprep by domain name
If the clone is registered with libvirt and powered off, target it directly:
virt-sysprep -d CLONE --enable machine-id,ssh-hostkeysThe operation names shown above are the conventional names for machine-ID and SSH-host-key cleanup. If --list-operations on your installed version presents different names, use the names it reports. You can select a larger, explicit set with --enable or --operations; do not enable an operation merely because it exists if its data is needed by your deployment.
Run sysprep against an image path
You can work on the disk directly instead of resolving a libvirt domain:
virt-sysprep -a /var/lib/libvirt/images/CLONE.qcow2 --operations machine-id,ssh-hostkeysUse either the domain form (-d CLONE) or the image form (-a), not both for the same run. In either case, keep the guest shut down and ensure no other process is editing or mounting the image for writing. The tool’s documented behavior is explicit: “virt-sysprep modifies the guest or disk image in place.”
Decide what not to remove
Sysprep is a generalization tool, not a universal reset button. Review the operation list and preserve application data, licensing files, certificates or custom provisioning state that your next deployment requires. If you are building a golden image, record the exact operation list in your provisioning script so subsequent clones receive the same treatment.
Boot and configure the clone
- Start the clone from virt-manager only after sysprep completes successfully.
- Set the intended host name inside the guest.
- Apply the deployment’s network policy. Remove or replace static addresses and confirm the guest sees the clone’s MAC address.
- Create or rotate users, passwords, certificates and application secrets as required by your environment.
- Verify that a new machine ID is generated on boot and that SSH presents a new host key. From an administration workstation, remove any stale known-host entry for the test address before reconnecting.
- Check DHCP, DNS, monitoring and configuration-management registration so the clone is recorded as a separate node.
These are guest-level actions; virt-manager can start and display the VM, but it does not rewrite those operating-system files for you.
Free tools Windows power users keep installed
One-click scans. No signup required.
Compare cloning approaches before choosing one
| Approach | Where identity changes occur | Storage behavior | Reversibility | Repeatability |
|---|---|---|---|---|
| virt-clone only | Libvirt host configuration | Copies or arranges disks according to selected options | Source remains intact, but the clone still contains source guest identity | High for host-side naming; insufficient for sanitized guest deployment |
| virt-clone followed by default sysprep operations | Host configuration plus a standard guest cleanup set | Same storage choices as cloning | Requires a source snapshot or backup if the selected image must be restored | Convenient, but the effective cleanup set should be reviewed for your version |
| virt-clone followed by an explicit operation list | Host configuration plus precisely selected guest files | Same storage choices as cloning | Restorable only from a preserved source or image backup | Best for scripted, repeatable templates because the operation list is documented |
| Image editing without a cloned copy | Inside the selected source image | No separate storage copy unless you make one first | Lowest; in-place edits can affect the template | Risky for production templates and concurrent workflows |
Troubleshooting common failures
“The source domain is running”
Shut it down completely and retry. A paused or suspended domain is not the same as an inactive one for cloning purposes. If virt-manager still shows a transitional state, wait for shutdown to finish and refresh the connection.
The clone appears, but it has the old IP or hostname
This is expected when only virt-clone was run. Reconfigure the guest after sysprep, replacing static network settings and the host name rather than editing only the libvirt XML.
SSH warns that the host key changed—or accepts the old key
Old SSH host keys were retained or the client has a stale known-host entry. Run the SSH-host-key cleanup operation while the clone is off, boot it to generate new keys, then remove the old client-side known-host entry for that address.
Sysprep reports that the image is in use
Power off the guest and stop any second process that has the image open for editing or writing. Concurrent disk editing can corrupt data. Check that a backup, snapshot tool or another management job is not holding the file before trying again.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The destination path already exists
Do not overwrite it blindly. Either select a new destination, or use the preserve-data behavior only after confirming that the existing file is the intended disk, has correct ownership and is safe to reuse.
The clone does not start after a storage optimization
Review whether a skipped device, reflink assumption, missing NVRAM file or inaccessible destination path changed the hardware definition. Compare the clone’s disks and firmware settings in virt-manager with the source, then correct the destination path or copy policy and retry.
A repeatable runbook for every clone
- Record the source domain, libvirt connection URI, disk paths and whether it uses UEFI NVRAM.
- Shut down the source and preserve a snapshot, backup or clean disk copy when the source is a template.
- Run
virt-clonewith an explicit new name and destination storage, adding the required MAC, reflink, sparse, device-copy and NVRAM options. - Refresh virt-manager and verify the new domain, disks, MAC address and firmware files before booting.
- Run
virt-sysprep --list-operations, choose the cleanup set, and execute sysprep against the powered-off clone. - Boot once, set guest-specific identity and network settings, rotate secrets, and verify SSH, DHCP, DNS and monitoring registration.
- Record the resulting domain name, UUID, MAC, storage paths and sysprep operation list in your deployment inventory.
Following that order keeps the clean source separate from the mutable clone, makes host and guest identity changes visible, and gives you a recoverable point before in-place guest cleanup.
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.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors
