Live data from Hacker News

QEMU v4.0.0 released

qemu.org

111–120 of 168 posts

Re: QEMU v4.0.0 released

#111
post #89

LTT [1] did a video recently about running macOS on a Linux host using QEMU. Anyone here tried that? If so, what's the experience like? Thanks [1]: https://www.youtube.com/watch?v=ATnpEOo3GJA

I do this using Proxmox (QEMU under the hood), and it's been mostly a nice experience. I currently run 3 VMs on a single Linux box with 3 GPUs (one per VM via VFIO passthrough). I've used both NVIDIA and AMD graphics cards with success. Before Mojave, NVIDIA cards were easier with their web driver, but Apple and NVIDIA don't get along in Mojave (both companies are blaming each other) and there is no web driver. So for macOS, I've switched to an AMD GPU which works mostly out of the box, apart from needing a small tweak in the Linux host's kernel parameters ("disable_idle_d3=1" to avoid a bug preventing the device from being used after a VM restart).

To get macOS to see my GPUs with full acceleration and audio over HDMI, I use the Clover bootloader to inject a small section into the DSDT, mapping the emulated PCI address to a device that actually looks like a graphics card to macOS. This same DSDT patch works for both NVIDIA and AMD GPUs (the ones I've tried anyway).

The best thing about Hackintosh in a VM is that you no longer need to fear macOS upgrades. Just create a snapshot, try the upgrade, and if it doesn't work out, you can restore, investigate, and try again.

LTT's video is a nice overview, but his claim that "because this is a VM... it will run on any hardware" isn't quite true when talking about GPUs. Unlike the CPU, memory, and some other devices, the GPU is seen (nearly) directly by the guest VM, so guest OS support is in fact required to see the advantages of GPU passthrough.

In summary, it's never going to be super easy, but it's not too difficult either, and the performance (and flexibility) is actually really great.

Re: QEMU v4.0.0 released

#112

Earlier quoted context omitted.

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,forma…

> minimal QEMU command-line" > -nodefaults Once you add `-nodefaults`, the list of arguments grows because now you must add a bunch of things that were there by default. If by "minimal command-line" you mean "the simplest list of arguments", then your example is wrong. If by "minimal command-line" you mean "command-line that gives the minimal VM", then you're being misleading, because that's not how people will take…

This. Also, most of the example command line has nothing to do with serial consoles.

Re: QEMU v4.0.0 released

#114
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…

Welcome to the Open Source experience... sadly.

As opposed to what? Most proprietary tools don't have good documentation either. And then you may not even be able to look at the code to see what it does.

Re: QEMU v4.0.0 released

#115
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,forma…

There's not really much choice than trying to use qemu command line directly on windows. I didn't find any single useful GUI that was usable or newer than 3 or 4 years ago. It's a pretty sad state of affairs. I spend hours until I discovered that I needed to add some magic flag called machine for acceleration even work.

Re: QEMU v4.0.0 released

#116

Anybody here using QEMU? What is your use case?

We use it with a wrapper[1] for continuous testing of an operating system[2]. The wrapper will perform the installation process as users do, then run the testsuite and upload the results. It's nice because it lets us catch regressions in the installation process, too.

[1] - https://www.gson.org/netbsd/anita/

[2] - http://releng.netbsd.org/test-results.html

Re: QEMU v4.0.0 released

#117
post #85
post #21

Earlier quoted context omitted.

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…

About 12 years ago when I had access to Microsoft MSDN I got a big SuperMicro box, set it up with CentOS 4 (RHEL) Linux, and used QEMU/KVM to set up a Windows domain controller and several other Windows VMs, and several Linux VMs, on a couple of virtual subnets, along with iptables port forwarding, Windows Remote Desktop, VNC, and many services. Some of the Linux VMs services authenticated with the Windows domain. I…

So basically what you're saying is RTFM, in a polite fashion :)

Re: QEMU v4.0.0 released

#118
post #114

Earlier quoted context omitted.

Welcome to the Open Source experience... sadly.

As opposed to what? Most proprietary tools don't have good documentation either. And then you may not even be able to look at the code to see what it does.

I don't get why he's downvoted. Virtualbox (which is not proprietary), VMWare, Hyper-V are way easier to use.

That's a fact.

And not many people need to look at the code in real life...

Re: QEMU v4.0.0 released

#119
post #78

Earlier quoted context omitted.

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,forma…

> like running the QEMU process as an unprivileged user, Anyone can run your example "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" from the command line/bash, as non-root user, yet libvirt which requires root to install, and is expecting root to configure it, is bett…

> Libvirt is one of those softwares which ads a layer of complexity for the sake of complexity, yet offers nothing of value in return.

Isn't that sort of like saying the system startup scripts/subsystem adds complexity for the sake of complexity, and you should just use ifconfig and route manually in some script after startup?

In both cases, that you can fall back to the underlying commands is great. That you should use them instead of the normalized interface provided is debatable.

Re: QEMU v4.0.0 released

#120
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…

TBH, I tend to give up on the accelerated video drivers on Windows inside of virt-manager. It is often easier to just use RDP for basic office applications.
Post reply on HN