Hi Michal,
The <loader>,<nvram> tags of os element in domain XML (
https://libvirt.org/formatdomain.html#elementsOSBIOS) currently expects
absolute path of the local file which would be used to back the the pflash
disk representing the non-volatile RAM:
<loader readonly='yes' secure='no'
type='rom'>/usr/lib/xen/boot/hvmloader</loader>
<nvram
template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/nvram/guest_VARS.fd</nvram>
However, given that for virtualized environments, it is possible that the
VM could be started on different hosts at various points in time, and so we
need to expose the firmware/nvram tuple over a network device so as to be
accessible from various hosts.
I propose extending of the existing config by adding a new element,
"backing". This could be one of :
- 'file': for local filesystem paths
- 'network': for network-attached storage.
As an example:
<loader readonly='yes' secure='no' type='rom' backing =
'file'>/usr/share/OVMF/OVMF_CODE.fd</loader>
<nvram backing='file'
template='/usr/share/OVMF/OVMF_VARS.fd'>/var/lib/libvirt/nvram/guest_VARS.fd</nvram>
For network-attached storage:
<loader readonly='yes' secure='no' type='rom' backing =
'network'>/usr/share/OVMF/OVMF_CODE.fd</loader>
<nvram backing='network'>
<source protocol='XXX' name='YYY'>
<host name='x.x.x.x' port=xxxx/>
</source>
</nvram>
Note that 'template' attribute in NVRAM should be explicitly disallowed for
backing type "network". This is because libvirtd may not be able to access
the backing store to copy the contents of the template.
I would like to capture thoughts from the community to extend the current
firmware spec.
Regards,
Prerna