Live data from Hacker News

QEMU v4.0.0 released

qemu.org

31–40 of 168 posts

Re: QEMU v4.0.0 released

#31

It's pretty great and has been useful for many use cases for me, except too bad it lacks good 3D graphics support for modern gaming

It all depends on how and if someone will implement a Windows driver for VirGL. Given how complex video drivers are nowadays, it looks like a pretty daunting task.

Re: QEMU v4.0.0 released

#32

Anybody here using QEMU? What is your use case?

I'm using it in conjunction with PCI passthrough instead of dual boot. I've been running Windows 10 for more than a year now and played all kinds of AAA titles successfully. The performance-loss seems minimal. Recently I managed to get a second GPU and spin up another VM, so now me and my partner can play on the same machine, heaving each a keyboard, mouse and screen.

Re: QEMU v4.0.0 released

#34

Anybody here using QEMU? What is your use case?

Mainly playing with old operating systems, I'm a retrocomputing enthusiast. While years ago I would mainly use Virtual PC (I do miss its great GUI) and VMWare (and rarely bochs), qemu improved a lot and has (somewhat decent) support for so many more architectures. You can run Solaris for SPARC and Mac Os 9, for example.

I'm interested in your is cases. Do you have any good write-ups for Mac OS 9 and others? I never considered QEMU for those older systems.

Re: QEMU v4.0.0 released

#35
post #21

Earlier quoted context omitted.

Using QEMU directly is a bit tricky and it's not really intended to be used in that fashion by most users, unlike VirtualBox. Both gnome-boxes and virt-manager use QEMU under the hood though, and they provide a point-and-click experience. I use virt-manager myself and I do not think it's any more difficult than VirtualBox is.

We have several windows vms running in virtualbox. All have rdp/vnc for specialised programs. (These are offline). Everytime I tried to migrate to qemu or virt-manager or gnome-boxes it was a real nightmare especially installing SPICE+virtio drivers+ networking. I read in Phoronix the performance of virtualbox is subpar and all KVM/qemu is the way to go. Please, could the OSS community build a easy to use GUI that SP…

I confess that I haven't run Windows with virt-manager on my own desktop in a long while, but it worked just fine after installing the required drivers at install time. IIRC Redhat distributes signed drivers for Windows for free.

The problems I did have were with VMs I tried to convert from VMware to KVM, and those stemmed from Windows' inability (version 7) to properly handle changing hardware. Perhaps it's better at nowadays.

Re: QEMU v4.0.0 released

#36
post #5

Last week, I intended to replace VirtualBox with QEMU for my personal use. The spartiate documentation made it really hard. I lack the competence to seriously contribute. The official documentation just explains the numerous parameters. It also points to tutorials (wikibook, etc), which unfortunately are very basic and out of sync. Even Arch Linux does not provide a good documentation (lack of clarity, some obsolete…

Launching QEMU directly is not merely "tricky", but incredibly inefficient and ineffective once you need something that's beyond bare minimal.

E.g. here is a minimal QEMU command-line that gives you access to a serial console in the guest:

`qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,format=qcow2,if=virtio`

Simple, yeah? Now here (it's too long to post in this comment) is a real world QEMU command-line (as launched by the libvirt[1]):

htttps://kashyapc.fedorapeople.org/Fedora-28-QEMU-command-line-by-libvirt.txt

Compare and contrast the number of devices that libvirt adds.

FWIW, I strongly recommend to use libvirt to launch your QEMU-based guests. It is far more effective, and more importantly, provides security infrastructure like running the QEMU process as an unprivileged user, protecting the QEMU process (and its associated disk iamges) via the SELinux-based sVirt mechanism, and so forth.

Check out these[2] slides (recording is online, too) on "Security in QEMU" from one of the QEMU maintainers, Stefan Hajnoczi, at last year's KVM Forum in Edinburgh.

[1] http://libvirt.org/

[2] https://vmsplice.net/~stefan/stefanha-kvm-forum-2018.pdf

Re: QEMU v4.0.0 released

#37

It's pretty great and has been useful for many use cases for me, except too bad it lacks good 3D graphics support for modern gaming

It all depends on how and if someone will implement a Windows driver for VirGL. Given how complex video drivers are nowadays, it looks like a pretty daunting task.

The ReactOS folks might do it.

Re: QEMU v4.0.0 released

#38

Anybody here using QEMU? What is your use case?

My employer provides me with an iPad Pro and rather than carry around an additional laptop I run x86 systems (Linux and Windows 10) using QEMU-KVM on my ridiculously overpowered home server and remote desktop to them from the iPad Pro.

Re: QEMU v4.0.0 released

#39

Anybody here using QEMU? What is your use case?

I have a NUC sitting in a closet that I've set up to serve virtual desktops using LXC or libvirt (depending on what features I need, or if it's a Linux or MacOS or Windows guest). I made some scripts to build the various types of virtual environments I need [1], and then connect to them using x2go or Chrome Remote Desktop. This has really freed me up because I'm no longer tied to a single machine. My home dirs are mo…

We've a shared beefy Threadripper workstation in my lab that has a boatload of RAM and cores to spare. We set up Qemu + KVM in order to run a big Windows VM that we use mainly for MS Office via RDP connections and when we really need Visual Studio. We also have a FreeBSD and a Aarch64 Linux instance that we use for testing. It's amazing how flexible Qemu is, and how reliable the whole stack can be.

Re: QEMU v4.0.0 released

#40

Anybody here using QEMU? What is your use case?

I currently have a messy side project[1] where I'm writing bare-metal RISC-V machine code (i.e. writing in hex after assembling instructions by hand) targeting the SiFive HiFive1. QEMU is handy for testing since it supports that board pretty well - it lets me skip the "code upload" step and just run a binary with gdb right away.

I did a similar thing with the Raspberry Pi a few years ago, but the QEMU support wasn't great back then which made debugging incredibly hard. I think the support has improved a lot since then, so I should probably give it another go.

[1] https://github.com/SgtCoDFish/bedrock-bootstrap - I'm writing the steps as a kind of tutorial to myself to aid learning, but fair warning that it's all a bit of a mess right now!

Post reply on HN