KVM virt-clone while the VM is running

Question

Is it possible to clone a running kvm machine without tools like virt-clone?

They already have the original vm in production, I cannot shut it down. If I don't care about temporary data corruption (what an initial fsck can fix) on the clone, can I just cp the qcow image file to a new name, create a new vm definition which uses that disk and start the machine up?

virt-clone --original slesp4 --name newsp4 ERROR Domain with devices to clone must be paused or shutoff. — c4f4t0r, Mar 02 '15 at 14:32
I know that already, the documentation clearly states that for virt clone the machine needs to be stopped (which is not an option in my case). — zino, Mar 02 '15 at 14:41
`virt-clone` is also allowed after `virsh suspend`; perhaps, that won't count as a real shutdown for you. — imz -- Ivan Zakharyaschev, Aug 01 '17 at 14:42

score 1 · Answer 1 · answered Mar 02 '15 at 16:08

1

If you don't care about in-memory data, you can snapshot the backing device and take a copy of that snapshot.

This of course require a storage pool with snapshot support (mostly LVM or ZFS, as BTRFS is abysmal slow for virtual machines storage).

answered Mar 02 '15 at 16:08

shodanshok

44,038
6
98
162

Or copy the file if the storage is file based – Christopher Perrin Mar 02 '15 at 16:11
No, you can't do that without snapshot. The problem is that while you are coping the file-based disk image, the virtual machine will probably write to the same disk, giving serious consistency problems. With snapshots, you can "freeze" the disk image / volume and copy that frozen image, without consistency issues. – shodanshok Mar 02 '15 at 16:15
You can have snapshots without filesystem support or LVM - http://www.r1soft.com/free-tool-linux-hot-copy albeit it explicitly is listing KVM AS incompatible. But wouldn't it be a much more elegant solution to just [create a VM snapshot](http://wiki.qemu.org/Documentation/CreateSnapshot) instead? – the-wabbit Mar 20 '15 at 20:43
Interesting. Anyway, I would not risk data integrity and system stability installing a 3rd part module in a production server, especially considering how that module install itself in the uber important VFS layer. – shodanshok Mar 21 '15 at 07:03
I like this solution. I would possibly add that you could momentarily remount filesystems as read-only on the server while taking the snapshot, then remount as rw after the snapshot is taken, though depending on the service this might break the "I can't shut it down" rule. – Alex Berry Mar 10 '17 at 12:16

score 0 · Answer 2 · answered Aug 03 '20 at 08:51

I had a working vm. While in it I have ssh'ed to KVM base machine and copied its backing disk and snapshot to a nvme drive using cp -ar. I have also formatted and partitioned mentioned nvme before copying ... Then used

virsh edit mykvm

changed the id and the disk locations and the name ...

and shutdown my machine and rebooted the new one. Only thing gone were open windows and chrome session ...

It seems to be working unless you are writing some system or application files ...

I wont use this ofcourse. I will experiment on it and after experimentation I will implement results to original file.

However If I ever had to use it as a main OS snapshot. I would simply do a filesystem check and then system files check (sha1sum) or would use any built in commands to check system files.

score 0 · Answer 3 · answered Nov 29 '21 at 13:38

When the guest agent is installed and your disk image has qcow2 format, you can also try:

Create disk snapshots:
virsh snapshot-create-as ${vm} backup --disk-only --atomic --no-metadata --quiesce.
Copy the original disk image.
Merge snapshot file with original disk image:
virsh blockcommit ${vm} ${disc} --active --wait --pivot.
check disk state: virsh domblklist ${vm} --details.
Delete temp *.backup files.
Dump VM definition: virsh dumpxml ${vm} > ${vm}.xml.

score 0 · Answer 4 · answered Mar 10 '17 at 09:28

I suspect it is only possible to clone a disk by avoiding the use of virt-clone, because (as has been mentioned already) virt-clone will refuse to work with a running VM. So you would have to use something else to make a copy of the actual disk image.

I think the basic answer is that you can try and hope you get lucky.

Getting a 'snapshot' of the guest's configuration is simple enough (virsh dumpxml NAME will do that). If you have more than one disk (i.e. if you have an OS disk and n+1 data disks), then I would try and avoid cloning the OS disk, and see if I could use a fresh install instead.

However, if there is any other method than copying disk images, I would probably prefer it. If this all related to a database server, for example, I would probably use the database's own facilities to copy the data between instances safely. If you were dealing with a filesystem directly, then it may be worth seeing if something like DRBD could help, or if something simple like rsync would.

Basically, I would carefully consider what you actually need to do, and try and avoid spending time on something like trying to copy a disk image that is in use (aside from the issues around what the copy might look like, I would have concerns about what trying to copy the disk might do to the original).

score -2 · Answer 5 · answered Mar 03 '15 at 10:05

This is completely doable with RAW disk image format. I don't know about qcow2...

Debian.img: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 497664 sectors; partition 2: ID=0x5, starthead 59, startsector 501758, 104353794 sectors, code offset 0x63

Debian2.img: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 497664 sectors; partition 2: ID=0x5, starthead 59, startsector 501758, 104353794 sectors, code offset 0x63

For test I cped a running linux mint system with everything. Then created a new vm with the new image, it didn't even have filesystem inconsistencies at boot. Although this was just a small desktop vm, what I was about to "clone" is a running LAMP server in production with high I/O on the database.

I really wouldn't care about inconsistency, just wanted to save some time to resetup the LAMP environment, I guess creating a base image at the beginning or snapshotting the first web server would've been a good idea but after it was fully configured and tested it was too late, they started using it in production right away.

While surely you can copy a "running" image with a simple "cp", consistency will be thrown out of the window. With journaling filesystem this can lead to filesystem-wide corruption, so please do NOT use this method on production system. — shodanshok, Mar 03 '15 at 11:21
While a system will allow you to do this, this will profoundly corrupt any image that is in use. If it is in use, it must be at least almost entirely read-only for this to remotely succeed. I wouldn't recommend this method on any system. A good way to get around this would be to deploy a base Debain system of the same version, (so you get all of your bootloader and partitioning created for you, if you don't want to do that manually), and then using rsync within the original VM to copy the entire root filesystem into the new VM image, overwriting all but /etc/fstab and the whole boot directory. — Spooler, Sep 30 '16 at 06:07

KVM virt-clone while the VM is running

5 Answers5