Add support for libvirt provider

[cserby]

I'd like to use the windows10 images built from this repository, but due to licensing issues I'd prefer to use libvirt/QEMU instead of VirtualBox.

[gusztavvargadr]

@cserby thanks for raising this. I cannot promise and actual timeline but will try to look into this in an upcoming release.

[JFrandon]

This would help us a lot as well, is there any way we could help?

[gusztavvargadr]

@JFrandon thank you for reaching out. I'm looking into this in one of the upcoming releases. I don't have an exact timeline yet, but I am making good progress with upgrading to Packer's HCL format and having a proper build matrix, after which I can pick this up.

Please let me know in the meantime which box(es) you'd prefer to have first, so I can prioritize those.

[cwegener]

I'm very curious about this feature. I did a very dirty hack myself to get something up and running locally with some manual intervention. I was using the qemu builder in packer to create the images that I needed to run on vagrant libvirt provider and it did work.

(I was mainly focusing on the Windows Server & Windows Server Core images - ws2022s and ws2022sc respectively)

[gusztavvargadr]

@cwegener @JFrandon if you have some approaches to share (like patches or PRs, or even some docs on how you use this) that could be some help. I am acticely using the providers this repo builds for at the moment (VirtualBox, VMware, Hyper-V), but have less experience with qemu / kvm.

Also, I will need to have reliable, on-demand agents to build the boxes later in a stable way, so any suggetions on typical setups are also welcome. Currently I use Azure and a bare-metal provider to build the images, but adding more providers will have some cost implications as well (compute and bandwidth) that I need to explore first.

[cwegener]

Unfortunately in my case it all was a bit of a one-off situation, so I didn't really put any effort into making it all work properly. I had to do a bit of manual hand-holding in order get the image built with the qemu builder.

If I get to make some time to revisit my approach, I'll take some notes and share them.

[gusztavvargadr]

@cwegener thanks anyway. I'm working on upgrading the templates to HCL2 so it would be ideally easier to make experiments and changes and maybe I can easily include qemu too.

[cwegener]

@cwegener thanks anyway. I'm working on upgrading the templates to HCL2 so it would be ideally easier to make experiments and changes and maybe I can easily include qemu too.

The main design problem that I ran into was that the Cake files seem to be very strictly structured around the fact the there will always be two different builder plugins. One builder plugin that is specifically for building from ISO and a separate builder plugin that is specifically used for cloning from existing VMs. That distinction of plugins is true for HyperV and Virtualbox.

But it is not true for QEMU. There is only one QEMU builder plugin and the same plugin is used for both tasks, building from ISO and cloning from existing VM disks.

If there is an easy way around this problem using the current Cake file structure, I could probably give the QEMU variant another go.

[gusztavvargadr]

@cwegener thanks for the details. I am trying to move away from that strict Cake-based setup with the HCL2 upgrade, where there are a lot more built-in options to extend the core templates, which was not possible in the old JSON-based world. After this upgrade ideally the addition of new providers would be a lot more simpler, not requiring this custom setup I have at the moment.