[libvirt] RFC: Extending UEFI XML specification
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
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
On Wed, Mar 28, 2018 at 4:41 PM, Peter Krempa <pkrempa@redhat.com> 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
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/
On Wed, Mar 28, 2018 at 16:15:50 +0530, Prerna wrote: pflash 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
On Wed, Mar 28, 2018 at 17:55:59 +0530, Prerna wrote:
On Wed, Mar 28, 2018 at 4:41 PM, Peter Krempa <pkrempa@redhat.com> wrote:
On Wed, Mar 28, 2018 at 16:15:50 +0530, Prerna wrote:
[...]
<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.
Not necessarily. You can always remember whether the parser has seen the old description or the new one and the formatter will then format the old or new one from the data according to the flag.
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 ?
No, I in fact meant qemu-img as a tool which can be used to copy the template file while provisioning the <nvram> image. qemu-img's convert functionality will copy the image to any destination that qemu supports. I'm not saying it has to be implementer right away, I just used it as a example that it depends on the implementation whether the template file is supported for a given hypervisor/storage.
On Wed, Mar 28, 2018 at 13:11:11 +0200, Peter Krempa 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.
<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>
Also since we'll be implementing this we should also add a format attribute so if the user wishes, the pflash drive can be backed by a qcow2 image.
participants (2)
-
Peter Krempa -
Prerna