(This is a serious question--what can possibly be more important to average virtualbox users than having a working desktop environment? Virtualbox has always occupied the desktop virtualization niche, so I'm trying to figure out what has changed...)
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.
[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".
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.
What? I can only laugh at such a statement
Don't use hyped up desktop managers that need 3D to work.
This is with firefox (they also broke 3d acceleration in linux); chrome is OK, and so is firefox if I force enable video acceleration and ignore the severe visual artifacts.
FWIW, Chrome is still a bit sluggish on a 12 core xeon with no GPU, but it is usable (unlike Firefox on the same VM).
Anyway, I used to get away with no gpu acceleration on my laptop, but it became untenable in ~ dec 2016. It still sorta works on the server-side web browser.
In Wayland mode, only if you are very patient. I'm not. Virtualbox support for Wayland is not there.
Anyway, most engineers at work use unity because it is the default, and it is a non-starter without hardware acceleration. We site-licensed vmware, and it seems to work OK.
The last time I checked, the second most common choice is fvwm. It sorta works out of the box and isn't unity. Also, it can run on the big server VM's, unlike unity (there is no 3d acceleration in the server kvm instances...)
Another common choice is to do everything via console, productivity be damned. (There are some highly productive console users, but they tend to put linux on their laptops on day one anyway)
Why start a browser there? Is it for testing the web pages in different environments? If not, then wouldn't it be more reasonable to start it on a bare metal (the machine you connect to the VM)?
But it might be my bias, I'm one of those that install Linux on a company laptop on day one :) so I'm most efficient in the console.
But then, I spend most of my time in vim and localhost web pages.
I hope they get the help they are asking for- I wish I could do it. I think it's a great program and it would be great if it were here for a while.