Re: [libvirt] RFC: Extending UEFI XML specification

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