On Wed, Mar 28, 2018 at 4:41 PM, Peter Krempa <pkrempa@xxxxxxxxxx> 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# ) currently expectselementsOSBIOS
> 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> Since this is as any other storage volume for the hypervisor, you should
> <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.
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> I presume you wanted to add the <source> section here as well.
> <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>
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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
