Unable to create EFI Disk on ZFS over iSCSI LIO

[Republicus]

Ive just configured my SAN to run as a PVE node/storage appliance with ZFS over iSCSI as a LIO target.
NFS and iSCSI over RDMA is working well with the exception of adding EFI disks to a VM.

Copying EFI vars image failed: command '/usr/bin/qemu-img convert -n -f raw -O raw /usr/share/pve-edk2-firmware//OVMF_VARS.fd iscsi://10.12.12.100/iqn.2003-01.org.linux-iscsi.pvesan.x8664:sn.ac80drg5766e/6' failed: exit code 1 (500)

The best I have found similar is here @ https://forum.proxmox.com/threads/ovmf-uefi-bios-improvments.26174/ from years ago. A fix was made to resolve that issue but I am now on latest PVE 6.X and experiencing what appears to be the same problems.

A workaround reported in the post linked above by creating the EFI Disk on local storage and moving the disk onto the iSCSI storage works in my case also; albeit with a bit more work...
I was unable to move the EFI Disk via the GUI until I detached and remounted the disk as a non-efi disk, then edit the vm config manually to efidisk0:.

Reporting and hoping some help may resolve this for me and others who may run into this problem.
Thanks!

 

[t.lamprecht]

Hi, can you run the command which failed manually and post any error message?

Seems to be really not possible, but your specific error could be interesting.

 

[t.lamprecht]

I can reproduce it here, seems the fix for bugzilla #2120 was not covering all cases.

 

[Republicus]

Thanks @t.lamprecht I presume you wont need that manually ran anymore.

I had opened a report: bugzill #2395

 

[Republicus]

I've also discovered that while creating a new VM, select OVMF as BIOS, and create the EFI Disk on the LIO iSCSI storage: the creation fails because both disks; it appears to be trying to use the same zvol name.

TASK ERROR: unable to create VM 101 - error with cfs lock 'storage-iscsi-storage2': /dev/raid50vol/pve/zvols/vm-101-disk-0: LUN already exists! at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 241.

If this can be replicated, I don't mind either updating the bug I earlier reported to include this info or creating a new one.