i can give it a try again. it complained about having two different hard drives in one snapshot iirc. when i was researching it, the documentation seemed to imply that libvirt wasn’t supporting it yet.
1 Like
Issue was discussed by Libvirt devs on RedHat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1320263#c4
I even linked to a secure clipboard proposal that would have given a secure clipboard functionality by copying Qubes style interaction. It went no where and was closed as WONTFIX.
https://bugzilla.redhat.com/show_bug.cgi?id=1320263#c5
Updated linked ticket with this info.
1 Like
I went ahead and tested it for ya. Add a new disk device in the VM’s Details pane. Install gparted and format the new disk with ext4 (exists under the name /dev/vdb).
After rebooting it will auto-mount the device in the Thunar favorites list using “/media/user/” as a mount point. You will need to adjust permissions of this external drive to be able to add files on it.
I followed this and it worked:
Then I saved a test file with this very link while in Live mode and rebooted to find it still intact.
Moral of the story: KVM is a beast and it will f* VBox’s shit up on every technical measure. It’s just the damn VM import feature that seems to be giving everyone grief 
2 Likes
thank you. i will give it a try again. if i can get kvm to support a configuration that involves an immutible/locked drive and a writethrough style drive via snapshotting, that would be great and would likely warrant yet another damn tweak to the perpetually beta version of the guide at the moment. lol!
2 Likes
I have just made the switch to kvm for whonix (having some familiarity already with it with other vm setups) and love it!
Just what I wanted in a user experience once I got over the increased learning curve; much more lightweight experience (and more cli based which I prefer) and of course and perhaps most importantly proper FOSS!
Kvm feels much more ‘linuxy’ whereas virtualbox is more like a windows relic in terms of user experience- point and click which is advantageous for some and was for me initially getting started but glad I got over the hump with kvm now as I will be sticking with it.
2 Likes
Related:
Why use VirtualBox over KVM on Linux hosts?
No reason , because simply why the user should use virtualbox in the first place inside GNU operating systems?
someone might use vbox in gnu hosts because he came from windows/mac background and hes noob to try new things which might he doesnt understand it very well.
Free Software:- No, Vbox is more into proprietary field
Security reasons: No, Vbox sucks at it as well
User Friendly: No, the user is using GNU/Linux so he should get used to it and try new things rather than staying on the dark ages from whatever background he came from.
Deprecation of Vbox is a step forward to anonymity,security,free software.
1 Like
Why not, actually? provided it’s easier?
Reading through this forums, I was somehow under the impression that VirtualBox is closed source. I was proven wrong. It is open source. So what are the big problems, actually?
I was searching hard for security issues in VirtualBox on Whonix wiki, and the single result I found was
(I don’t include the full link since the forum system doesn’t allow me to)
If we put the licensing issue aside, most of the rest is pretty vague.
Oracle is infamous for their lack of transparency in disclosing the details of security bugs, as well as discouraging full and public disclosure by third parties.
References?
it would be unsurprising if users were charged for these restricted features in the future
Future prediction. More reasons pertaining to present?
There is indeed one specific issue on this page
One example is this historical [0day vulnerability]) reported privately to Oracle in 2008 by an independent security researcher. Over four years later, the vulnerability [remained unfixed], exhibiting Oracle has a history of failing to provide timely patches to customers so they can protect themselves.
That’s serious enough. However we are at 2019. Any updates since then?
Seriously, whether or not it’s eventually depreciated, I feel that the case of VirtualBox being less secure isn’t fully explained.
Edit by Patrick: add real link
1 Like
References for VirtualBox licensing issues here:
Whonix ™ Virtualization Platforms
On VirtualBox security, ticket VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed does look really bad due to non-responsiveness and non-progress.
To learn more, see: VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed and the associated VirtualBox forum discussion. [2] Users must patiently wait for VirtualBox developers to fix this bug.
VirtualBox version 5.2.18 or above is required since only that version comes with Spectre/Meltdown defenses. See Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF) - #22 by Patrick.
Also see the following Whonix forum discussion: Whonix vulerable due to missing processor microcode packages? spectre / meltdown / retpoline / L1 Terminal Fault (L1TF)
Perhaps this feedback can be used to improve chapter Whonix ™ for KVM? @HulaHoop
1 Like
I don’t manage to reconcile those two statements. Does version 5.2.18+ have defenses or not?
I tried to follow the link but it is way too technical for me and I don’t see a clear conclusion at the end of it.
If the host was patched, does the problem in VirtualBox still exists?
It has but seems incomplete as per #17987 (VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed) – Oracle VM VirtualBox.
As per #17987 (VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed) – Oracle VM VirtualBox possibly yes.
Developer comment from #17987 (VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed) – Oracle VM VirtualBox
No, this isn’t expected. Looks like it needs dev attention (including having a look at what exactly goes wrong with specre-meltdown-checker.
It’s not only the spectre/meltdown issue, the bigger one is that virtualbox is not supported very well on most distributions.
It’s not available in Debian stable’s (Stretch) and testing’s (Buster) default repositories main, contrib or non-free. For Debian stretch you need to install it from backports and in buster you will have to wait, until buster get’s stable, thus a backports repository is created for buster.
Oldstable jessie is the only one, that has a offical package of virtualbox in the default repositories.
See here:
https://packages.debian.org/search?keywords=virtualbox
But it gets worse.
Many Linux users, especially beginners, use Ubuntu and all the other ubuntu flavors like Linux Mint.
And in Ubuntu virtualbox is available only in the multiverse repository.
Packages in multiverse are not supported by Canonical, it’s up to the community but no one is responsible for a package in multiverse, there are no maintainers of a package like in Debian, thus these packages usually get no updates at all and will have plenty of known security vulnerabilities after a couple of months of the release of a Ubuntu version.
The story is different for KVM. KVM is officially supported by Canonical and its package is in main. Main is a repository officially supported by Canonical. Multiverse and universe are not supported by Canonical, multiverse and universe usually end up in a collection of vulnerable software packages. It’s highly recommended to not use any packages of these repositories, unless you know what you are doing.
Thanks @Patrick and @Firefox that makes things clearer.
It’s not in Debian Stable because it’s being compiled with a tool that’s considered free by OSI (whatever that is) but not by FSF / Debian. Was not a priority for Oracle 6 and 4 years ago and probably not a priority now either.
Possibly still vulnerable to Spectre/Meltdown although patching the host may solve the problem. No reply from developers on that during the last 8 months.
Not many serious players in this market though. For linux, it’s either VirtualBox, KVM and Xen.
I switched completely from VBox to KVM a few months ago. I disliked it first because of a perceived complexity. VBox was more beginner-friendly.
I gave it another try, and this time I took the time to understand how to setup vbox-guest-additions-like settings like full-screen resolution and clipboard and files sharing. Virt-manager is a great tool, also user-friendly and I have no difficulty using it as I would have VBox.
As nothing would stop anyone from importing the .ova files in VBox on Linux, I guess “deprecation” here means unsupported/you are on your own?
Yes.
1 Like
Well, only advantage I’ve found in using KVM instead of VirtualBox was speed. My tests showed it to be about 15% faster. In spite of that, I found my way back to VirtualBox. Why? much easier to install, configure, update and change configuration. It is a breeze to share files between host and guest (something I spent days trying to understand and make work on KVM – but never fully succeeded. This takes seconds to configure on VirtualBox. And it never fails). Same thing with pen-drive. It is a child’s play on vVirtualbox, but a pain in the neck on KVM (I never managed to make it work smoothly.)
I don’t like the idea of using proprietary code. Never did. Even when it is open source. But, it this case, I think it is worthwhile to use VirtualBox in place of KVM. Perhaps it is different if you are a IT Pro or if you have a lot of time to find the sparse and poor KVM documentation.
From the Debian wiki:
“Packages for VirtualBox are not available in Debian 10 and won’t be in buster-backports either. A recommended alternative is Virtual Machine Manager.”
If VirtualBox is not supported by Debian, it should not be supported on Debian either.
i’m somewhat sympathetic here for user friendliness, whether it’s a mount or an immutable snapshot. but, both are scriptable with kvm. it’s not “it pro” level sophistication. it’s just slightly different. and while it may not matter to many, one downside with virtualbox is the number of extra hoops one must jump trough to get it to work with secure boot. kvm works fine with secure boot without any additional tweaks. to get virtualbox working with secureboot requires more problematic hoops to jump through than getting kvm to do a shared directory.