I find this baffling when KVM is much more amenable to being scripted from the command line.
If my VMs can't easily be run on any host from backup they tend to be quite useless at the most critical of times.
As a light user of virtualbox, I get the impression using anything but the gui is really hard compared to other virtualization tools.
For instance, auto-starting raw-disk vms at boot on windows is a pain, and hyper-v is free. Its only real downside is lack of gui support for linux guests.
Similarly, you need to stand up separate backup infrastructures for your desktop and virtualbox, or you will be told "you're doing it wrong" when you try to restore.
I guess I could try to write a script to get a crash-consistent export of running virtualbox vms, but the host file system (btrfs, zfs, etc) already does an adequate job of that, so this is just useless administrative overhead and disk space waste from my point of view.
Anyway, when win8 came out, virtualbox couldn't handle the new start menu, and windows guest vdi was my only remaining use case for it at the time.
It is a shame, VirtualBox was my go-to vm solution for years, specifically for its debian/ubuntu host support (unlike vmware) and good desktop guest support (unlike all the other options).
I've used VBoxManage to create, manage and control VMs on remote headless hosts. And work with VRDC desktops. Easy.
Backup/restore of host system should have nothing to do with VirtualBox. It's just files. But then, I use Debian hosts. For backups, I tend to use LUKS-encrypted SSDs via USB, and just copt the full VM folder. Works perfectly.
IME, you can't.
why can't you do it in the user space within those VM's, communicating over a network adapter? If you don't care about putting on a raincoat, going outside to the Internet, and launching it up into the cloud, you can just install dropbox and get a sync'd directory without additional work. Obviously this is extra unnecessary overhead, two times, but for your use case you may not care.
you can alternatively roll your own solution though it might take you an hour or two. think about rsync over a local network adapter.
I realize these are hackish solutions but if it's stupid but it works, it's not stupid.
on the plus side you will control that traffic. having directory syncing that breaks the VM abstraction opens leaks due to potential oversights in how it's coded.
if I were in your predicament I would work around it.
The difference between this proper approach, and what you call "hacks" is minimal, and basically a question of packaging. To be clear, I agree that the VM developer should write and package these utilities for every major guest operating system it supports.
[0] https://github.com/vagrant-libvirt/vagrant-libvirt#synced-fo...
I see this as a vagrant issue though. It really falls short of its promise of being a dev environment where you "never say 'it works on my machine' again".