Re: [libvirt] RFC: Extending UEFI XML specification
On Wed, Mar 28, 2018 at 17:55:59 +0530, Prerna wrote:
On Wed, Mar 28, 2018 at 4:41 PM, Peter Krempa
<pkrempa(a)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.
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)