Windows 10: Add VirtualBox, KVM CI

[qmfrederik]

This PR adds CI for the Windows 10 packer image for the VirtualBox and KVM builders.

• VirtualBox images can be built with Azure Pipelines. Support for using VirtualBox on the macOS instances in Azure Pipelines/GitHub actions has been added recently
• Travis supports KVM nested virtualization for their Bionic environments (which get routed to GCE which supports nested virtualization).
  • There's a default timeout of 50 minutes for Travis jobs; you can extend this to 120 and 180 minutes by sending an e-mail to [email protected]
  • Travis jobs will also time out on 'log silence' (e.g. nothing printed to stdout/stderr for more than 10 minutes), so there's a background job which just writes a message to stdout every 9 minutes

Other environments should be easy to add; if you decide to enable CI in this repo, I can send up a follow up PR for Windows Server and Windows 7 or 8.1

[StefanScherer]

Oh that's really interesting that you can run packer on just some CI machines 👍

I'm not sure if I want to actually build images here. My use-case is for VMware, and I use a different repo packer-builder for that from time to time. It costs a bit of money as I use baremetal machines on demand.

[qmfrederik]

So, as a sidenote, #281 and #282 have regressed/broken building QEMU images.

They reacted to a recent change in packer, where specifying -drive arguments in qemuargs would replace the default drives generated by Packer, rather than adding new drives. (I think this was caused by packer-plugin-qemu/commit/4a5c5ce817795d1d1134fdb6fbf7f988088e0ef9, but not sure).

However, the fix used was to specify:

        [
          "-drive",
          "file={{ user `iso_url` }},media=cdrom,index=2"
        ],

which would mount an ISO file over HTTP. This is probably not a good idea, and the remote server does not support it. It causes the Packer build to fail like this:

qemu-system-x86_64: -drive file=https://software-download.microsoft.com/download/sg/19043.928.210409-1212.21h1_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_en-us.iso,media=cdrom,index=2: CURL: Error opening file: Server does not support 'range' (byte ranges).

For now, I worked around this by reverting those changes and using an older Packer version (1.6.0).

I guess it demonstrates that having CI to validate changes to the .json files may be useful :-).

[StefanScherer]

Hey @qmfrederik
Thanks again for your PR. ❤️
Yes, I agree that having CI gives feedback and helps avoiding regression.
But on the other side as a maintainer who doesn't use QEMU at all I'm hesitant of adding more and more things to this repo. That's the hard decision to say "no" to some things, just to avoid future maintenance cost/time. And even waiting for CI results or fixing some minor things are additional time that "costs" something.

The CI can also be activated in forks. So what I could think of is to merge your PR to have the yml files in the repo, and also follow up PR's to fix KVM/QEMU configuration sections. But I'm not planning to activate the additional CI in this repo here, because I wouldn't take care of it/wait for it when I merge PRs for other things.

I understand this is a difficult topic when PRs don't get merged easily. I already accepted the first KVM/QEMU PR's to be kind, now I have to live with follow up fixes. I'm trying to find a way that keeps me out of the loop for such other builders.

What do you think? Would that work for you if you run the CI in your fork?

[manics]

I've had similar issues with complicated CI workflows in other repos. One idea I've had is to create a repo just for the extra CI workflows, e.g. packer-windows-ci-qemu:

• packer-windows is a submodule
• dependabot is configured to automatically open PRs to update the submodule
• extra CI workflows are included in this repo

I haven't actually tried this yet, but I think it'd be easier than manually maintaining a fork since dependabot will do most of the work.

[rautends]

i think, that should _libvirt.box

[rautends]

i think, that should _libvirt.box

[rautends]

What do you think? Would that work for you if you run the CI in your fork?

@StefanScherer i don't think that's the right way because it limits the growth of the project.
simply allow to maintain @qmfrederik the repo / pipelines, if you/he is still interested in.
so the development can driven by two persons.