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
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]
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
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?
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.
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.
And also I am not seeing many people interested in nested visualization.
You said the same thing about KVM support once
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.
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 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.
