Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export QEMU command can't be executed #3744

Closed
dylanmc opened this issue Mar 10, 2022 · 6 comments
Closed

Export QEMU command can't be executed #3744

dylanmc opened this issue Mar 10, 2022 · 6 comments

Comments

@dylanmc
Copy link

dylanmc commented Mar 10, 2022

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

  • UTM Version: 3.1.3
  • OS Version: 12.2.1
  • Intel or Apple Silicon? - M1Max

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
Copy link
Contributor

osy commented Mar 10, 2022

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.

@osy osy closed this as completed Mar 10, 2022
@dylanmc
Copy link
Author

dylanmc commented Mar 10, 2022

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

@osy
Copy link
Contributor

osy commented Mar 10, 2022

#2280 will be implemented in the next update

@jamesmortensen
Copy link

jamesmortensen commented Jun 23, 2022

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
Copy link

mietzen commented Jul 6, 2022

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
Copy link
Contributor

osy commented Jul 6, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants