[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Gnome Boxes -- Viable platform for Whonix?

#1

I see a couple of posts anticipating the Gnome Boxes – the simplified virtualisation platform for qemu-kvm – but find no mention of whether it can actually support Whonix. Though very basic, the Boxes graphic interface seems fine to run a simple OS. Can Whonix be setup in Gnomes Boxes? Are there any experiences or performance results to discuss? Just curious …

1 Like
Why use VirtualBox over KVM on Linux hosts? Considering deprecation of VirtualBox on Linux hosts.
#2

There was much anticipation because of improved UX - we thought it would gain VBox-like simplicity in importing VMs instead of using the commandline. It didn’t the last time I looked which is a while ago. Also I’m not sure if it enforces Apparmor for VMs.

1 Like
#3

Any update?

#4

OVF import support has been merged:

The import/export feature ticket is still open though:

Here is the design discussion page for the GUI:
https://wiki.gnome.org/Design/Apps/Boxes/ImportExport

1 Like
#5

Is it more usable than virt-manager / available from packages.debian.org yet?

#6

Not an expert on Gnome Boxes, but last time I tried, i.e. a few weeks ago on debian stretch, it was very disappointing. While the GUI is quite elegant, the lack of features (or removal of) is appalling. It just seems that Gnome Boxes devs take pleasure of implementing as few features as possible, or they are very well hidden. I couldn’t figure out how to customize anything, like network or shared folders, etc.

virt-manager is way better IMHO.

1 Like
#7

Ironically, I just reinstalled Gnome Boxes again after a long time away. I actually installed virt-manager, qemu-kvm along side, and tested Windows 10 in both. I’d have to say that Boxes out-performed VMM out of the “box” (pardon the pun). Without the Spice guest and webdav drivers, it was not initially nice. But with those additions, it is very good and permits file sharing where virt-manager requires creation of a shared bridge network to allow host-guest networking due to the macvtap limitations.

That said, the .ova is hurdle for Whonix installs, as is noted above.

1 Like
#8

Hm. You are talking about two different things in this sentence. VMM doesn’t use a network for shared folders but a protocol called 9pfs that handles it directly. That’s why it outperforms NFS implementations that proprietary OSs like Windows otherwise need.

BTW VMM does support drag-and -drop of shared files via SPICE but I disable it for simplicity. I also am not sure of the security implications.

Networking is a different topic. Laptop wireless cards don;t allow bridging for security reasons and so you need to use NAT for the external facing connection.

#9

I did actually refer to “host-guest networking,” which certainly is, an option for “file sharing” within VMM, Samba being a popular choice. However, I’m certainly NOT an expert in this domain.

Please correct me if I’m wrong, but, my understanding is that 9pfs is technically a paravirtual file system, that still relies upon a network “protocol” such as TCP/IP to emulate a passthrough system service. Unfortunately, going back to the previous discussions that you and I had on getting this passthrough to work with Whonix, I have still not been completely successfull with it, even with a Windows guest.

And the SPICE folder sharing feature, I believe, also relies on a network protocol … webdav? With gBoxes, sharing via webdav configured automatically once the Guest Tools & webdav daemon were installed. With VMM, I was unable to get it work.

The assumption that I have made (which perhaps you will correct if you know otherwise), is that some of these difficulties are likely related to the basic limitation of macvtap, which provides the out-of-the-box “network” bridge created in VMM:

“due to the way that the host’s physical ethernet is attached to the macvtap bridge, traffic into that bridge from the guests that is forwarded to the physical interface cannot be bounced back up to the host’s IP stack (and also, traffic from the host’s IP stack that is sent to the physical interface cannot be bounced back up to the macvtap bridge for forwarding to the guests.)”

You simply cannot even ping from host to guest (nor vice-versa), with the box-standard network, despite being able to see outside.

This can apparently be overcome, e.g., through custom configuration of a shared network bridge. But as gBoxes solved my problem with Windows, I just have not invested in customizing a bridge, as yet.

#10

Correct but it doesn’t need a network interface to work with the way it is implemented as a kernel module.

Expected specifically on Windows because there is just no way a Linux kernel module would be compatible with their closed kernel. I remember there is a virtio package for Windows guests but I am unfamiliar/disinterested with the details since I don’t use Windows.

That might be because I explicitly disable it in the config and you will have to change that to get it working.

I’d see that as a good security feature in my book. One can do port forwarding for NAT guests with some script floating out there.

Good to see it works for you :slight_smile:

#11

So as the developer, can you offer any insights on how to configure VMM to enable the SPICE folder sharing feature, preferably with all guests, but at least, with linux guests? Do you feel this change creates any significant security risk? Does the required “change” go beyond the steps outlined here or is this sufficient? https://www.whonix.org/wiki/KVM#Shared_Folders

#12

It is not outlined in that link.

To enable change no to yes for filetransfer in the XML

<graphics type='spice' autoport='yes'>
      <clipboard copypaste='no'/>
      <filetransfer enable='no'/>
</graphics>

Go ahead and test it as I haven’t.

Yes since Libvirt exempts the shared folder path from Apparmor restrictions. I have no idea how a feature that allows transfer from arbitrary folders on the host would change that so I decided not to mess with it.