[libvirt] [PATCH 1/3] firmware: include arch and features in firmware file list

Richard W.M. Jones rjones at redhat.com
Wed Oct 19 13:13:52 UTC 2016


On Wed, Oct 19, 2016 at 01:18:07PM +0100, Daniel P. Berrange wrote:
> On Wed, Oct 19, 2016 at 01:07:25PM +0100, Richard W.M. Jones wrote:
> > Unfortunately it's a case of so near and yet so far.  You're proposing
> > this essentially static and non-secret data be stored in
> > /etc/libvirt/qemu.conf, which is not readable as non-root.  virt-v2v
> > (which can run as non-root) would still need to store a duplicate copy
> > of the data.
> 
> What does v2v need the mapping data for ?  Any use case needs to be
> addressed via the APIs, not having apps poke at libvirt private
> config files.

Well the use is fairly narrow (and not present in RHEL).  If you use
`-o qemu' mode, then virt-v2v will write a shell script that invokes
qemu directly.  To do this for UEFI guests it needs to know the right
firmware paths to use.

There's also the issue of writing guests out to old versions of
libvirt, but I'm not too worried about that since we could make the
switch after we are sure the minimum version of libvirt supports
<firmware/> everywhere.

Libguestfs itself also uses UEFI paths on aarch64 when backend = direct
to run the appliance.

We could query the data through an API, I suppose, although that
assumes libvirt is present.  Could this information be stored
somewhere outside libvirt?  It's useful for people running qemu
directly.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v




More information about the libvir-list mailing list