When will we get a replacement for QEMU? It's a bloated security mess and the cause of most virt CVEs. KVM is a pretty good hypervisor but we need device emulators.
When will we get a replacement for QEMU? It's a bloated security mess and the...
Other urls found in this thread:
Google wrote a replacement for Google Cloud but they aren't releasing it.
just fork qemu and fix it or write your own x86 emulator / kvm hyper-visor that should be super easy
write your own x86 emulator
QEMU is fine for CPU emulation, that's not used with KVM/virtualization. QEMU is used with KVM for peripheral emulation. (disk, network, VGA, PCI, USB, serial/parallel ports, etc.)
KVM is actually good code and has a relatively small codebase. KVM is fuzzed and audited by many companies and is fairly secure.
I really hope we do see a replacement, and hopefully that replacement is more intuitive and simple. Maybe i'm just a brainlet, but I can never figure out QEMU's options and the logic behind how you do things, and I just end up going back to Virtualbox.
Amazon AWS is moving to KVM soon. Is this the death of XEN?
Use it with libvirt.
If you need a GUI, use virt-manager. Gnome Boxes is also an option but it's too simple (like most gnome shit).
Never knew about this
Wow, Virgil 3D finally made it into the kernel: virgil3d.github.io
is the performace decent?
If you're using QEMU, just do GPU passthrough and get 99% gaming performance. Virgil doesn't even have windows guest drivers.
It's called Qubes
it's not enabled by default. you have to compile qemu with the option enabled and then play a bunch of games to get it going.
i could give a shit about 3d acceleration or 3d in general inside a vm, I just want 2d acceleration so the interface is snappy, which is never going to happen. I haven't gotten virgil3d setup with qemu yet, I want to try. virgil3d is supposed to use the host gpu to some extent to accelerate 3d, and mesa uses 3d now to accelerate 2d with DRI if i understand it right. So in theory, running a browser or moving a window around the screen won't look like a slideshow inside of the VM, but I'm not getting my hopes up.
gpu passthrough is really the best answer.
This is why we need AGPL.
So in theory, running a browser or moving a window around the screen won't look like a slideshow inside of the VM, but I'm not getting my hopes up.
QXL+Spice looks decent to me.
it works and it's useable, i'm not really complaining, but it's nothing compared to how silky smooth it is running natively with everything accelerated. firefox and chromium have gpu accelerated 2d now too if you turn it on. if you could get that going in a vm you wouldn't even be able to tell your in one.
Even 3D support for X11 guests in Virtualbox is in a dilemma.
Our 3D support for X11 guests is a bit of a dilemma for us. There are many, many issues which would be relatively easy to fix. Individually each one might be a day or two's work for a developer. Unfortunately it does not really make sense to address them individually, and just now none of our developers has much time to spend on this. Since a lot of the problems are things which could probably be fixed by users with reasonable 3D development skills, we have decided that for now it makes sense to declare 3D support for X11 guests as "user supported". We will be happy to integrate patches to fix individual problems if we can see without too much effort that they are not going to break other things, and we will be glad to provide other assistance as time permits.
Why not use joyent.com
Now that we are on the topic of qemu, is there any way of having it run properly (with a hypervisor like kvm) on Windows or can Virtualbox use qcow2 images? I don't want to use virtualbox on Linux, but I want windows ppl to be able to use my images.
the real (((delimma))) is oracle's support for open source
there's a quote somewhere of the ceo saying something along the lines of "our customers tried open source, and they prefer proprietary" referring to virtual box but i can't seem to find it.
That seems like a valid stance for a free open source project with limited developer resources, however I'd like to know what they're directing their attention to instead of 3D support, what else do they deem as more important and what are they actually working on besides 3D? Without that information it just seems like they're saying "we're not going to work on it." not "we would work on it if we didn't also have to work on this first".
This is obviously just an anecdote but I will say that I know a good handful of people, myself included, who have switched from virtualbox to other products (usually vmware), I don't know any that went the other way.
Use qemu-img to convert qcow2 to another format
I just want 2d acceleration so the interface is snappy
Too bad gnome-shell is an opengl compositor and wouldn't benefit from 2d acceleration. one of the most popular desktop environments is all llvmpipe
software opengl rendering. No benefits from 2d acceleration whatsoever.
it doesn't seem like they're working on a whole lot of anything. I can't think of the last update to virtualbox that was significant. they probably pump more work into the open source but seperately licensed extensions for usb 3 and shit like that.
i can't really argue for the corporate side, where's the money for oracle to dump a bunch of resources into virtualbox.
i thought mesa accelerates 2d with 3d anyway.
LLVMpipe is a fallback driver for software rendering OpenGL 3d applications on your CPU instead of GPU.
this would be good then, i don't use gnome-shell i use xfce, but since there's zero interest in hardware accelerated 2d in VM's, if it all runs in 3d, and some VM somewhere get's it together with hardware accelerated 3d, like virgil3d, then it might happen.
here's some interesting drama
virgl3d is out, enable it pls!
<fuck okay if we have to
what the fuck what are these unneeded dependencies on my server doing!
<it's disabled again serverfags and we aren't re-enabling it until stretch+1 in 10 years. we're also too lazy to make separate packages.
so debian disabled a major feature for years, and the average linux user probably isn't going to compile and install something as massive as qemu. i just spent 3 hours trying to get it going on *buntu and it isn't going to happen, i need to do this on gentoo.
this is how features die. no wonder whoever makes virgl3d is taking is time. spend all that work, on something that would make a huge difference in vm's on linux, and lazy niggers won't even include it.
*buntu isn't going to include it either, because debian won't include it. so that probably means no distro's that rely on debian will include it.
I'd rather spend a billion hours implementing vdi support in qemu or qcow2 in virtualbox.
vdi is supported in qemu
Why the fuck do the server people even care about extra libraries? It's not like they are running processes.
tracking all that user data takes a lot of space
all for a simple simple arm virtualization
qemu-system-arm.exe -M versatilepb -cpu arm1176 -m 192 -hda Occidentalis_v02.img -kernel kernel-qemu -append "root=/dev/sda2" -net nic -net user,hostfwd=tcp::2222-:22,hostfwd=tcp::5800-:5800,hostfwd=tcp::5900-:5900
this is why virt-manager exists, and it's meant to be scripted obviously nobody is typing that shit out everytime
I've never understood the point of doing this? Why not just dual boot windows?
And Nvidia has been do doing shady shit. If they detect your are using KVM, the drivers refuse to run. QEMU had to add an option to hide the KVM signature: lists.gnu.org
The latest Nvidia driver (337.88) specifically checks for KVM as the
hypervisor and reports Code 43 for the driver in a Windows guest when
found. Removing or changing the KVM signature is sufficient for the
driver to load and work. This patch adds an option to easily allow
the KVM hypervisor signature to be hidden using '-cpu kvm=off'. We
continue to expose KVM via the cpuid value by default. The state of
this option does not supercede or replace -enable-kvm or the accel=kvm
machine option. This only changes the visibility of KVM to the guest
and paravirtual features specifically tied to the KVM cpuid.
In other news, it looks like Virtual Box modules will soon been in the Linux tree. It's currently being worked on in staging,
No more DKMS bullshit :D
Note this driver has already been significantly cleaned up, when I started working on this the files under /usr/src/vboxguest/vboxvideo as installed by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681 lines. The version in this commit has 4874 lines.
Why is Redhat helping upstream VirtualBox drivers? It's a direct competitor.
if it's in the kernel it's not a competitor anymore
BINARY DISTROS CUCKED AGAIN
Wow, now I can finally play SuperTuxKart in QEMU!
I've never seen a Linux user using QEMU for desktop virtualization. It's always either Virtualbox or VMWare. Is QEMU really that shitty? And doesn't Virtualbox use KVM in linux anyway?
The documentation and intuitiveness are really that bad. I can't speak on performance, but apparently the performance with KVM is excellent though.
i use qemu exclusively. i've never had any problems. the performance is near native cpu wise, with virtualbox you take a 20% performance hit, even using KVM mode. look up the benchmarks. there's also way more options with qemu, it's just not that intuitive to use. i just use virt-manager, but if it's not implemented in virt-manager you have to edit some xml for the vm directly. you can send any pci or usb device through to the VM, your tpm if you want to use that botnet, your rng, you can do all kinds of shit.
the only benefit to virtualbox is the seamless mode, which is kind of like X11 forwarding without X11 forwarding, it just makes it fullscreen but only draws the windows your using. there's no seamless mode with qemu/virt-manager, which uses's spice or vnc, so i just do X11 forwarding when I want that.
Running QEMU through virt-manager / libvirt is better anyway
libvirt does automatic SELinux / Apparmor confinement, runs QEMU as a unprivileged user, drops unneeded capabilities, etc.