This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 837884

Summary: per-machine-type CPU models for safe migration
Product: Red Hat Enterprise Linux 6 Reporter: Bhavna Sarathy <bsarathy>
Component: libvirtAssignee: Jiri Denemark <jdenemar>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 6.4CC: acathrow, areis, bsarathy, dallan, dyasny, dyuan, ehabkost, honzhang, hui.xiao, jane.lv, juzhang, jvillalo, luyu, mjenner, mkenneth, mzhan, qzhang, rwu, virt-maint, weizhan, yupzhang, zhpeng
Target Milestone: rcKeywords: TestOnly
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 833152 Environment:
Last Closed: 2013-02-21 02:19:00 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 833152    
Bug Blocks: 832177, 837920    

Comment 2 Dave Allan 2012-07-05 13:37:13 EDT
Depending on the design there will be more or less libvirt impact, possibly none.  Jiri, please talk to Eduardo about the design and see what you think.
Comment 6 Jiri Denemark 2012-07-19 05:43:05 EDT
So far the direction seems to be that qemu-kvm will implement CPU models that will differ according to the machine type used. This will be completely transparent to libvirt. Libvirt will think SandyBridge model will always contain TSC-deadline feature.
Comment 7 Eduardo Habkost 2012-07-19 13:31:19 EDT
(In reply to comment #6)
> So far the direction seems to be that qemu-kvm will implement CPU models
> that will differ according to the machine type used. This will be completely
> transparent to libvirt. Libvirt will think SandyBridge model will always
> contain TSC-deadline feature.

Yes, that's the plan: to implement in the in qemu-kvm in a way that doesn't affect libvirt (or affect it only in minor ways, like in the case of TSC-deadline).

I think this can be closed as NOTABUG, as long as there's a TSC-deadline-specific bug already open for libvirt.
Comment 8 Jiri Denemark 2012-07-20 09:23:23 EDT
OK, bug 804749 tracks the addition of TSC-deadline to SandyBridge model; I'm closing this bug. BTW, Eduardo, could you update the qemu-kvm bug 833152 with the current plan?
Comment 9 Jiri Denemark 2012-07-26 15:34:49 EDT
The right solution is still not finalized upstream but there's a possibility some changes will be needed in the way libvirt probes for available CPU models. I'll keep this bug open as a reminder...
Comment 10 Jiri Denemark 2012-10-01 11:04:50 EDT
The solution for qemu has been agreed on upstream and no work needs to be done on libvirt. I'm marking this bug as TestOnly. Before testing it, please, wait until bug 833152 is done.
Comment 11 hongming 2012-11-26 20:53:54 EST
Verify it as follows.The result is expected. So move its status to VERIFIED.

Steps
1. Prepare two host as follows.

# uname -r
2.6.32-338.el6.x86_64

# rpm -q libvirt qemu-kvm
libvirt-0.10.2-9.el6.x86_64
qemu-kvm-0.12.1.2-2.334.el6.x86_64

2. Start one rhel 6.4 guest on rhel 6.4 host.

# virsh start rhel64 
Domain rhel64 started

# ps -ef|grep rhel64
qemu     21063     1 39 16:13 ?        00:00:16 /usr/libexec/qemu-kvm -name rhel64 -S -M rhel6.4.0 -cpu SandyBridge,

3. Check tsc_deadline_timer flags in guest 
# cat /proc/cpuinfo|grep tsc_deadline_timer
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm xsaveopt


4.Start one rhel6.3 guest on rhel6,4 host 

# virsh start rhel63
Domain rhel63 started

# ps -ef|grep rhel63
qemu     22066     1 43 16:26 ?        00:00:04 /usr/libexec/qemu-kvm -name rhel63 -S -M rhel6.3.0 -cpu SandyBridge


5. Check tsc_deadline_timer flag in guest, no tsc_deadline_timer
# cat /proc/cpuinfo|grep tsc_deadline_timer
Comment 12 hongming 2012-12-07 00:54:56 EST
Add migration test.

Ping-Pong migrating rhel6.3 guest (-cpu SandyBridge) between RHEL6.4 and RHEL6.3 host (Both hosts are SandyBridge)

Steps

From host A to host B
# virsh migrate rhel6.3 --live qemu+ssh://host B ip/system

Check tsc_deadline_timer flag in guest, no tsc_deadline_timer
# cat /proc/cpuinfo|grep tsc_deadline_timer

From host B to host A
# virsh migrate rhel6.3 --live qemu+ssh://host A ip/system

Check tsc_deadline_timer flag in guest, no tsc_deadline_timer
# cat /proc/cpuinfo|grep tsc_deadline_timer


Result:
The guset rhel6.3 doesn't have tsc_deadline_timer flag on both hosts.


Ping-Pong migrating rhel6.4 guest (-cpu SandyBridge) guest between RHEL6.4 and RHEL6.4 host (Both hosts are SandyBridge)

Result:
The guset rhel6.4 always has tsc_deadline_timer flag on both hosts.
Comment 13 errata-xmlrpc 2013-02-21 02:19:00 EST
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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html