Bug 2168578
| Summary: | use q35 machine type for libguestfs appliance | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Sandro Bonazzola <sbonazzo> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | YongkuiGuo <yoguo> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | CentOS Stream | CC: | bstinson, jwboyer, lersek, qzhang, rjones, virt-maint, ymao, yoguo |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libguestfs-1.50.1-4.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-11-07 08:24:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sandro Bonazzola
2023-02-09 12:40:43 UTC
Is there a reason to use the direct backend? The default (on RHEL) uses libvirt and is much more secure. The direct backend should only be used temporarily in case there are problems with libvirt. Pushed a patch to the build system to stop using it here: https://github.com/oVirt/ovirt-appliance/pull/115/files Comments there were pointing to some issues we saw in the past, hopefully they got solved by then. Nevertheless, especially if direct is going to be used only in an emergency, I think it should use a supported machine type, not a deprecated one. (In reply to Richard W.M. Jones from comment #1) > Is there a reason to use the direct backend? The default (on RHEL) > uses libvirt and is much more secure. The direct backend should only > be used temporarily in case there are problems with libvirt. Apparently without direct backend we have still a bug: https://github.com/oVirt/ovirt-appliance/actions/runs/4134571041/jobs/7145869311#step:6:53 libguestfs: libvirt version = 8010000 (8.10.0) libguestfs: guest random name = guestfs-wmy9j07x4smwjs4k libguestfs: connect to libvirt libguestfs: opening libvirt handle: URI = qemu:///system, auth = default+wrapper, flags = 0 libvirt: XML-RPC error : Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory libguestfs: error: could not connect to libvirt (URI = qemu:///system): Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory [code=38 int1=2] libguestfs: trace: launch = -1 (error) This is a libvirt bug (of sorts). After installing libvirt the services are somehow not available. I worked around this in my tests by doing: https://src.fedoraproject.org/rpms/virt-v2v/blob/rawhide/f/tests/basic-test.sh#_10 Of course using direct mode is valid to work around libvirt bugs, but it's better to fix those bugs. (In reply to Richard W.M. Jones from comment #5) > This is a libvirt bug (of sorts). After installing libvirt the > services are somehow not available. I worked around this in my > tests by doing: > > https://src.fedoraproject.org/rpms/virt-v2v/blob/rawhide/f/tests/basic-test. > sh#_10 > > Of course using direct mode is valid to work around libvirt bugs, > but it's better to fix those bugs. I'll give your workaround a try then. Have you got a libvirt bugzilla already opened for this issue I can track? Probably one of: https://bugzilla.redhat.com/show_bug.cgi?id=2052405 https://bugzilla.redhat.com/show_bug.cgi?id=2016601 Note it depends if you are running the program as root or non-root, so it might work one way but not the other. Upstream in https://github.com/libguestfs/libguestfs/commit/f0f8e6c5fe0c3f6d5d90534d263bded3a4dc7e8d Change the Summary to something I can search for more easily. Tested with the package:
libguestfs-1.50.1-3.el9.x86_64
Steps:
1. On rhel9.3 host
$ LIBGUESTFS_BACKEND=direct libguestfs-test-tool
...
/usr/libexec/qemu-kvm \
-global virtio-blk-pci.scsi=off \
-no-user-config \
-nodefaults \
-display none \
-machine q35,accel=kvm:tcg,graphics=off \
...
===== TEST FINISHED OK =====
The machine type has changed to q35.
Verified this bug per comment 10. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (libguestfs bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:6327 |