Open jamesfreeman959 opened 1 month ago
Quick update - if you remove qemuargs
, then the VM boots into UEFI mode, so it appears that these are overriding the efi_boot
parameter. Is this a bug, or did I miss something in the documentation about how this argument interacts with others? I'd argue it's a bug as the TPM related flags are not affects, but if I've misunderstood something please let me know!
QEMU paramters without qemuargs
:
2024/08/02 17:16:14 packer-plugin-qemu_v1.1.0_x5.0_linux_amd64 plugin: 2024/08/02 17:16:14 Executing /usr/libexec/qemu-kvm: []string{"-drive", "file=windows_2022-qemu/WindowsServer2022,if=virtio,cache=writeback,discard=ignore,format=qcow2", "-drive", "file=/home/jamesf_local/.cache/packer/f1379c61c4705c2d66f46d271609fc75e967a5fe.iso,media=cdrom", "-drive", "file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,unit=0,format=raw,readonly=on", "-drive", "file=windows_2022-qemu/efivars.fd,if=pflash,unit=1,format=raw", "-name", "WindowsServer2022", "-netdev", "user,id=user.0,hostfwd=tcp::4357-:5985", "-device", "virtio-net,netdev=user.0", "-device", "tpm-tis,tpmdev=tpm0", "-machine", "type=q35,accel=kvm", "-m", "2048M", "-smp", "2", "-vnc", "127.0.0.1:10", "-chardev", "socket,id=vtpm,path=/tmp/410159575/vtpm.sock", "-tpmdev", "emulator,id=tpm0,chardev=vtpm"}
Hi @jamesfreeman959,
As you noted this is a conflict between the arguments provided in qemuargs
and how the EFI blob is mounted, as you define a -drive
in your config, it takes precedence over everything that the plugin computes, including the EFI blob here, so qemu
defaults to SEABios in this case.
The documentation does specify that For instance adding a "--drive" or "--device" override will mean that none of the default configuration Packer sets will be used.
, but there maybe a misunderstanding regarding what default configuration
means here. The device
and drive
args are computed as part of a getDeviceAndDriveArgs
function, and the EFIvars/OVMFCode are mounted as -drive
(maybe they could be mounted some other way though?) so they are overridden by yours, as you can inspect in applyUserOverrides.
Right now I think the easiest way we can fix this problem is by improving the docs so they declare how the arguments are passed to qemu, so you can bisect more easily why/which argument overrides them, but I'm all ears if you have other suggestions!
Thanks for the report!
Hey there!
Thanks so much for your response - I did see that in the documentation although much later on after reporting the issue. Overall the challenge is:
This necessitates two CDROM drives in Qemu, as you can't add a floppy drive to a Qemu machine in UEFI mode (it throws an error).
What works really well (but isn't documented as clearly) is using cd_files
to build up a supplemental ISO containing the Autounattend.xml
, Virtio drivers, and any other scripts. When you use this in conjunction with iso_url
, you actually get two CDROM drives attached to the VM. The iso_url
drive is first (so D:
) and cd_files
is second (E:
).
This actually solves my problem perfectly and last night I produced my first working VM through Packer per the above requirements. So all the right functionality is there already - but I found out through trial and error about how to create two CDROM drives on the VM. I don't know if you can drop in an application note, or add a note to the two parameters I've mentioned here about how they work together? Just a few thoughts - happy to help contribute if I can!
Hey @jamesfreeman959,
Good to know you managed to make your case work!
Regarding cd_files
/floopy_files
that's interesting, I didn't know that floppy was unsupported with UEFI, that might be a good idea to add a note to the attribute pointing to cd_files
in this case, though I think they're inherited from the SDK so it could be slightly touchy to add the note in the right place, but it may be possible to hint at it at least.
If you're willing to submit a PR to add something like this please feel free to do so, we'll review it ASAP, and provide suggestions if we have an idea on how to improve the docs; otherwise I'll add this to my TODO list and revisit it when possible.
Thanks for the update!
It'd be nice if cd_files property were a default property from packer that all providers then would inherit or at least it should be a standard for all providers that it makes sense for. I've only seen it in the qemu and hyper-v iso builders. much like floppy_files is pretty standard for all builders. UEFI drops support for floppy disk drives and newer OS's are scanning cdrom drives for automation files for cloud init or windows autounattend.xml. I opened an issue in parllels plugin repo along the same lines https://github.com/Parallels/packer-plugin-parallels/issues/102
Overview of the Issue
I am trying to produce a proof of concept based around Windows Server 2022 (eval) but booted in UEFI mode with a vTPM. My source system is RHEL 8.10 but I can test on newer systems if that helps. All permutations of the build file are booting into SeaBIOS, and there are no errors I can see in the output of packer with
PACKER_LOG=1
set. It's almost like theefi_boot
parameter is being ignored.Reproduction Steps
packer build
Plugin and Packer version
Packer v1.11.2
Simplified Packer Buildfile
Operating system and Environment details
RHEL 8.10 host machine on AMD64 architecture. OVMF files installed and verified as present.
Log Fragments and crash.log files