Sorry, I can't offer any blanket guarantees. Yes, if it's a working VirtualBox VM then CloneVDI should be able to clone the drives. With compaction enabled this may go faster than you think. CloneVDI does not clone VMs, you'd have to create the VM yourself.

If it was me then I'd set up the new server separately, get it all ready to run so that all you have to do is swap over the cables. I assume the server has some kind of internal backup mechanism that can take care of bringing it right up to date relative to the few-hours-old version which was cloned.

Our current backup system is done by previous tech. For some reason he used Fsarchiver to create a complete filesystem backup of the whole Virtualbox LVM partition (this includes ALL VM's on that specific server) as a backup solution. This is a bad setup and i will be fixing this in the new system.

For previous reasons i cannot bring back a few-hours-old version back up in a timely manner, since i have to write the whole filesystem (700gb+) on the existing disk.

The plan now is to setup KVM temporarily on a different server (already setup and ready to go) and clone VM's from the old system to the temporary KVM server and when all VM's are cloned and transfered i can just start the VM's on KVM server 1 by 1 and if they startup normally, ill shutdown VM's on Virtualbox server 1 by 1.

If the drives use LVM then CloneVDI will not recognize the partitions on the drive, meaning that compaction will not work. It will just be a straight copy, though the snapshot merging will still work as that happens at sector (not filesystem) level.

For the avoidance of doubt: CloneVDI has no volume snapshot feature a la Windows backup. It would be dangerous to have the filesystem being written to while CloneVDI is cloning it, and I'm not sure host permissions will even allow it.

What a life saver this program is. I did a fresh install of my ubuntu and had the *.VDI files (base and snapshots) on another disk, I didn't know about the virtualbox.xml file until it was too late.I copied all the VDI files to a windows machine and ran CloneVDI choosing the latest snapshot as the source, it took 2.5hrs and another 1hr getting it back to the new ubuntu system (190GB clone) but it was worth it.

Thanks, however for future reference the important control file since v4.0.0 is the ".vbox" file which can be found inside the VM folder alongside the base VDI. If you're going to back up a VM it's best to just copy the VM folder: backing up and restoring are just special cases of moving a VM: Howto: Move a VM.

Last week I cloned a VM (3 VDI files) to a new SSD, and proceeded to work with them under VBox 6.0. All went well.

Today I installed the VBox 6.0.2 update, ran the same VM, installed the extensions, and rebooted. When it started again, it failed. I saw errors about missing ATA drives (mine are SATA), and when Windows tried to boot, it offered to run repairs. I accepted that, and it cycled back through another reboot, another report of missing drives, loading Windows filees, and offered again to repair.

I tried another VM I had on the SSD, and it worked fine.

Then I cloned my three VDI files again, assigned again to the VM, and tried to run. Got the same errors.

I noticed that on that VM, I had selected the checkboxes for SSD drives in the settings. On the others, I had not.

I am cloning again, and now wondering whether to reinstall VBox 6.0 and try that, or to simply try again under 6.0.2.

@wmeyer,Not sure why you posted in the "CloneVDI tool - Discussion & Support" thread, I don't see the connection. Just because you might have used CloneVDI, does not make all your problems a CloneVDI problem necessarily.

Don, if you need to split the message from wmeyer, and/or delete my message, go right ahead...

Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.

Wmeyer has been using CloneVDI a long time, in fact he was the first person to post in this topic other than myself.

That said, I agree that it isn't clear what role CloneVDI played in this problem, if it even did the cloning. AFAIK the SSD option in the VirtualBox VM settings doesn't affect the structure of the VDI, it just controls how the VDI is managed at runtime.

However perhaps it's time to say again something I've said before: I'd prefer to keep this topic useful, I don't need to have my ego stroked. If you found CloneVDI uniquely useful for some task then I'd like to hear the details, or if you have a CloneVDI problem or feature request then that's obviously what this topic is for. I'd like to keep it to those things, and keep to a minimum all posts that haven't much potential to benefit future readers.

If CloneVDI played no part in my problem with the SSD image, that's great. I confess I posted that here because a) I could not rule out CloneVDI as a factor, and b) mpack's responses have always been most helpful. If it could not have been a factor, I will pursue in a more appropriate forum.

I have used CloneVDI for years, and have not found any issues, apart from the one introduced with Windows 10 disk formats. And I don't know if that is an issue with CloneVDI, or the underlying libraries, come to that.