Closed kocierik closed 2 years ago
What were the exact commands that you used (1) to create the VM and (2) to launch it? You only posted the output of those commands 😬
sorry! 😬
./quickget ubuntu-mate impish
Now I have the ubuntu iso downloaded!
Darwin Eriks-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0:
Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64
Would that be MacOS Big Sur you are trying to run quickemu
on by any chance ?
Yes
Quickemu is currently only intended for use on Linux workstations. If anyone wants to help add support for running Quickemu on macOS hosts, we welcome PRs 👍
That said, all the requirements from running Quickemu are documented in the README and it seems many are not available on your macOS hosts @kocierik. So, perhaps start with getting the requirements satisfied and see if that improves things for you 🙂
Notes:
spicy/spice-gtk only supports macOS Big Sur as of 2021-12-11.
All of the other available dependencies is available for macOS Big Sur and Monterey on both Intel and Apple Silicon.
[X] qemu (6.0.0 or newer) with GTK, SDL, SPICE & VirtFS support
[X] bash (4.0 or newer)
[X] coreutils
[ ] EDK II
[X] grep
[X] jq
[ ] LSB
[ ] procps
[X] python3
[ ] macrecovery
[X] mkisofs (cdrtools)
[ ] usbutils
[ ] util-linux
[X] sed
[X] spicy
[ ] swtpm
[X] wget
[ ] xdg-user-dirs
[ ] xrandr
[X] zsync
brew install qemu bash coreutils grep jq python@3.10 cdrtools gnu-sed spice-gtk wget zsync
@SebDanielsson Please consider submitting a pull request that adds documentation to the README for getting Quickemu working on macOS.
lscpu is not included in the MacOS version of util-linux
I did some basic work with changing all use other tools instead of: lscpu => sysctl machdep.cpu uname => guname free => sysctl -n hw.memsize
It works for both platforms now to some extent. The issue comes to the qemu flags for various display modes and spice devices, its above my paygrade to get that to work properly. I just commented out everything from the .sh file generated that qemu complained about(gl, and spice devices mostly) and it started but have not done any further tests. If any body wants it(Can continue the work on the qemu flags) i can push it to some temporary branch.
It now works with MacOS host and ubuntu guest. If someone have the means to test it out. Both so i did not break any old hosts and that other guests works on MacOS(They should :)). Here is the fork, say when and ill create a pull request. https://github.com/trollkarlen/quickemu
@trollkarlen I ran a diff on 3.16 vs. your fork (3.14?) and manually patched the current rev. This is the output for EndeavourOS on an M1 Pro running macOS 12.4:
λ quickemu --vm endeavouros-apollo_22_1.conf
ERROR! Public directory: '' doesn't exist!
λ quickemu --vm endeavouros-apollo_22_1.conf --public-dir ~/Downloads
uname: illegal option -- -
usage: uname [-amnprsv]
uname: illegal option -- -
usage: uname [-amnprsv]
uname: illegal option -- -
usage: uname [-amnprsv]
Quickemu 3.16 using /opt/homebrew/bin/qemu-system-x86_64 v7.0.0
- Host: Unknown OS running ()
/usr/local/bin/quickemu: line 254: lscpu: command not found
/usr/local/bin/quickemu: line 255: lscpu: command not found
/usr/local/bin/quickemu: line 256: lscpu: command not found
- CPU:
- CPU VM: Socket(s), 4 Core(s), 1 Thread(s)/usr/local/bin/quickemu: line 312: free: command not found
, 2G RAM
ERROR! EFI boot requested but no EFI firmware found.
Please install OVMF firmware.
λ quickemu --vm endeavouros-apollo_22_1.conf --public-dir ~/Downloads
ERROR! Requested sdl display, but only cocoa avalible on MacOS.
λ quickemu --vm endeavouros-apollo_22_1.conf --display cocoa --public-dir ~/Downloads
Quickemu 3.16 using /opt/homebrew/bin/qemu-system-x86_64 v7.0.0
- Host: Unknown OS running Darwin 21.5 (mbp)
sysctl: unknown oid 'machdep.cpu.vendor'
- CPU: AppleM1Pro
- CPU VM: 1 Socket(s), 4 Core(s), 1 Thread(s), 8G RAM
- BOOT: EFI (Linux), OVMF (/opt/homebrew/opt/qemu/share/qemu/edk2-x86_64-code.fd), SecureBoot (off).
- Disk: endeavouros-apollo_22_1/disk.qcow2 (16G)
Just created, booting from endeavouros-apollo_22_1/EndeavourOS_Apollo_22_1.iso
- Boot ISO: endeavouros-apollo_22_1/EndeavourOS_Apollo_22_1.iso
- Display: COCOA, virtio-vga, GL (off), VirGL (??)
- ssh: On host: ssh user@localhost -p 22220
- SPICE: On host: spicy --title "endeavouros-apollo_22_1" --port 5930 --spice-shared-dir /Users/lance/Downloads
- WebDAV: On guest: dav://localhost:9843/
- 9P: On guest: sudo mount -t 9p -o trans=virtio,version=9p2000.L,msize=104857600 Public-lance ~/Downloads
- smbd: On guest: smb://10.0.2.4/qemu
- Monitor: On host: nc -U "endeavouros-apollo_22_1/endeavouros-apollo_22_1-monitor.socket"
or : socat -,echo=0,icanon=0 unix-connect:endeavouros-apollo_22_1/endeavouros-apollo_22_1-monitor.socket
- Serial: On host: nc -U "endeavouros-apollo_22_1/endeavouros-apollo_22_1-serial.socket"
or : socat -,echo=0,icanon=0 unix-connect:endeavouros-apollo_22_1/endeavouros-apollo_22_1-serial.socket
qemu-system-x86_64: -accel hvf: invalid accelerator hvf
cat: endeavouros-apollo_22_1/endeavouros-apollo_22_1.pid: No such file or directory
- Process: Starting endeavouros-apollo_22_1.conf as endeavouros-apollo_22_1 ()
---
cat: endeavouros-apollo_22_1/endeavouros-apollo_22_1.pid: No such file or directory
- Process: Starting endeavouros-apollo_22_1.conf as endeavouros-apollo_22_1 ()
Would very much like to see this progressed. @trollkarlen / @pythoninthegrass have either of you considered making a PR to integrate things into the current master branch to get some forward movement on this project?
I've been having some rough times with UTM.app - particularly in creating reliably recreatable virtual machines. It would be incredibly helpful to have a system such as this that utilizes QEMU on macOS to work with various and many operating systems and distributions.
For example, I'm using an Apple Silicon process and recently have had a usecase where I need to use the Intel x86 (32-bit) version of Debian to troubleshoot something. UTM seems to gag every time so far during first boot following setup and it really seems as though this project could facilitate working through such scenarios much more efficiently.
Having QuickEMU at our disposal, as I'm sure you guys can also see value in, would be of incredible value.
In reviewing the list above by @SebDanielsson I noted that the following may be available and/or worked around:
This is not as simple as documenting usage, it requires Quickemu to add macOS host support which is being tracked in #447
@flexiondotorg I think the point, in my mind, with this discussion is to isolate all issues that may be resolvable prior to making PRs that make direct changes to quickemu
... Maybe that's not the case?
I suppose there could be considerations in various elements of quickemu
that should be altered to reduce/remove dependencies?
An example, LSB
is something that would require a direct intervention in terms of changing filesystem locations for macOS tooling, etc. Right?
Similarly xdg
would simply require replacement with macOS specific options, right? Unless one would want to, for some reason, utilize xquartz
to provide this for X11 handling (which probably still could and should be done through open
or some other function so that it's using macOS facilities).
Etc...
Error when I create a vm
Quickemu output
Run
quickemu
orquickget
and paste the output here.Linux Distribution & Kernel