search

utmapp / UTM

Virtual machines for iOS and macOS
https://getutm.app
Apache License 2.0
27.03k stars 1.34k forks source link

Export QEMU command can't be executed #3744

Closed dylanmc closed 2 years ago

dylanmc commented 2 years ago

Describe the issue I discovered this feature via this issue, by searching for "headless qemu UTM". I tried it out, on a simple VM that works fine when launched by UTM, but the command it exported didn't work.

First, the command issued an argument with a path to a non-exist terminal file/device:

qemu-system-aarch64: -chardev pipe,id=term0,path=/Users/<me>/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/8169C503-2646-4317-BE65-7F931B70884F.terminal: Could not open '/Users/<me>/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/8169C503-2646-4317-BE65-7F931B70884F.terminal': No such file or directory

I found that there was a pair of files ending in .terminal.in and .out in that directory, so I tried editing the command to refer to the ...terminal prefix instead, and got this error:

qemu-system-aarch64: -chardev spicevmc,name=usbredir,id=usbredirchardev0: 'spicevmc' is not a valid char driver name

Thinking that perhaps the qemu-system-aarch64 command UTM uses has added new drivers, I looked for the one run by UTM (by examining the output of ps auwwx, and found this one: /Applications/UTM.app/Contents/Frameworks/qemu-aarch64-softmmu.framework/Versions/A/qemu-aarch64-softmmu, but when I try to run that command, I get zsh: exec format error. At this point I decided to chime in here.

Configuration

Here's the complete (anonymized) exported command:

qemu-system-aarch64 -L /Applications/UTM.app/Contents/Resources/qemu -S -qmp tcp:127.0.0.1:4444,server,nowait -nodefaults -vga none -nographic -chardev "pipe,id=term0,path=/Users/<me>/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/E3459327-D6AC-409C-ABCA-08EAAC345F57.terminal" -serial chardev:term0 -cpu host -smp cpus=8,sockets=1,cores=8,threads=1 -machine virt,highmem=off -accel hvf -accel tcg,tb-size=256 -drive if=pflash,format=raw,unit=0,file=/Applications/UTM.app/Contents/Resources/qemu/edk2-aarch64-code.fd,readonly=on -drive "if=pflash,unit=1,file=/Users/<me>/Downloads/Debian ARM.utm/Images/efi_vars.fd" -boot menu=on -m 1024 -device intel-hda -device hda-duplex -name "Debian ARM" -device nec-usb-xhci,id=usb-bus -device usb-tablet,bus=usb-bus.0 -device usb-mouse,bus=usb-bus.0 -device usb-kbd,bus=usb-bus.0 -device qemu-xhci,id=usb-controller-0 -chardev spicevmc,name=usbredir,id=usbredirchardev0 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0 -device virtio-blk-pci,drive=drive0,bootindex=0 -drive "if=none,media=disk,id=drive0,file=/Users/<me>/Downloads/Debian ARM.utm/Images/debian.qcow2,cache=writethrough" -device usb-storage,drive=drive1,removable=true,bootindex=1,bus=usb-bus.0 -drive if=none,media=cdrom,id=drive1 -device rtl8139,mac=26:31:64:F0:F0:28,netdev=net0 -netdev user,id=net0 -uuid 8169C503-2646-4317-BE65-7F931B70884F -rtc base=localtime
osy commented 2 years ago

Hi, sorry for the confusion but the command isn’t meant to be executable. You’re right in that we’ve made changes to QEMU so it won’t work as-is. That option is meant purely as a debugging/support mechanism to determine what’s happening “under the hood”. Advanced users can pick and choose the arguments they care about (say path to the disk image) but that’s about it.

dylanmc commented 2 years ago

Aha, so the "running UTM headless" pointers that lead to that feature were a red herring. Understood.

osy commented 2 years ago

2280 will be implemented in the next update

jamesmortensen commented 2 years ago

Hi, sorry for the confusion but the command isn’t meant to be executable. You’re right in that we’ve made changes to QEMU so it won’t work as-is. That option is meant purely as a debugging/support mechanism to determine what’s happening “under the hood”. Advanced users can pick and choose the arguments they care about (say path to the disk image) but that’s about it.

Hi @osy would it be possible to modify the export QEMU command so that it uses the QEMU built by UTM? I have successfully migrated UTM VM's to QEMU, but it involves pulling out some of the options that the upstream QEMU complains about. It would be great if it were seamless. Thank you!

mietzen commented 2 years ago

Hi, sorry for the confusion but the command isn’t meant to be executable. You’re right in that we’ve made changes to QEMU so it won’t work as-is. That option is meant purely as a debugging/support mechanism to determine what’s happening “under the hood”. Advanced users can pick and choose the arguments they care about (say path to the disk image) but that’s about it.

Hi @osy would it be possible to modify the export QEMU command so that it uses the QEMU built by UTM? I have successfully migrated UTM VM's to QEMU, but it involves pulling out some of the options that the upstream QEMU complains about. It would be great if it were seamless. Thank you!

Or that it sanitises the call to work with vanilla QEMU?

osy commented 2 years ago

Hi, commenting on a closed issue isn't recommended because it's unlikely to be seen. For the future, open a new discussion and feel free to tag me. Regarding the command export, it is provided mostly for as a debugging tool and for advanced users. There isn't an easy way to "sanitize" the output because we use a fork of QEMU with extra features, devices, etc. It is quite easy to manually strip those options when QEMU complains about it so it doesn't make sense to add a new option for 0.001% of the users who need to have that done for them.