RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2168578 - use q35 machine type for libguestfs appliance
Summary: use q35 machine type for libguestfs appliance
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libguestfs
Version: CentOS Stream
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: YongkuiGuo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-02-09 12:40 UTC by Sandro Bonazzola
Modified: 2024-01-22 08:16 UTC (History)
8 users (show)

Fixed In Version: libguestfs-1.50.1-4.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-07 08:24:21 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-148145 0 None None None 2023-02-09 12:41:19 UTC
Red Hat Product Errata RHBA-2023:6327 0 None None None 2023-11-07 08:24:29 UTC

Description Sandro Bonazzola 2023-02-09 12:40:43 UTC 
Description of problem:

While running virt-sparsify on CentOS Stream 9 with direct backend a deprecation warning is raised about machine type 'pc-i440fx-rhel7.6.0' being used.

$ export LIBGUESTFS_BACKEND=direct
$ export LIBGUESTFS_DEBUG=1
$ export LIBGUESTFS_TRACE=1
$ virt-sparsify --in-place ovirt-engine-appliance.qcow2 2>log
$ grep warning log
qemu-kvm: warning: Machine type 'pc-i440fx-rhel7.6.0' is deprecated: machine types for previous major releases are deprecated

libguestfs-appliance-1.48.4-4.el9.x86_64
libguestfs-1.48.4-4.el9.x86_64
libguestfs-xfs-1.48.4-4.el9.x86_64
guestfs-tools-1.48.2-8.el9.x86_6
qemu-kvm-7.2.0-6.el9.x86_64


The same process executed on Fedora 37 doesn't issue the same warning:
guestfs-tools-1.49.7-2.fc37.x86_64
libguestfs-appliance-1.49.9-1.fc37.x86_64
libguestfs-1.49.9-1.fc37.x86_64
libguestfs-xfs-1.49.9-1.fc37.x86_64
qemu-kvm-7.0.0-13.fc37.x86_64
Comment 1 Richard W.M. Jones 2023-02-09 12:58:10 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.
Comment 2 Sandro Bonazzola 2023-02-09 13:23:58 UTC 
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.
Comment 3 Richard W.M. Jones 2023-02-09 13:46:09 UTC 
Patch proposed:
https://listman.redhat.com/archives/libguestfs/2023-February/030645.html
Comment 4 Sandro Bonazzola 2023-02-09 14:11:56 UTC 
(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)
Comment 5 Richard W.M. Jones 2023-02-09 14:15:01 UTC 
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.
Comment 6 Sandro Bonazzola 2023-02-09 16:04:40 UTC 
(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?
Comment 7 Richard W.M. Jones 2023-02-09 16:18:51 UTC 
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.
Comment 8 Richard W.M. Jones 2023-02-10 11:01:57 UTC 
Upstream in
https://github.com/libguestfs/libguestfs/commit/f0f8e6c5fe0c3f6d5d90534d263bded3a4dc7e8d
Comment 9 Richard W.M. Jones 2023-02-13 12:11:22 UTC 
Change the Summary to something I can search for more easily.
Comment 10 YongkuiGuo 2023-03-09 02:44:45 UTC 
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.
Comment 13 YongkuiGuo 2023-03-21 03:00:11 UTC 
Verified this bug per comment 10.
Comment 15 errata-xmlrpc 2023-11-07 08:24:21 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.