Bug 2303267

Created attachment 2043603 [details]
guests-all-good.xml

This is the XML file being parsed.

The exact command being run is:

$ virt-alignment-scan -c test://$PWD/test-data/phony-guests/guests-all-good.xml

However when run locally (presumably because with a network connection) it does not fail.

libvirt 10.5.0-2.fc41
libxml2 2.12.8-2.fc41

Other versions as here: https://kojipkgs.fedoraproject.org//work/tasks/2119/121562119/root.log

The network connection bit is probably a red herring. I've just tried
building the package using "fedpkg local" inside a Rawhide container
and it also failed, with many other errors being reported in addition
to this specific one.

From inside the build directory, I can run the command manually and
get the same error:

  # ./align/virt-alignment-scan -c test://$PWD/test-data/phony-guests/guests-all-good.xml
  I/O warning : failed to load external entity "/root/guestfs-tools/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/test-data/phony-guests/guests-all-good.xml"
  libvirt: Test Driver error : XML error: failed to parse xml document '/root/guestfs-tools/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/test-data/phony-guests/guests-all-good.xml'
  ./align/virt-alignment-scan: could not connect to libvirt (code 27, domain 12): XML error: failed to parse xml document '/root/guestfs-tools/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/test-data/phony-guests/guests-all-good.xml'

virsh is similarly unhappy when asked to connect to that test:// URI.
The reason is ultimately very straightforward:

  # ls $PWD/test-data/phony-guests/guests-all-good.xml
  ls: cannot access '/root/guestfs-tools/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/test-data/phony-guests/guests-all-good.xml': No such file or directory

Looking at the build log[1] we can find this:

  /builddir/build/BUILD/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/run: command timed out after 4h
  make[3]: *** [Makefile:992: windows.img] Error 124
  make[3]: Leaving directory '/builddir/build/BUILD/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/test-data/phony-guests'
  make[3]: Target 'guests-all-good.xml' not remade because of errors.

So I don't think there's anything wrong in libvirt specifically, it's
just that it's been asked to load a non-existing file and it can't
really do anything sensible when faced with that request.

You could argue that "no such file or directory" would be a much
better error message than "failed to load external entity", and I
would tend to agree. Unfortunately it looks like that error message
is coming from libxml2, not libvirt, so I don't think there's much we
can do to there either.


[1] https://kojipkgs.fedoraproject.org//work/tasks/2119/121562119/build.log

> You could argue that "no such file or directory" would be a much
> better error message than "failed to load external entity", and I
> would tend to agree. Unfortunately it looks like that error message
> is coming from libxml2, not libvirt, so I don't think there's much we
> can do to there either.

I presume we're in the virXMLParseHelper method at this stage where we do


    if (filename) {
        xml = xmlCtxtReadFile(pctxt, filename, NULL, parseFlags);
    } else {
        xml = xmlCtxtReadDoc(pctxt, BAD_CAST xmlStr, url, NULL, parseFlags);
    }

If so, we could take libxml out of the equation here by calling 'virFileReadAll(filename)' where we have useful error reporting and then we only ever have to use  xmlCtxtReadDoc() in libxml

Thanks for the analysis.  Now I see that the error is in fact caused by
an earlier build failure:

  /builddir/build/BUILD/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/run: command timed out after 4h
  make[3]: *** [Makefile:992: windows.img] Error 124
  make[3]: Leaving directory '/builddir/build/BUILD/guestfs-tools-1.53.2-build/guestfs-tools-1.53.2/test-data/phony-guests'
  make[3]: Target 'guests-all-good.xml' not remade because of errors.

preventing the guests-all-good.xml file from being generated.

Finally I managed to reproduce this using:

$ LIBGUESTFS_BACKEND_SETTINGS=force_tcg fedpkg mockbuild

The hang happens in appliance/init when we are altering the
hard disk schedulers to be noop, and just before we set up
the network, in this code:

for f in /sys/block/{h,s,ub,v}d*/queue/scheduler; do echo noop > $f; done  <-- hangs here
shopt -u nullglob

# Set up the network.
ip addr add 127.0.0.1/8 brd + dev lo scope host

This is actually a new kernel bug, but instead of trying to track it down, I
removed the lines from libguestfs appliance/init.  Patch coming up ...

Upstream bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=219166

Upstream fix:
https://github.com/libguestfs/libguestfs/commit/b2d682a4730ead8b4ae07e5aaf6fa230c5eec305

FEDORA-2024-40b4f44bd1 (libguestfs-1.53.5-4.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-40b4f44bd1

FEDORA-2024-5e40799695 (libguestfs-1.53.5-4.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-5e40799695

FEDORA-2024-40b4f44bd1 (libguestfs-1.53.5-4.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-5e40799695 (libguestfs-1.53.5-4.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.