On Wed, Mar 28, 2018 at 16:15:50 +0530, Prerna wrote:
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.
Since this is as any other storage volume for the hypervisor, you should
treat it as a virStorageSource, including the 'block' and 'volume'
types.
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>
I presume you wanted to add the <source> section here as well.
<nvram backing='network'>
<source protocol='XXX' name='YYY'>
<host name='x.x.x.x' port=xxxx/>
</source>
</nvram>
In addition to this we should also support the 'storage-source' like
definition for backing='file' too:
<nvram backing='file'>
<source file='/path/to/blah'/>
</nvram>
With that encryption of the image can be defined as well.
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.
This should be hypervisor-defined. While it will not be easy, you can
use qemu-img in the qemu driver to populate network disks via the
'convert' command.
I would like to capture thoughts from the community to extend the
current
firmware spec.
Regards,
Prerna