@olivierlambert Sounds like the best way forward would be to add the equivalent of the Hyper-V builder's secondary_iso that mounts a second iso-file, or even better cd_files which creates a temporary iso for you and mounts it.

For anyone who wants to test building eufi machines until this is solved, I have a Powershell script that takes a Windows ISO and generates a new one with files added (in my case autounattend.xml, bootstrap.ps1 and the management agent msi. Though I should change it to just download the msi instead to avoid rebuilding it.)

Since I was building a new ISO anyway, I also changed the boot loader to the noprompt one in order to avoid the timing issues with boot_commands and "Press any key to boot from DVD...."

The script uses oscdimg.exe that's included in the Windows ADK, which can be found here:
https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

# Settings
$Architecture    = "amd64" # Or x86
$InputISOfile    = "D:\Deploy\ISO\Windows Server 2022 Eval.iso"
$OutputISOfile   = "D:\Deploy\ISO\Windows Server 2022 Eval XenServer.iso"
$TempFolder      = "E:\Temp\Win2022XenServer"
$AdditionalFiles = @(
	"C:\files\Autounattend.xml",
	"C:\files\bootstrap.ps1",
	"C:\\managementagentx64.msi"
)

$OSCDIMG_Path = "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools" + "\$Architecture\Oscdimg"

# Check environment
If (!(Test-path $InputISOfile)){ Write-Warning "Input ISO file not found. Exiting";Break}
If (!(Test-path $OSCDIMG_Path)){ Write-Warning "OSCDIMG Path not found. Exiting";Break}
if((Test-Path $TempFolder)){ Write-Warning "Temp folder $TempFolder exists. Exiting.";Break}
foreach($file in $AdditionalFiles) {
	if(!(Test-Path $$file)){ Write-Warning "Additional file $file does not exists. Exiting.";Break}
}

# Mount the original Windows ISO and figure out the drive-letter
Mount-DiskImage -ImagePath $InputISOfile
$ISOImage = Get-DiskImage -ImagePath $InputISOfile | Get-Volume
$ISODrive = [string]$ISOImage.DriveLetter+":"

# Copy ISO contents to temp dir and add additional files
New-Item -Path $TempFolder -ItemType Directory -Force
Copy-Item "$ISODrive\*" $TempFolder -Recurse
if(($AdditionalFiles) -and $AdditionalFiles.Length -gt 0) {
	Copy-Item $AdditionalFiles $TempFolder
}

# Dismount the Original ISO
Dismount-DiskImage -ImagePath $InputISOfile

# Create a new bootable Windows ISO file, based on the Original ISO, but using efisys_noprompt.bin instead
$BootData='2#p0,e,b"{0}"#pEF,e,b"{1}"' -f "$TempFolder\boot\etfsboot.com","$TempFolder\efi\microsoft\boot\efisys_noprompt.bin"
  
$Proc = Start-Process -FilePath "$OSCDIMG_Path\oscdimg.exe" -ArgumentList @("-m","-o","-bootdata:$BootData",'-u2','-udfver102',"$TempFolder\","`"$OutputISOfile`"") -PassThru -Wait -NoNewWindow
if($Proc.ExitCode -ne 0)
{
    Throw "Failed to generate ISO with exitcode: $($Proc.ExitCode)"
}
Get-FileHash -Path $OutputISOfile -Algorithm SHA256
Remove-Item $TempFolder -recurse -force

@ddelnano is probably ultra busy now

Not sure if this is best solved at the Packer level or if it should be intercepted and corrected XCP-ng level?

@olivierlambert Just curious if this is more of a Packer issue or does the solution have to come from the Vates side?

they offer VMware type/like value

@olivierlambert Yes, I am aware & not suggesting you spend money like a drunk sailor!
That is why I said "vmware like value"

Obviously, we'd like to close the gap as fast as possible, but the fact Vates is entirely privately bootstrapped and privately owned means we cannot burn VC's money at the pace of Nutanix for example.

Looking at vSphere ISO docs, there is the option to create cdrom configs and also another option to use cd_files (list of files to place on to a CD that is attached when the VM is booted).

I don't see that option in the XenServer-iso docs.

If Vates (as a company) is going to claim they offer VMware type/like value then Windows can not be a 2nd class citizen in your ecosystem!

Here is what I was able to deduce when this issue came up.

When creating a Windows VM in uefi mode and using the floppy_file option in packer:

1. There is a disk added as "fda"
2. However the fda device is not available as the a: drive or any other drive letter. When booted using bios mode, you can find the fda device by settting drive letter to "a:".

This is likely because uefi typically does not support floppy disks. I believe in VMWare when the floppy_file option was used in UEFI mode, it added the ISO as a DVD drive instead of an FDA.

Not sure if this is best solved at the Packer level or if it should be intercepted and corrected XCP-ng level?

I noted that in the packer file. I was not able to get packers floppy_files working in uefi mode.

@ddelnano might have some insight?

After posting this I ended up building out a sample project and shared on github.
https://github.com/mtcoffee/xcp-ng-packer-examples

Do you have a pkr.hcl for windows that you can share?

Follow up question: Do you have a pkr.hcl for windows that you can share?

Do you have a pkr.hcl for windows that you can share?

I am curious how your handling winrm and autounattend.xml?

@dan89 Glad you figured it out !

Maybe it can be documented in the packer repo. What do you think @ddelnano ?

I'm not a windows expert, but I can do some testing.

Can you show us your pkr.hcl file ?

When setting platform_args you need to define all of them even if you only need to change one.

Since the defaults are

{
    "viridian": "false",
    "nx": "true",
    "pae": "true",
    "apic": "true",
    "timeoffset": "0",
    "acpi": "1",
    "cores-per-socket": "1"
}

I needed to include all of them even though I only needed "viridian": "true". Once I added in the other options the VM booted and the build worked.