3

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?

4
  • 1
    virt-clone --original slesp4 --name newsp4 ERROR Domain with devices to clone must be paused or shutoff.
    – c4f4t0r
    Mar 2, 2015 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 2, 2015 at 14:41
  • virt-clone is also allowed after virsh suspend; perhaps, that won't count as a real shutdown for you. Aug 1, 2017 at 14:42
  • virt-clone no longer supports cloning suspended machines. Jan 4, 2021 at 13:31

5 Answers 5

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).

5
  • Or copy the file if the storage is file based Mar 2, 2015 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 2, 2015 at 16:15
  • You can have snapshots without filesystem support or LVM - 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 instead?
    – the-wabbit
    Mar 20, 2015 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, 2015 at 7: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, 2017 at 12:16
0

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).

0

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.

0

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

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

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.

2
  • 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 3, 2015 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, 2016 at 6:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .