Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QEMU v4.0.0 released

qemu.org

Post reply on HN
Print view View original

131–140 of 168 posts

Re: QEMU v4.0.0 released

#131

Post by oblio »

bonzini wrote: post #121
oblio wrote: post #118

Earlier quoted context omitted.

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...

You should compare VirtualBox to virt-manager or GNOME Boxes, not QEMU, just like you shouldn't compare Visual Studio to gcc.

Yeah, but VirtualBox & co. come as a package. virt-manager and Gnome Boxes, as you can see from the other comments, have been missed by various people trying to use these tools :)

Re: QEMU v4.0.0 released

#132

Post by goykasi »

dperfect wrote: post #111
slig wrote: 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 fo…

Thats sounds pretty interesting. Ive been running a hacked together windows VM gaming setup via qemu with vfio passthrough for the past 1.5 years on my local linux server. Im pretty pleased with it. Ive got it down to simply executing a small script and everything comes up. It could be even more automated using evdev potentially (recognizing mouse/keyboard events).

I was thinking about expanding the setup to include a beefier linux host (more gpus and better hardware) and more seats -- windows gaming for me and osx for my wife. But you mentioned several possible osx specific caveats: amd gpus, clover (?) bootloader w/ dsdt (?), disable_idle_d3, etc. Can you link to some info or READMEs regarding your setup or how you came across these solutions?

Re: QEMU v4.0.0 released

#133

Post by bronco21016 »

MuffinFlavored wrote: post #45
bronco21016 wrote: post #38

Earlier quoted context omitted.

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.

What’s your mouse/keyboard situation like? What remote desktop app do you use? What’s your latency like? What are the drawbacks to a setup like this?

For software I use Jump Desktop. On Linux I connect via VNC and Windows I use their custom Fluid protocol. For keyboard and mouse I use an Anker Bluetooth keyboard and mouse is a Swiftpoint GT.

Latency varies a lot and I’ve found hotel WiFi to sometimes be unusable. ATT LTE on the device generally works pretty well. I’m primarily running this setup just to have access to a full browser environment for my tinkering with web scraping so having a super responsive low latency connection isn’t as vital as it would be to do something like gaming. The main drawback is always needing a solid connection which is mostly solved with LTE where I go.

Re: QEMU v4.0.0 released

#134

Post by nurettin »

bonzini wrote: post #121
oblio wrote: post #118

Earlier quoted context omitted.

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...

You should compare VirtualBox to virt-manager or GNOME Boxes, not QEMU, just like you shouldn't compare Visual Studio to gcc.

I am on my third confusing error using virt-manager to create an armv7 build environment. First one was some ca-cert error, which meant I forgot to type a slash somewhere in some URL, second was something about not being able to enable firewall, which required firewalld and dnsmasq to be installed, now I'm having an error adding a qcow2 image to my vm setup, it probably doesn't like my mounted storage. We can compare this experience to terrible vendor lockins.

Re: QEMU v4.0.0 released

#135

Post by [deleted] »

jolmg wrote: post #122
fulafel wrote: post #79

Earlier quoted context omitted.

There's a lot to be said for running qemu from the command line, vs the complexity and opaqueness of libvirt. For example you can put the invocation in a script and check it into version control, and it will work on anyone's Linux box. You can easily debug the config and be suire about what options qemu was given. Yes, there may be many switches in the invocation, but at least they are in one place, the invocation sy…

You're splitting the option value for -drive into multiple arguments. Here's an idea to fix that while keeping the same style: qemu-system-x86_64 \ -display none \ -m 2048 \ -serial stdio \ -drive "$(printf "%s" file=/export/cirros.qcow2, \ format=qcow2, \ if=virtio )"

[deleted]

Re: QEMU v4.0.0 released

#136

Post by dperfect »

goykasi wrote: post #132
dperfect wrote: post #111

Earlier quoted context omitted.

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 fo…

