Bug 1494471

Summary: host-model CPU changes to custom CPU in an inactive config after reverting to an active snapshot
Product: Red Hat Enterprise Linux 7 Reporter: Jiri Denemark <jdenemar>
Component: libvirtAssignee: Jiri Denemark <jdenemar>
Status: CLOSED WONTFIX QA Contact: jiyan <jiyan>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.4CC: bugproxy, dyuan, hannsj_uhl, hhan, jsuchane, lmen, xuzhang, yalzhang
Target Milestone: rc   
Target Release: 7.5   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1662588 (view as bug list) Environment:
Last Closed: 2019-04-29 11:44:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1476742, 1662588    
Attachments:
Description Flags
Attaching Sosreport none

Description Jiri Denemark 2017-09-22 10:57:56 UTC 
Description of problem:

When a domain with a host-model CPU is started, its CPU changes into a custom one and this custom CPU is stored within a snapshot taken while the domain is running. The inactive config still contains host-model CPU. But once we revert to the active snapshot, even the CPU in the inactive config changes into the custom one, which is wrong.

Version-Release number of selected component (if applicable):

libvirt-3.7.0

How reproducible:

100%

Steps to Reproduce:
1. define a domain with <cpu mode='host-model'/>
2. start the domain: virsh start $DOM
3. create a snapshot: virsh snapshot-create-as $DOM snap
4. revert to the new snapshot: virsh snapshot-revert $DOM snap
5. check inactive domain XML: virsh dumpxml --inactive $DOM

Actual results:

After each of the first three steps the inactive domain XML correctly contains the host-model CPU, but after step 4 the CPU in the inactive domain XML changes to the custom one from the snapshot.

Expected results:

The inactive XML should contain the host-model CPU in all steps, i.e., even after reverting the domain to the snapshot.

Additional info:

Do not confuse this issue with bug 1485022 which fixes an issue with an offline, i.e., inactive snapshot.
Comment 1 Jiri Denemark 2017-11-22 13:31:39 UTC 
*** Bug 1509107 has been marked as a duplicate of this bug. ***
Comment 2 IBM Bug Proxy 2017-11-22 13:38:07 UTC 
------- Comment From sthoufee.com 2017-11-03 03:20 EDT-------
https://www.redhat.com/archives/libvir-list/2017-October/msg01333.html
Comment 3 IBM Bug Proxy 2017-12-07 11:01:17 UTC 
Created attachment 1364220 [details]
Attaching Sosreport
Comment 4 jiyan 2018-12-30 10:37:51 UTC 
Reproduce this bug in the following components:

Version:
libvirt-3.7.0-1.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.18.x86_64
kernel-3.10.0-693.el7.x86_64

Steps:
1. prepare a shutdown VM with 'host-model' CPU configuration
# virsh domstate test1
shut off

# virsh dumpxml test1 --inactive | grep "<cpu" -A2
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

2. Start VM and check cpu configuration in inactive dumpxml
# virsh start test1
Domain test1 started

# virsh dumpxml test1 --inactive|grep "<cpu" -A2
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

3. Create internal snapshot for VM and check cpu configuration in inactive dumpxml
# virsh snapshot-create-as test1 snap1
Domain snapshot snap1 created

# virsh dumpxml test1 --inactive|grep "<cpu" -A2
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

4. Revert VM from internal snapshot and check cpu configuration in inactive dumpxml
# virsh snapshot-revert test1 snap1

# virsh dumpxml test1 --inactive|grep "<cpu" -A2
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Opteron_G5</model>
    <vendor>AMD</vendor>
    ...

As step-4 shows, the CPU configuration in inactive dumpxml changed after reverting from internal snapshot.
Comment 6 IBM Bug Proxy 2019-04-10 13:39:36 UTC 
------- Comment From danielhb.com 2019-04-10 09:29 EDT-------
*** Bug 159269 has been marked as a duplicate of this bug. ***
Comment 7 Jaroslav Suchanek 2019-04-29 11:44:55 UTC 
This bug will be addressed in the next major release.