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

Qemu driver should allow to specify architecture (hard-coded qemu-system-x86_64) #4684

Open
onlyjob opened this issue Sep 16, 2018 · 9 comments · May be fixed by #15510
Open

Qemu driver should allow to specify architecture (hard-coded qemu-system-x86_64) #4684

onlyjob opened this issue Sep 16, 2018 · 9 comments · May be fixed by #15510
Labels

Comments

@onlyjob
Copy link
Contributor

onlyjob commented Sep 16, 2018

Currently hard-coded qemu-system-x86_64 severely undermines usefulness of Qemu driver.
It would be useful to be able to run arm images on x86_64 architectures through qemu-system-arm executable, etc.

Please allow to specify qemu architecture in config.

@onlyjob
Copy link
Contributor Author

onlyjob commented Sep 26, 2018

It would be great to get some attention here please.
This issue is not only limiting how Qemu could be used on x86_64 but also makes Qemu driver useless on all architectures other than x86_64.
On Debian Nomad is built for 10 hardware architectures - all of them have Qemu as well...

@nickethier
Copy link
Member

Hey @onlyjob

I'm doing some refactor work on drivers for the upcoming release. I will see if I can take care of this during that work. Thanks for reporting.

@nickethier nickethier self-assigned this Sep 26, 2018
@onlyjob
Copy link
Contributor Author

onlyjob commented Nov 7, 2019

A year passed yet still no progress with this trivial issue even in 0.10.1?

@lanefu
Copy link

lanefu commented Jun 23, 2020

@onlyjob

FYI I was able to perform a workaround with 2 pieces.

  • symlinking the QEMU-arm executable to to QEMU-system-x86_64
  • overloading some arguments to supersede some of hashi's default arguments
 
 args = ["-enable-kvm", "-M", "virt", "-cpu", "host",  "-bios", "/usr/share/qemu-efi-aarch64/QEMU_EFI.fd"]

@XVilka
Copy link

XVilka commented Dec 24, 2021

With the recent growth in popularity of M1-based hardware, ARMv8-based servers, etc this becomes quite important.

@the-maldridge
Copy link

@tgross any updated thoughts on this? Looks like the uniform intel empire may be drawing to a close and it would be great to schedule with ease across arbitrary CPU archs.

@tgross
Copy link
Member

tgross commented Feb 16, 2022

Hi @the-maldridge! Totally agreed, and thank goodness for that! #10035 has a work-in-progress patch for a bunch of QEMU driver refreshes, but we haven't had a chance to wrap that up. I was looking to break it up into smaller patches so we can land a series of incremental fixes but I got sidetracked for the 1.3.0 cycle in finishing up a bunch of outstanding CSI work.

@Amier3 Amier3 added the help-wanted We encourage community PRs for these issues! label Apr 1, 2022
@Esity
Copy link

Esity commented Dec 2, 2022

This is a super easy fix and should be prioritized IMO

CC @wjpatton

@Esity
Copy link

Esity commented Dec 2, 2022

this sounds janky but one way you can work around this if running yum/dnf based installs,

ln -s /usr/libexec/qemu-kvm /usr/bin/qemu-system-x86_64

@hashicorp hashicorp locked and limited conversation to collaborators Dec 6, 2022
schmichael added a commit that referenced this issue Dec 9, 2022
Fixes #4684

This contains 3 changes to the qemu driver:

1. Adds a `binary_path` plugin configuration parameter for specifying
   alternative binary locations for qemu.
2. Defaults `binary_path = "qemu-system-ARCH"
3. Replaces ARCH in `binary_path` with the Nomad binary's GOARCH.

This should allow qemu to Just Work on non-x86_64 architectures like
Apple's M1/M2 or MIPS if... I honestly don't know why you'd be using
this on MIPS but it's a target both Go and QEMU support!

The `ARCH` replacement is ugly, and I had planned on using standard
`${ARCH}` replacement. However that causes it to be handled by our HCL
parser which fails with:

```
==> Error starting agent: failed to create plugin loader: failed to initialize plugin loader: parsing plugin configurations failed: 1 error occurred:
        * plugin "qemu" (driver): failed to parse config:  Variables not allowed: Variables may not be used here.
```

This is returned from `hclutils.ParseHclInterface`, and I'm not sure
it's worth fighting that battle.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants