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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
