Bug 2149863

See also:

https://github.com/oVirt/ovirt-engine/blob/0b754784901f2d8aefc89f05be65f389655a9531/packaging/conf/osinfo-defaults.properties#L385

https://github.com/libguestfs/virt-v2v/blob/04ab49264dfb949d713f38598ab368212a3efd98/lib/create_ovf.ml#L238

Posted:
https://listman.redhat.com/archives/libguestfs/2022-December/030364.html

Upstream in:
https://github.com/libguestfs/virt-v2v/commit/38b35f3b7e5c6e5aea5dece5f77561b8332d3360

Tried with the versions:
libguestfs-1.48.4-4.el9.x86_64
osinfo-db-20221130-1.el9.noarch
libosinfo-1.10.0-1.el9.x86_64
virt-v2v-2.0.7-7.el9.x86_64

Steps to Reproduce:
1.Use virt-v2v to convert Win 11/Win 2019/Win 2022 to RHV with -o rhv-upload.

2.After conversion, check the guest info from RHV GUI, the guest version shows incorrect;

For win2019: Windows 2016 x64
For win2022: Windows 2016 x64
For win11: Windows 10 x64

3.Check the log file,only win11 shows incorrect info.
      <Info>Windows Server 2019 Standard</Info>
     <Description>windows_2019x64</Description>

      <Info>Windows Server 2022 Standard</Info>
     <Description>windows_2022</Description>

      <Info>Windows 10 Enterprise</Info>
    <Description>windows_11</Description>

Please check the attachments on the screenshots and -vx debug log.

>       <Info>Windows 10 Enterprise</Info>
>     <Description>windows_11</Description>

Hi Vera, this is actually correct.  Microsoft put "Windows 10 ..."
in the product name field of Windows 11.  We don't know why, but
we have to assume they know what they are doing.

The <Description> field is important however.  It must be
windows_11 (as here, so correct), not anything else.  This
is because RHV uses this field to tune the VM drivers /
virtual hardware.

(In reply to Richard W.M. Jones from comment #9)
> >       <Info>Windows 10 Enterprise</Info>
> >     <Description>windows_11</Description>
> 
> Hi Vera, this is actually correct.  Microsoft put "Windows 10 ..."
> in the product name field of Windows 11.  We don't know why, but
> we have to assume they know what they are doing.
> 
> The <Description> field is important however.  It must be
> windows_11 (as here, so correct), not anything else.  This
> is because RHV uses this field to tune the VM drivers /
> virtual hardware.

Hi rjones,

Can you help to confirm? 

As saying above, for all these 3 guests, the <Description> shows correct version. 
V2V has no bugs on this showing issue. Even on the step2, the versions are not correct on the GUI:
>>
2.After conversion, check the guest info from RHV GUI, the guest version shows incorrect;

For win2019: Windows 2016 x64
For win2022: Windows 2016 x64
For win11: Windows 10 x64
>>

The incorrect version is the bug of RHV. Is it right?

Yes I think this may be a bug in RHV (or maybe not).  But we are
passing the correct <Description> field to RHV as far as I know.
You might want to ask nsoffer or tgolembi for confirmation.

(In reply to Richard W.M. Jones from comment #11)
> Yes I think this may be a bug in RHV (or maybe not).  But we are
> passing the correct <Description> field to RHV as far as I know.
> You might want to ask nsoffer or tgolembi for confirmation.

Thanks rjones.

@nsoffer @tgolembi  could you help to confirm this issue? Thanks.

I think @ahadas can help with this.

(In reply to Richard W.M. Jones from comment #9)
> >       <Info>Windows 10 Enterprise</Info>
> >     <Description>windows_11</Description>
> 
> Hi Vera, this is actually correct.  Microsoft put "Windows 10 ..."
> in the product name field of Windows 11.  We don't know why, but
> we have to assume they know what they are doing.
> 
> The <Description> field is important however.  It must be
> windows_11 (as here, so correct), not anything else.  This
> is because RHV uses this field to tune the VM drivers /
> virtual hardware.

That's how RHV used to determine the operating system type but since virt-v2v switched to provide the OVF as an OVA configuration [1], it's no longer the case - RHV doesn't process the Description tag but rather checks the ovirt:id attribute of the OperatingSystemSection tag and falls back to checking the ovf:id attribute if ovirt:id doesn't exist [2].

I see that in both cases of windows 2019 and 2022, ovirt:id is set to 29 which represents Windows2016x64, the values should be 31 and 37, respectively

[1] https://github.com/libguestfs/virt-v2v/blob/v2.1.11/output/rhv-upload-createvm.py#L119
[2] https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.5.4/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfOvaReader.java#L73-L85

Thanks Arik.  Vera can you open a new bug against virt-v2v and I'll
get that fixed as well (but not until January unless Laszlo can look
at it).

(In reply to Richard W.M. Jones from comment #15)
> Thanks Arik.  Vera can you open a new bug against virt-v2v and I'll
> get that fixed as well (but not until January unless Laszlo can look
> at it).

File a new bug against this issue.

Bug 2152465 - v2v should set ovirt:id correctly after coverting windows11/2019/2022 guests to rhv via -o rhv-upload

For the comments above, moving to Verified status and track the rhv issue on bz2152465.

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 (virt-v2v 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:2313