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 1987456 - NICs and secondary disks change in Win 2016/2019 VMs when changing the machine type from pc-q35-rhel8.3.0 to pc-q35-rhel8.4.0
Summary: NICs and secondary disks change in Win 2016/2019 VMs when changing the machin...
Keywords:
Status: CLOSED DUPLICATE of bug 1939546
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: virtio-win
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: beta
: ---
Assignee: Meirav Dean
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-29 14:54 UTC by Arik
Modified: 2021-09-19 17:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-09 01:09:32 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Arik 2021-07-29 14:54:22 UTC 
RHV changes the machine type of the virtual machine when upgrading the cluster-level. However, changing the machine type from pc-q35-rhel8.3.0 to pc-q35-rhel8.4.0 introduces an issue that we didn't experience before:

On Windows 2016 and 2019, we see that the NIC is discovered within the guest as a new device, so if the user configured the NIC prior to upgrading the cluster level then those settings get lost, and the secondary disks go offline.

If we change the machine type back to pc-q35-rhel8.3.0 then the original NIC device is getting active and the secondary disks go online.

We suspected that the fix for bz 1939546 would address this but that doesn't seem to be the case since it happens with the latest version of virtio drivers that are supposed to have this fix.

The issue with the NIC was also reported on Windows 2012 before - bz 1962187
Comment 1 Igor Mammedov 2021-07-30 08:09:02 UTC 
Bug 1939546 fixed regression where NIC lost settings on ==the same== machine type.
QEMU doesn't guarantee ABI compatibility when changing machine type, so breakage is expected.
It's all been discussed in original bug (i.e.
  1) do not change machine type or
  2) prepare migration plan to deal with necessary guest re-configurations).
At this point nothing more could be done on QEMU level.

You can try to convince virtio-win drivers team to look into it from
drivers point of view, but even if virtio drivers are able to work around
the issue, it won't magically solve it. You will still need to update
drivers within guest before changing machine type [2].
Comment 2 Arik 2021-07-30 14:45:54 UTC 
(In reply to Igor Mammedov from comment #1)
> Bug 1939546 fixed regression where NIC lost settings on ==the same== machine
> type.

Yeah, I've realized it when reading https://bugzilla.redhat.com/show_bug.cgi?id=1939546#c5
That's a pity I didn't see it before because that was never the case in any of the related bugs on RHV/oVirt - they all involved changing the cluster level which changes the machine type..
 
> You can try to convince virtio-win drivers team to look into it from
> drivers point of view, but even if virtio drivers are able to work around
> the issue, it won't magically solve it. You will still need to update
> drivers within guest before changing machine type [2].

Fair enough, so could you please assist in moving this bz to the right component for that?
Comment 4 John Ferlan 2021-08-06 15:35:21 UTC 
Meirav - I changed the from RHEL-AV to virtio-win as it seems that's what Igor is suggesting and of course assigned to you for your team's analysis. I had to guess on the sub-component.
Comment 5 lijin 2021-08-09 01:09:32 UTC 

*** This bug has been marked as a duplicate of bug 1939546 ***
Note You need to log in before you can comment on or make changes to this bug.