Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-21705

pc-q35-rhel9.4.0 does not provide proper computer information

    • qemu-kvm-8.2.0-9.el9_4
    • Yes
    • None
    • Regression, CustomerScenariosInitiative
    • rhel-sst-virtualization
    • ssg_virtualization
    • 28
    • 30
    • None
    • QE ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Red Hat Enterprise Linux
    • None
    • Approved Exception
    • Known Issue
    • Hide
      .SMBIOS does not work on a Windows VM with the SeaBIOS firmware

      Microsoft Windows bootloader doesn't support System Management BIOS (SMBIOS) 3.0 entry point lookup, when booted on the SeaBIOS firmware. Consequently, virtual machines (VMs) might fail to boot or read SMBIOS information. `pc-q35-rhel9.4.0` or newer machine type(s) set SMBIOS entry point automatically depending on the configuration.

      A 32-bit SMBIOS entry-point (SMBIOS v2.8 tables) will be generated if configuration permits:

      * Windows VM uses VCPUs with less than 255 cores/threads.
      * SMBIOS tables consume less than 64KB of RAM

      Otherwise, QEMU will transparently switch to 64-bit SMBIOS entry-point (SMBIOS v3.0).

      As a workaround:  

      * Configure VM to use UEFI firmware, where Windows supports 64-bit SMBIOS entry-point.
      * Alternatively, if switching to UEFI is not feasible, use smaller VM with less vCPUs or memory until Windows guest starts reading SMBIOS information.
      Show
      .SMBIOS does not work on a Windows VM with the SeaBIOS firmware Microsoft Windows bootloader doesn't support System Management BIOS (SMBIOS) 3.0 entry point lookup, when booted on the SeaBIOS firmware. Consequently, virtual machines (VMs) might fail to boot or read SMBIOS information. `pc-q35-rhel9.4.0` or newer machine type(s) set SMBIOS entry point automatically depending on the configuration. A 32-bit SMBIOS entry-point (SMBIOS v2.8 tables) will be generated if configuration permits: * Windows VM uses VCPUs with less than 255 cores/threads. * SMBIOS tables consume less than 64KB of RAM Otherwise, QEMU will transparently switch to 64-bit SMBIOS entry-point (SMBIOS v3.0). As a workaround:   * Configure VM to use UEFI firmware, where Windows supports 64-bit SMBIOS entry-point. * Alternatively, if switching to UEFI is not feasible, use smaller VM with less vCPUs or memory until Windows guest starts reading SMBIOS information.
    • Done
    • None

      Got message "No Instance(s) Available" when running wmic MemoryChip get Capacity in windows guest

       

      Versions:

      kernel-5.14.0-405.el9.x86_64

      qemu-kvm-8.2.0-2.el9

      seabios-bin-1.16.3-2.el9.noarch

      win2019 with virtio-win-prewhql-0.1-245.iso

      How reproducible:

      5/5

      Steps to reproduce

      1.  boot a windows 2019 guest with seabios
      2. run wmic MemoryChip get Capacity in guest

      Expected results

      get the correct output: 

      PS C:\Users\Administrator> wmic MemoryChip get Capacity
      Capacity
      17179869184

      Actual results

      get the output: No Instance(s) Available

      Also CHID can not get any information with the latest pc-q35-rhel9.4.0.

       

      Additional information:

      1. Also got incorrect message when running "wmic cpu get socketDesignation"

      SocketDesignation

      The correct output as below:

      PS C:\Users\Administrator> wmic cpu get socketDesignation
      SocketDesignation
      CPU 0
      CPU 1

      2. downgrade to qemu-kvm-8.1.0-5.el9, all work well, it should be a regression bug.

      3. tested with edk2-ovmf-20231122-1.el9 and qemu-kvm-8.2.0-2.el9, not hit this issue.

       

       

              rhn-engineering-imammedo Igor Mammedov
              jetwei Xueqiang Wei
              Daniel Vozenilek
              virt-maint virt-maint
              Xueqiang Wei Xueqiang Wei
              Jiří Herrmann Jiří Herrmann
              Votes:
              0 Vote for this issue
              Watchers:
              28 Start watching this issue

                Created:
                Updated:
                Resolved: