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

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

XMLWordPrintable

    • 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.

       

       

        1. image-2024-01-23-11-04-00-257.png
          image-2024-01-23-11-04-00-257.png
          21 kB
        2. image-2024-01-31-13-28-11-933.png
          image-2024-01-31-13-28-11-933.png
          63 kB
        3. image-2024-03-20-14-57-43-189.png
          image-2024-03-20-14-57-43-189.png
          29 kB
        4. win2019.sh
          4 kB

            [RHEL-21705] pc-q35-rhel9.4.0 does not provide proper computer information

            Mayur Patil added a comment -

            Thanks rhn-engineering-imammedo for your suggestions.

            Mayur Patil added a comment - Thanks rhn-engineering-imammedo for your suggestions.

            Mayur Patil added a comment -

            Hi rhn-support-davozeni,

            Thanks for the review.

            Mayur Patil added a comment - Hi rhn-support-davozeni , Thanks for the review.

            Daniel Vozenilek added a comment -

            maypatil@redhat.com, I copied the RN to the following Gdoc: RHEL-21705 release note peer review

            Because I suggested multiple rewrites, I thought it would be better to make it in a Gdoc, so that you can easily see the suggestions. Since this is quite a long and detail-heavy RN, I suggested some improvements for more clarity and readability.

            Let me know if something is unclear or if you need some more feedback from me.

            Daniel Vozenilek added a comment - maypatil@redhat.com , I copied the RN to the following Gdoc: RHEL-21705 release note peer review Because I suggested multiple rewrites, I thought it would be better to make it in a Gdoc, so that you can easily see the suggestions. Since this is quite a long and detail-heavy RN, I suggested some improvements for more clarity and readability. Let me know if something is unclear or if you need some more feedback from me.

            Errata Tool added a comment -

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            For information on the advisory (Moderate: qemu-kvm security 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/RHSA-2024:2135

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory (Moderate: qemu-kvm security 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/RHSA-2024:2135

            Xueqiang Wei added a comment -

            the default value of smbios should be automatically generated based on some conditions (e.g. the value of CPU or memory). boot a vm with large cpu and memory, got the default value of smbios  was 3.0.

             

            rhn-engineering-imammedo, thank you for your confirmation. Can you help provide the exact conditions for enabling smbios 3.0?

            How much memory, how much CPU, or other conditions? Many thanks.

             

            Xueqiang Wei added a comment - the default value of smbios should be automatically generated based on some conditions (e.g. the value of CPU or memory). boot a vm with large cpu and memory, got the default value of smbios  was 3.0.   rhn-engineering-imammedo , thank you for your confirmation. Can you help provide the exact conditions for enabling smbios 3.0? How much memory, how much CPU, or other conditions? Many thanks.  

            Igor Mammedov added a comment -

            jetwei confirming that your last comment is correct.

            Igor Mammedov added a comment - jetwei confirming that your last comment is correct.

            Xueqiang Wei added a comment -

            Follow my previous comment https://issues.redhat.com/browse/RHEL-21705?focusedId=24442712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24442712,

            I re-checked the changes in https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/merge_requests/230:

            Downstream changes applicable to x86:

            1. keep 'pc' based machine types using 32 bit SMBIOS entrypoint
            2. keep 'q35' based machines 9.2 and older using 32 bit SMBIOS entrypoint
            3. make the latest 'q35' based machines use 'auto' entry point (incl. 9.4 machine type)

            If I understand correctly, according to item 3, the default value of smbios should be automatically generated based on some conditions (e.g. the value of CPU or memory). The following results seem to reflect this as well. 

            1. based on https://issues.redhat.com/browse/RHEL-7526?focusedId=24443486&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24443486, boot a vm with large cpu and memory, got the default value of smbios  was 3.0
            2. with smaller cpu and memory, got the default value of smbios was 2.8

            Hi rhn-engineering-imammedo, Sorry for bothering you again, Can you help confirm them? If I was wrong, please correct me. Many thanks. cc jsuvorov@redhat.com, rhn-support-yiwei, jinzhao@redhat.com, coli@redhat.com   

            Xueqiang Wei added a comment - Follow my previous comment https://issues.redhat.com/browse/RHEL-21705?focusedId=24442712&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24442712 , I re-checked the changes in https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/merge_requests/230: Downstream changes applicable to x86: keep 'pc' based machine types using 32 bit SMBIOS entrypoint keep 'q35' based machines 9.2 and older using 32 bit SMBIOS entrypoint make the latest 'q35' based machines use 'auto' entry point (incl. 9.4 machine type) If I understand correctly, according to item 3, the default value of smbios should be automatically generated based on some conditions (e.g. the value of CPU or memory). The following results seem to reflect this as well.  based on https://issues.redhat.com/browse/RHEL-7526?focusedId=24443486&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24443486 , boot a vm with large cpu and memory, got the default value of smbios  was 3.0 with smaller cpu and memory, got the default value of smbios was 2.8 Hi rhn-engineering-imammedo , Sorry for bothering you again, Can you help confirm them? If I was wrong, please correct me. Many thanks. cc jsuvorov@redhat.com , rhn-support-yiwei , jinzhao@redhat.com , coli@redhat.com   

            Xueqiang Wei added a comment - - edited

            add the impact bugs "Q35: Use SMBIOS 3.0 Entry Point Type automatically" and "SMBIOS 2.1 table limits error when booting guest with 710 vcpus and 250G memory"

            Xueqiang Wei added a comment - - edited add the impact bugs "Q35: Use SMBIOS 3.0 Entry Point Type automatically" and "SMBIOS 2.1 table limits error when booting guest with 710 vcpus and 250G memory"

            Xueqiang Wei added a comment - - edited

            Hi rhn-engineering-imammedo, I found after this fix the default value of smbios version is 2.8 instead of 3.0 (with machine type pc-q35-rhel9.4.0). The value changes back to 2.8. And according to https://issues.redhat.com/browse/RHEL-7527, the default value of smbios version is 3.0 from qemu-kvm-8.2.0-1.el9. After the fix, we need to add smbios-entry-point-type=64 to qemu command lines to use SMBIOS 3.0 Entry Point Type. So I would like to double confirm if it's correct? If yes, do we have any plan to change the default version back to 3.0?  cc jsuvorov@redhat.com

            Xueqiang Wei added a comment - - edited Hi rhn-engineering-imammedo , I found after this fix the default value of smbios version is 2.8 instead of 3.0 (with machine type pc-q35-rhel9.4.0). The value changes back to 2.8. And according to https://issues.redhat.com/browse/RHEL-7527 , the default value of smbios version is 3.0 from qemu-kvm-8.2.0-1.el9. After the fix, we need to add smbios-entry-point-type=64 to qemu command lines to use SMBIOS 3.0 Entry Point Type. So I would like to double confirm if it's correct? If yes, do we have any plan to change the default version back to 3.0?  cc jsuvorov@redhat.com

            Xueqiang Wei added a comment -

            Tested seabios test loop and qemu gating stage test loop with rhel guest and windows guest, no new bug was found.
            Hit some automation issues which have been fixed.

            Versions:
            kernel-5.14.0-427.3.1.el9_4.x86_64
            qemu-kvm-8.2.0-9.el9_4
            seabios-bin-1.16.3-2.el9

            1. Seabios_test_loop_with_rhel940_win2019_qemu-kvm-8.2.0-9.el9_4
              1. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_test_loop_with_rhel940_win2019_qemu-kvm-8.2.0-9.el9_4/results.html
              2. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_pxe_boot_with_rhel940_win2019_qemu-kvm-8.2.0-9.el9_4/results.html
              3. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/pxe_boot.with_query_cpus_with_qemu-kvm-8.2.0-9.el9_4/results.html
              4. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_system_power_down_with_win2019_qemu-kvm-8.2.0-9.el9_4/results.html
              5. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_hotplug_unplug_with_qemu-kvm-8.2.0-9.el9_4/results.html
              6. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/nmi_bsod_catch_with_win2019_qemu-kvm-8.2.0-9.el9_4/results.html
            2. Qemu_gating_stage_rhel9_with_qemu-kvm-8.2.0-9.el9_4
              1. Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/qemu_gating_stage_rhel9_with_qemu-kvm-8.2.0-9.el9_4/results.html

             

            Xueqiang Wei added a comment - Tested seabios test loop and qemu gating stage test loop with rhel guest and windows guest, no new bug was found. Hit some automation issues which have been fixed. Versions: kernel-5.14.0-427.3.1.el9_4.x86_64 qemu-kvm-8.2.0-9.el9_4 seabios-bin-1.16.3-2.el9 Seabios_test_loop_with_rhel940_win2019_qemu-kvm-8.2.0-9.el9_4 Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_test_loop_with_rhel940_win2019_qemu-kvm-8.2.0-9.el9_4/results.html Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_pxe_boot_with_rhel940_win2019_qemu-kvm-8.2.0-9.el9_4/results.html Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/pxe_boot.with_query_cpus_with_qemu-kvm-8.2.0-9.el9_4/results.html Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_system_power_down_with_win2019_qemu-kvm-8.2.0-9.el9_4/results.html Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/seabios_hotplug_unplug_with_qemu-kvm-8.2.0-9.el9_4/results.html Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/nmi_bsod_catch_with_win2019_qemu-kvm-8.2.0-9.el9_4/results.html Qemu_gating_stage_rhel9_with_qemu-kvm-8.2.0-9.el9_4 Job link: http://fileshare.hosts.qa.psi.pek2.redhat.com/pub/logs/qemu_gating_stage_rhel9_with_qemu-kvm-8.2.0-9.el9_4/results.html  

              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: