search

lavabit / robox

The tools needed to robotically create/configure/provision a large number of operating systems, for a variety of hypervisors, using packer.
626 stars 139 forks source link

Emphasizing qemu provider #163

Open mcandre opened 4 years ago

mcandre commented 4 years ago

With macOS and Windows beginning to shift to ARM, can we get more guest support for qemu providers? Otherwise, many x86 boxes may become unusable.

djdanielsson commented 10 months ago

qemu would be nice because there is a working provider for M1/2/3 Macs now and this doesn't require a payed tool like Paralles.

ladar commented 10 months ago

Hi @mcandre @djdanielsson ... someone came through with an ARM server, so I've working overtime the past few weeks to update all of the Robox automation to be "arch" aware, and I've started working adding a select handful of ARM box configurations to the pipeline. I haven't started uploading them yet.

All of that said,, the ARM server I was provided does not have an M1/M2/M3 and its running Linux. Which means I will only be creating libvirt boxes for ARM, at least in the near term (unless someone steps up and donates a Mac mimi with an M1/M2 chip). Which means I have no plans for adding VMWare / VirtualBox or Parallels ARM boxes, as those providers only provide ARM support on MacOS (with an M1/M2/M3 chip).

@djdanielsson what caught my attention was your reference to qemu boxes. Technically libvirt boxers are created using QEMU and intended to run on QEMU. So I wasn't sure if you actually meant I should add support for the qemu Vagrant plugin.

I looked into that plugin a very long time ago and but didn't pursue it at the time because the plugin didn't offer much, and it didn't seem like anybody was using it (same goes for the lxc/lxd Vagrant plugins). Has that changed?

And if I were to add support, would it simply be uploading the same box file I'm already creating for libvirt, only I'd tell the cloud it's for the qemu provider? Or do I need to add an export directive to Packer which creates a distinct box file for QEMU?

I presume that even if distinct box files are required, I can use the same virtual machine, I just need to export it twice? The export step involves a lot of compression and disk I/O, which means a big server load for several minutes (which can cause a parallel build to fail, and is why I limit the robots to only build 2 parallel builds). And while a few minutes might not sound like much, there are currently 107 generic libvirt box configs being built (more if you add the Lineage/Magma versions).

thoughts? Did you really mean to say libvirt?

the libvirt configs, ARM configs for some of the libvirt box config a select handful of the libvirt boxes.

djdanielsson commented 10 months ago

I will be honest I do not have much experience with packer or vagrant to answer that, most of my time with hashi products has been in vault and terraform. I was trying to find some examples of the packer files that people have used to create some of the images that are in the registry but so far I haven't been able to find any to see if there is any difference or not.

djdanielsson commented 10 months ago

I ran across this https://github.com/ppggff/vagrant-qemu#box-format which looks to say that it is basically the same so you might be able to publish the same box as qemu in the cloud. I can test if a box works if you want to try this sometime before adding that change to your pipeline.

djdanielsson commented 7 months ago

not sure if this will help any or not https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/