Thats sounds pretty interesting. Ive been running a hacked together windows VM gaming setup via qemu with vfio passthrough for the past 1.5 years on my local linux server. Im pretty pleased with it. Ive got it down to simply executing a small script and everything comes up. It could be even more automated using evdev potentially (recognizing mouse/keyboard events). I was thinking about expanding the setup to include…

I don't have any specific guides about my setup, but here are a few things that have been helpful to me:

- Good starting point for setting up macOS under QEMU/KVM: https://github.com/kholia/OSX-KVM

- DSDT/SSDT patching: https://www.tonymacx86.com/threads/ssdt-gpu-graphics-card-in...

- AMD reset bug: https://www.reddit.com/r/VFIO/comments/5h351m/gpu_stuck_in_d...

- Kernel extension that can help with some GPU issues: https://github.com/acidanthera/WhateverGreen

The DSDT/SSDT patch was probably the trickiest thing. I've posted my particular patch here if you're interested: https://pastebin.com/ngvkVZYN

Also, a few of my other scripts/config: https://pastebin.com/9Nh5rheZ

Re: QEMU v4.0.0 released

#137

Post by kashyapc »

LukeShu wrote: post #101
kashyapc wrote: post #36

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…

> Once you add `-nodefaults`, the list of arguments grows because now you must add a bunch of things that were there by default [...]

Partly true (refer below).

> If by "minimal command-line" you mean [...]

I appreciate your corrections, but please don't read too much into the word "minimal". I just quickly pasted it from one of the "subjective scripts" named `min-qemu.sh` lying around on my file system. By the time I realized, it was too late to adjust it.

> Most of the devices added by libvirt would be included by qemu automatically if you didn't say `-nodefaults`

Not quite; I just double-checked with an upstream libvirt dev: when you remove `-nodefaults`, some of the built-in devices get removed, whether those equate to "most" or not depends how many devices you've asked for.

> PS: You have too many "t"s in the "htttps://" in one of those URLs.

Yeah, realized too late that there was a typo :-(

Re: QEMU v4.0.0 released

#138

Post by goykasi »

dperfect wrote: post #136
goykasi wrote: post #132

Earlier quoted context omitted.

Thats sounds pretty interesting. Ive been running a hacked together windows VM gaming setup via qemu with vfio passthrough for the past 1.5 years on my local linux server. Im pretty pleased with it. Ive got it down to simply executing a small script and everything comes up. It could be even more automated using evdev potentially (recognizing mouse/keyboard events). I was thinking about expanding the setup to include…

I don't have any specific guides about my setup, but here are a few things that have been helpful to me: - Good starting point for setting up macOS under QEMU/KVM: https://github.com/kholia/OSX-KVM - DSDT/SSDT patching: https://www.tonymacx86.com/threads/ssdt-gpu-graphics-card-in... - AMD reset bug: https://www.reddit.com/r/VFIO/comments/5h351m/gpu_stuck_in_d... - Kernel extension that can help with some GPU issues:…

Thank you for the links. Time to build a new server!

Re: QEMU v4.0.0 released

#139

Post by archi42 »

wyldfire wrote: post #113

QEMU's killer feature is user mode emulation [1]. It's never been easier to test/experiment with cross-target binaries. [1] https://wiki.debian.org/QemuUserEmulation

Exactly! We are using this in our compiler test farm for the quick test runs. Sadly, the release prior to 4.0.0 broke floating point handling of NaN on (at least) PowerPC e5500 :( I'm looking forward to test qemu 4.0.0 once I'm back in the office again.

Edit: Tested it, aaaaaand NaN compares are still broken :(

Re: QEMU v4.0.0 released

#140

Post by shmerl »

Did anyone manage to solve the problem of virgl rendering failing with

    Error starting domain: internal error: qemu unexpectedly closed the monitor
    ....
    libvirtError: internal error: qemu unexpectedly closed the monitor
Post reply on HN