Michal Privoznik 5bb4540dbb virsysinfo: Be more forgiving when decoding OEM strings
On some systems, there are two or even more 'OEM Strings'
sections in DMI table. Here's an example of dmidecode output on
such system:

  # dmidecode -q -t 11
  OEM Strings
          String 1: Default string

  OEM Strings
          String 1: ThunderX2 System
          String 2: cavium.com
          String 3: Comanche

Now, this poses a problem, because when one tries to obtain
individual strings, they get:

  # dmidecode -q --oem-string 1
  Default string
  ThunderX2 System

  # dmidecode -q --oem-string 2
  No OEM string number 2
  cavium.com

NB, the "No OEM string number 2" is printed onto stderr and
everything else onto stdout. Oh, and trying to get OEM strings
from just one section doesn't fly:

  # dmidecode -q -H 0x1d --oem-string 2
  Options --string, --type, --handle and --dump-bin are mutually exclusive

This means two things:

1) we have no way of distinguishing OEM strings at the same index
   but in different sections,

2) because of how virSysinfoDMIDecodeOEMString() is written, we
   fail in querying OEM string that exists in one section but not
   in the others (for instance string #2 from example above).

While there's not much we can do about 1), there is something
that can be done about 2) - refine the error condition and make
the function return an error iff there's nothing on stdout and
there's something on stderr.

Resolves: https://issues.redhat.com/browse/RHEL-45952
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2024-07-25 16:50:47 +02:00
2019-05-31 17:54:28 +02:00
2024-07-15 15:20:50 +02:00
2024-07-25 16:04:50 +02:00
2019-09-06 12:47:46 +02:00
2022-03-17 14:33:12 +01:00
2023-12-05 11:48:28 +01:00
2020-08-03 09:26:48 +02:00
2019-10-18 17:32:52 +02:00
2024-07-24 12:41:58 +02:00
2024-07-25 16:04:50 +02:00

GitLab CI Build Status

CII Best Practices

Translation status

Libvirt API for virtualization

Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.

For some of these hypervisors, it provides a stateful management daemon which runs on the virtualization host allowing access to the API both by non-privileged local users and remote users.

Layered packages provide bindings of the libvirt C API into other languages including Python, Perl, PHP, Go, Java, OCaml, as well as mappings into object systems such as GObject, CIM and SNMP.

Further information about the libvirt project can be found on the website:

https://libvirt.org

License

The libvirt C API is distributed under the terms of GNU Lesser General Public License, version 2.1 (or later). Some parts of the code that are not part of the C library may have the more restrictive GNU General Public License, version 2.0 (or later). See the files COPYING.LESSER and COPYING for full license terms & conditions.

Installation

Instructions on building and installing libvirt can be found on the website:

https://libvirt.org/compiling.html

Contributing

The libvirt project welcomes contributions in many ways. For most components the best way to contribute is to send patches to the primary development mailing list. Further guidance on this can be found on the website:

https://libvirt.org/contribute.html

Contact

The libvirt project has two primary mailing lists:

Further details on contacting the project are available on the website:

https://libvirt.org/contact.html

Description
Libvirt provides a portable, long term stable C API for managing the virtualization technologies provided by many operating systems. It includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER Hypervisor.
Readme 908 MiB
Languages
C 94.8%
Python 2%
Meson 0.9%
Shell 0.8%
Dockerfile 0.6%
Other 0.8%