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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list