Exactly. A few days using HyperV for my linux desktop guest was enough to convince me that I didn't need Docker for Windows THAT bad. I'm back to Virtualbox.
Portability of VMs shouldn't be overlooked, it's why VMware is still quite relevant and why when that is out of the question Virtual Box is very popular.
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.
While I do love KVM, it takes a lot more to get running properly than installing Virtualbox and Vagrant and being up and running with a whole ecosystem of every type of prebuilt box you could imagine.
Yep, the last time I tried to get a KVM machine going I had to hack XML files to get the correct SCSI controller just so I could mount an ISO. It's 3 clicks in VirtualBox.
I've tried to use VBoxManage, but mostly to no avail. I have some full-system backups with not-exported virtualbox vm's in them, and usually have to hand edit a bunch of undocumented xml to make them start. I guess vagrant makes this sort of thing better, somehow, but I'm moving everything I possibly can to docker, and then I'll deal with the remaining desktops using some other technology (maybe vagrant, maybe not).
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 doubt that I'd even try to pull VMs out of a full-system backup without restoring it first. Over my head, for sure.
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.
I'm not a vagrant user, but your question intrigued me. A quick skim of the documentation for the vagrant-libvirt module shows a synced folders section[0], which appears to support configs for NFS and 9pfs for two-way sync. Do those not work? I use vanilla libvirt, and I've had great luck with exposing my development directories to VMs using the 9pfs resource sharing. If the vagrant plugin isn't doing that, then it may just be a small bug in the libvirt XML file they're generating. Or am I totally off-base?
Thanks, I'll look into it more closely. I tried the libvirt module and I remember having issues with it. I don't remember if there were no compatible debian boxes for it, or it didn't work properly on windows... something was there.
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".
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.
Bidirectional syncing primary use case is for development. Requiring a bunch of hacks and overhead is a terrible idea and controlling the traffic is not a useful feature for that use case.
I understand that, but it's not reasonable to ask that the VM intrusively modify the filesystem without the guest operating system knowing about it: therefore the "correct" solution is some guest userspace utilities for the user to install, which perform these operations from inside the VM. (If a 5 in a file changes to a 6, then rather this change happening from outside the VM, to the total surprise of the guest OS, as though you pulled the hard drive, mounted it in another computer, modified that one value, and remounted it in the original computer, all without the guest OS even being aware that the hard drive had been unmounted or modified, instead, it should be performed by a utility from inside the VM.)
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.