On Tue, Jan 04, 2022 at 02:02:57PM +0000, Richard W.M. Jones wrote:
On Tue, Jan 04, 2022 at 10:33:14AM +0000, Daniel P. Berrangé wrote:
> On Thu, Dec 23, 2021 at 11:36:58AM +0100, Laszlo Ersek wrote:
> > Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2034160
> >
> > The first patch extends our current <qemu:commandline> hack, moving the
> > virtio-net-pci device to slot 0x1E, where it is very unlikely to
> > conflict with any libvirt-assigned PCI address.
>
> Remind me why we still need to use <qemu:commandline> ? A need
> for this obviously reflects a failure of libvirt to address the
> libguestfs requirements. Can we fix the root cause here with proper
> XML support for whatever feature is missing.
Laszlo actually fixed this properly in the case we care about (modern
libvirt), if you look at the 3rd patch which went upstream:
https://github.com/libguestfs/libguestfs/commit/5858c2cf6c24b3776e3867eaf...
Ignoring the old libvirt case, the only reason we still need
<qemu:commandline> is to allow us to set TMPDIR accurately.
(Otherwise if you recall we can get a TMPDIR from an unrelated run of
libguestfs that happens to share the same session libvirtd).
Hmm, right so that's originally because of the use of 'snapshot=on'
but IIUC you no longer use that and instead create overlays explicitly.
It is still possible QEMU creates other temporary files, and for
that matter so could libvirtd, but the qemu:arg only affects the
former.
I guess we can't set TMPDIR before calling virConnectOpen because
while that would correctly influence the spawned libvirtd, it
would also influence anything else in the process using libguestfs
in other threads.
This is painful :-( Basically would need ability to pass a
custom TMPDIR for libvirtd into the virConnectOpen call, via
a URI parameter.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|