Packer: [Feature] Add remote target support for QEMU builder

[stdevel]

As far as I understood from the documentation, the QEMU builder does not support remote hosts running KVM/QEMU.
This means, you will need to run Packer on that host that also runs KVM.
It would be very useful to have the possibility to specify a hypervisor host and have Packer to connect to it via SSH (like the vsphere-iso builder).

[SwampDragons]

Thanks for this suggestion! The QEMU builder one of our community-supported builders, which means that the HashiCorp maintainers don't spend much engineering time on it; this means that the best way to see your suggestion make it into Packer is to open a PR.

[vtolstov]

some time ago (2 years may be) i'm try to write libvirt builder. but it incomplete, but possible to use any libvirt enabled host.

[stdevel]

That sounds great @vtolstov - maybe you could share the code so that somebody else can continue your work?

[vtolstov]

@stdevel https://github.com/vtolstov/packer-builder-libvirt as you see i'm write it in 2015 =).
Main question for me: how to provision vm, i think about creating tcp network and use it.. but may be now i can use something different.

[tormath1]

Hey, I'd really like to see this feature !
From libvirt / virsh you can easily target a remote KVM by giving the remote qemu URI (ex: virsh -c qemu://toto@url/system).
So we could think to a similar approach with packer

...
"builders": [
    {
        "type": "qemu",
        "qemu_uri": "qemu://toto@remote/system"
    }
]

By default qemu_uri will be set to qemu:///system in order to not break compatibility. What do you think ?

EDIT: I've been through the code to see how it looks like. The magic for qemu is there:

cmd := exec.Command(d.QemuPath, qemuArgs...)

We are using directly the qemu binary d.QemuPath, AFAIK there is not support for qemu remote call. IMO the only way to support remote target should be to run this command through an SSH remote connection. We could use libvirt but we need to mass refactoring the builder and libvirt needs to have libvirt system dependencies in its runtime.

[stdevel]

Happy to hear your thoughts @tormath1,
that's a great idea.

But - somebody needs to implement it and unfortunately I've never been coding in Go 😄

Would you be able to help us?

[tormath1]

Sure, I could give a try this weekend!

[tormath1]

So, this is my plan:
In the builder configuration, we should add this fields:

• ssh_host: the URL of the remote target (with qemu installed on it)
• ssh_port: SSH port (22 by default)
• ssh_username: username for SSH connection

One of them:

• ssh_password: password of the username
• ssh_key_file: path to you your SSH private key

Now we need to handle some points with the minimum changes:

• vnc at the boot: I guess we could route VNC through SSH tunnel
• SSH commands: SSH over SSH
• every qemu commands will be pass through SSH, so it's not a problem.
• how to deal with QMP ?

[vtolstov]

sorry, but for me using ssh and qemu is the bad way. my idea when i'm create libvirt builder, to use abstracting over qemu command lines and use high level of control via libvirt.
for libvirt we don't need external deps, as i can use digitalocean/go-libvirt native package.
(I known that it not have agreement from libvirt devs, but it works fine for me and not need CGO and other deps)

[tormath1]

@vtolstov I know it's not the best idea. However, qemu builder is designed around qemu binary himself. Two options:

• refactor qemu builder in order to use libvirt
• make a new builder kvm / libvirt

[vtolstov]

My code that I'm share libvirt builder

вс, 21 июл. 2019 г., 15:18 Mathieu Tortuyaux [e-mail]:

@vtolstov https://github.com/vtolstov I know it's not the best idea.
However, qemu builder is designed around qemu binary himself. Two options:

• refactor qemu builder in order to use libvirt
• make a new builder kvm / libvirt

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/7757?email_source=notifications&email_token=AADVQG33GZFKPEP4Z53PBG3QARHYDA5CNFSM4HYXHP7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2OCDOI#issuecomment-513548729,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADVQG2ZFCJV4QINPGGOKLTQARHYDANCNFSM4HYXHP7A
.

[minhluantran017]

Hi @vtolstov ,
I'm interested in your 'remote libvirt' builder. Could you please give me some instruction on how to configure packer template (or give me a sample template) to try this builder?
It would be great to make the new 'libvirt' community builder.

Thanks in advanced.

[tormath1]

hi @minhluantran017 ,
The solution of @vtolstov it's a bit outdated, I'm not sure it will work with current packer version. However, it's funny you necrobump this issue since I started one week ago libvirt implementation of packer builder: https://github.com/tormath1/packer-libvirt. It's not yet functional (it only creates a pool aha)
Feel free to start / watch the repo, you'll be notified of the first release when it will be available.

@vtolstov we could maybe try to merge our work / upgrade your builder if you still interested to maintain it. Just let me know :wink:

[vtolstov]

i'm interest to maintain it, my main problem with communication channel. i want to as libvirt can be run with nat default network not so easy to connect to it. i think about userspace networking for such case

[vtolstov]

so if someone want to help, i can update it to work with latest packer

[minhluantran017]

Hi @vtolstov , @tormath1 ,
It's great to here your work still up. I don't have any background on Go, but found this when working with Terraform: https://github.com/dmacvicar/terraform-provider-libvirt

Hope this builder will be done, I can be a tester if needed (lol).

[tormath1]

@vtolstov

so if someone want to help, i can update it to work with latest packer

I'd like to help. In the builder that I've started, I've implemented a driver interface in order to ease testing + avoid libvirt connection creation at each step. It could be nice to add it to your builder. What do you think about creating an issue to list things to update / improve on your repo ?