[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Nested Virtulization needs 64-bit Whonx guest

#1

https://www.kernel.org/doc/Documentation/virtual/kvm/nested-vmx.txt

Known limitations

The current code supports running Linux guests under KVM guests.
Only 64-bit guest hypervisors are supported.

Thats why even when its enabled on host and the instruction for it is visible in the guest, it still doesn’t work. Can you please make kvm builds 64-bit?

For those who want to test make sure you detect nested capability on the host first. By now Linux enables them from out of the box.
http://ebalaskas.gr/wiki/kvm/nested

#2

Maybe related:

Can you try please if it is sufficient to install 64 bit kernel?

Don’t get confused by the package name. Works with amd and intel.

I make a wiki page about 64 bit builds.

#3

Good news is the KVM modules now work under this kernel and load. Somethigng they couldn’t do before.

Bad news, libvirtd did not start automatically and this solution is not working.

Full error here:

[code]Unable to connect to libvirt.

Verify that the ‘libvirtd’ daemon is running.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/connection.py”, line 1185, in _open_thread
self.vmm = self._try_open()
File “/usr/share/virt-manager/virtManager/connection.py”, line 1167, in _try_open
flags)
File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 102, in openAuth
if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
libvirtError: Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: Permission denied[/code]

#4

Its a permissions problem most likely. Any idea what needs to happen?

sudo usermod -G kvm -a user sudo usermod -G libvirt -a user

those don’t seem to work.

#5

Have you rebooted after modifying groups?

#6

Breaking News!

Continuing my current trend of exaggerated excitement

It works. After a reboot the error is gone and nested KVM works JUST WORKS!

#7

Added your solved issue to troubleshooting chapter:
https://www.whonix.org/wiki/KVM#Unable_to_open_a_connection_to_the_libvirt_management_daemon.

Started documenting Nested Virtualization:

Please complete and move to KVM page.

#8

is there away you can inlcude this functionality/packages out of the box? with user added to both groups. The point is to make it as easy as possible for users

#9

booted an i686 kernel by mistake, and KVM works. This limitation is old and no longer applies. its a matter of having the right packages with group permission tweaked - can you do this by default please?

#10

Installing that kernel by default would still require you to manually choose it in grub boot menu. Unless we can somehow autodetect it and boot the most suitable one - but that is difficult. Tails is doing that, but they’re a non-persistent iso (with additional persistence feature) using syslinux and a syslinux combot module. I am not sure it’s worth the effort just for nested virtulization. Having separate 64 bit builds as development goal for all packages might be more desirable.

Or to uninstall the other kernels to automatically pick it. But we probably shouldn’t make the amd64 kernel default - not backwards compatible - it won’t boot on non-64 bit systems at all. Only installing linux-image-amd64 would equal abandoning 32 bit builds while Whonix is using grub.

Also documenting 32 bit vs 64 bit seems quite difficult:

Adding both groups by default would probably be doable.

#11

my last post talks about how the 64 bit kernel is not a dependency.

Adding both groups by default would probably be doable.
That would be great, and also inclusion of the kvm packages too from backports?
#12

Created https://github.com/Whonix/Whonix/issues/259 to keep track of it.

Will probably be done for Whonix 10 when working on this:

Adding packages from non-stable, i.e. from testing or backports adds up too much maintenance burden. Adding backports by default is wrong. Would require each time there is an upgrade for qemu-kvm to download the package from Debian and to upload to Whonix repository. Already doing this with python-stem (which is probably not affected or really seldom by security updates), but this situations should be kept to a minimum. When Whonix will be based on jessie, this won’t be an issue anymore.

Would be a useless package for VBox users.

And also I am not seeing many people interested in nested visualization. Not sure having kvm installed within the image would be much beneficial for most users.

#13
Created https://github.com/Whonix/Whonix/issues/259 to keep track of it.

Will probably be done for Whonix 10 when working on this:
https://github.com/Whonix/Whonix/milestones/Major%20Usability%20Issues

Aweosme, Thanks.

And also I am not seeing many people interested in nested visualization.

You said the same thing about KVM support once :stuck_out_tongue:
The thing is we don’t know who will use it. Heck I bet most people reading this had no idea that this existed but would love to have it out of the box with less friction as possible.

Putting aside the backports issue, I think its worthwhile to include the version from vanilla stable repo. Its useful for testing and for building images if you plan to use it too.

Would be a useless package for VBox users.

You already include KVM centric packages like spice-vdagent, this couldn’t hurt either, right? VirtualBox users have been nagging their developers to include such a feature for years. But it doesn’t seem likely. Having this feature supported and ready to go by default, would encourage adoption of Linux for the sake of what KVM can do.

#14

The comparison with spice-vdagent is only ~0,3 MB. That useless ~0,3 MB for VBox users is a good compromise for also vastly improving platform support (KVM / libvirt). Very small size, very high benefit.

Would cause extra 241 MB. Really big size, dubious benefit.

There is also a package anon-workstation-extra-applications (https://github.com/Whonix/anon-meta-packages/blob/master/debian/control#L154). (https://www.whonix.org/wiki/Software)

Would only cause extra 54 MB. And those would be more justified.

The problem I see installing qemu-kvm, libvirt-bin, virt-manager by default is seeing complaints why image size increased, why update size increased, difficulty for justification why they are installed and what to answer to a feature request “shrink size, remove qemu-kvm, libvirt-bin, virt-manager”.

Making a good choice for default applications is difficult and controversial, but I am not convinced of the benefit of those. When there is a big demand, it’s easier to justify.

#15

Very understandable. Thanks for explaining.

#16

HulaHoop, I’m afraid it does not work for me.

#17

Screenshot from 2016-06-30 20-34-50.png1920x1080 281 KB

Whonix and nested Guest crashed. Whonix froze.
ker n.log
http://paste.ubuntu.com/18206764

And now run this VM causes reboot of the Whonix.

#18

Now work. Its virt-manager’s VM’s window’s resizing bug I think. (Nouveau HOST driver)