Purpose of the EFI disk?

[Agent92]

After I made the mistake of detaching the EFI disk on one of my VM:s I noticed that it still works as usual. I can boot it and it still uses EUFI. That made me wonder what the purpose of the EFI disk is? I keep seeing in documentation that you need it in order to run OVMF but seems to work fine without it.

I also managed to setup a new CentOS machine using OVMF without an EFI disk.

 

[proxfire44]

What exactly do you mean by EFI disk?

Are you referring to the roughly ~500mb partition that mounts as /boot/efi

 

[Agent92]

In the Proxmox GUI you can add a new device under: Add -> EFI disk.

And you can read the following here: https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines

"In order to save things like the boot order, there needs to be an EFI Disk"

All though I don't seem to have a problem with it not saving the boot order after removing the EFI disk.

 

[dcsapak]

the efi disk contains the EFIVARS which also contains the boot order
if no efidisk is specified, there is a temporary given to the vm on each start of the vm

 

[Agent92]

So there isn't really a big problem to remove a EFI disk and create a new one? I will have to recreate the boot order and perhaps some other things?

 

[podgaysky]

I don’t understand why I need a separate drive for efi vars. Oracle virtual box and KVM+qemu do not use it, everything works and so...

 

[proxwolfe]

so, is it safe to remove it?

If I remove and find that I do need it after all, will I be able to re-attach it?

 

[dcsapak]

so, is it safe to remove it?

this depends on how your guest installs its boot loader... afaik windows puts the efi bootloader into $ESP/EFI/BOOTX64.efi (which is the default fallback path which should always work as a last resort)
but not all guest os' do this
e.g. debian puts it in $ESP/EFI/debian/..., and creates a efi boot entry; which is saved in the efivars

 

[proxwolfe]

Thanks! I am glad I waited with removing it.

Do you happen to know what macOS does?

Bonus question: is the EFI disk necessary (irrespective of where the guest OS stores its EFIVARS, if the VM resides on its own dedicated passthrough raw disk? (Or would the EFIVARS then be stored on the raw disk?

 

[AngryAdm]

What would one do if the EFI disk for a debian system was accidently deleted?

 

[dcsapak]

What would one do if the EFI disk for a debian system was accidently deleted?

create a new one and recreate your boot entries with e.g. efibootmgr

 

[esi_y]

the efi disk contains the EFIVARS which also contains the boot order

I also wondered, why this cannot go to the VMs config payload.

if no efidisk is specified, there is a temporary given to the vm on each start of the vm

When this has been already taken care of.

 

[t.lamprecht]

I also wondered, why this cannot go to the VMs config payload.

What "this", what "payload"? It'd be great if you could at least go for a specific questions if you have to necro-bump old threads...

The whole EFI vars content? An efidisk0 entry pointing at the temporary EFI disk? ...?

The first one doesn't make much sense, as this is used as RW pflash device for qemu, hardly something one wants to back as some base64 encoded value inside a config file.
For the second: Because, as Dominik stated, and you quoted from this old thread already, it's a temporary disk. I.e. PVE cannot automatically figure out which the correct storage would be, as that's a user decision, so a temporary place like /run has to be used, which, as is, makes not much sense to add to the VM config as it's gone on next boot and would then cause errors.

And as the VM wizard requires setting a storage for an efidisk, if OVMF is selected, this is rather an edge case anyway, as it basically can only happen if one uses the API to create VMs, in which case the API usage needs fixing anyway, or switching from SeaBIOS to OVMF after VM creation, in which case the web UI shows a rather prominent "You need to add an EFI disk for storing the EFI settings. See the online help for details." hint.

 

[esi_y]

What "this", what "payload"? It'd be great if you could at least go for a specific questions if you have to necro-bump old threads...

If you want me start new ones, I can, but if I come with the very same question that is still relevant, I don't think that's necro.

I also ask the question interleaved:

The whole EFI vars content? An efidisk0 entry pointing at the temporary EFI disk? ...?

This:

the efi disk contains the EFIVARS which also contains the boot order
if no efidisk is specified, there is a temporary given to the vm on each start of the vm

Payload = the boot order
This = temporary given to the vm on each start of the vm.

And as the VM wizard requires setting a storage for an efidisk, if OVMF is selected, this is rather an edge case anyway, as it basically can only happen if one uses the API to create VMs, in which case the API usage needs fixing anyway, or switching from SeaBIOS to OVMF after VM creation, in which case the web UI shows a rather prominent "You need to add an EFI disk for storing the EFI settings. See the online help for details." hint.

But this is the crux of my question, why even ask for this, why have that "efidisk" for each VM individually. I can just set boot order to QEMU. It would be just another piece of VM config.

 

[t.lamprecht]

But this is the crux of my question, why even ask for this, why have that "efidisk" for each VM individually. I can just set boot order to QEMU. It would be just another piece of VM config.

Ok, with knowing the actual questions answering gets way easier:

You _can_ already specify the boot order for VMs in PVE, independent of OVMF or SeaBIOS, just edit them under the VM's "Options" panel, if the OS is somewhat standard conform and sets up an EFI spec conform loader under $ESP/EFI/BOOTX64.efi it will already work.
But the EFIvars is not just for boot order, it can enroll signatures or a MOK, and even (small) programs that could be used by a VM to boot, e.g. through network or some elaborate scheme. But yes, it's also the place where custom EFI boot entries go, i.e., those that can be set with efibootmgr, or similar tools, on e.g. most modern Linux distros. And some OS or setups have multiple entries directly in there, e.g. if they want to use another intermediate bootloader like GRUB.

So if you just want the boot order then just do not add any EFI disk, but then again using SeaBIOS might be the better fit, well naturally only if the OS is still supporting it.

 

[esi_y]

just do not add any EFI disk

Thanks, this was not obvious.

, but then again using SeaBIOS might be the better fit,

Yes, but.

well naturally only if the OS is still supporting it.

Exactly.

 

[esi_y]

One more thing though, for the record, at least before it's forgotten again.

There's, I suppose, no plan to support storing *just* NVRAM, as in libvirt/qemu/nvram/*.fd style, correct? I can imagine not, since your remark on SeaBIOS.

 

[t.lamprecht]

There's, I suppose, no plan to support storing *just* NVRAM, as in libvirt/qemu/nvram/*.fd style, correct?

I.e., just the read-only NVRAM pflash for the OVMF code but no EFIVARS pflash at all?
No, there are no active plans, but IMO it might be OK to add and opt-out switch for adding an EFIVARS pflash device when using OVMF. Feel free to open a BZ enhancement request if you want, but please do not have any expectation on an implementation timeframe.