[libvirt] RFC: Extending UEFI XML specification

[Prerna]

On Wed, Mar 28, 2018 at 4:41 PM, Peter Krempa <pkrempa at redhat.com> wrote:

> 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.
>
>
Agree, I'd missed it while writing up, but I intended <source> to cover
this.


> > <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>
>
>
Yes, this would be required for uniformity. But this would inadvertantly
break the existing XML description for local files. So I was not sure if
this would be acceptable.



> 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.
>
>
You probably meant qemu-nbd? But other backends such as gluster/iSCSI may
not just work with that.
Were you describing some other scenario ?


> > I would like to capture thoughts from the community to extend the current
> > firmware spec.
> >
> > Regards,
> > Prerna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180328/f309b5a8/attachment-0001.htm>