Your message dated Mon, 11 Aug 2025 13:26:30 +0300 with message-id <[email protected]> and subject line Re: can't migrate from system with tsc_scale cpu flag to one without has caused the Debian Bug report #831761, regarding can't migrate from system with tsc_scale cpu flag to one without to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 831761: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831761 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: qemu-system-x86 Version: 1:2.6+dfsg-3 1. What Works: Migrating from a host CPU without tsc_scale to one with it works perfectly. e.g. from an AMD Phenom II x4 940 to an AMD FX-8150. Migrating from a host CPU without tsc_scale to another one without it also works perfectly. e.g. from an AMD Phenom II 1090T to an AMD Phenom II x4 940, and back and forth as often as I like, without a problem. I haven't tested it yet, but given that migration works for lots of people I assume that migrating from a host CPU with tsc_scale to another one with it will also work perfectly. e.g. an FX-8150 to/from an FX-8320. 2. What doesn't work: Migrating from a CPU with tsc_scale to one without it **appears** to migrate successfully, but the VM on the migration-target host uses 100% CPU and hangs. e.g. from an AMD FX-8150 to an AMD Phenom II x4 940. Migrating it back to the original host doesn't fix it. The only things that can be done with the VM are force-reboot and force-shutdown. There's no console or log output on the VM itself, the only indication of any problem (apart from the 100% CPU utilisation & hang) is a message in /var/log/libvirt/qemu/vmname.log on the migration-target host saying: qemu-system-x86_64: warning: TSC frequency mismatch between VM and host, and TSC scaling unavailable IMO, that's shouldn't be just a warning. it's a fatal error. NOTE: Disabling kvm_steal_time as recommended in several similar bug reports and forum posts doesn't solve the problem. AFAIK, there is no solution other than "Don't Do That". I'm not sure if this is a bug in qemu or just a hardware incompatibility between old and new (or not-quite-so-old) CPUs. Please forward upstream, they should at least document the issue, even if it can't be fixed. For a more detailed analysis/example of the problem, see: http://unix.stackexchange.com/questions/296636/100-cpu-utilisation-and-hang-after-virsh-migrate craig -- craig sanders <[email protected]>
--- End Message ---
--- Begin Message ---On Tue, 19 Jul 2016 17:26:50 +1000 Craig Sanders <[email protected]> wrote:Package: qemu-system-x86 Version: 1:2.6+dfsg-3 1. What Works: Migrating from a host CPU without tsc_scale to one with it works perfectly. e.g. from an AMD Phenom II x4 940 to an AMD FX-8150. Migrating from a host CPU without tsc_scale to another one without it also works perfectly. e.g. from an AMD Phenom II 1090T to an AMD Phenom II x4 940, and back and forth as often as I like, without a problem. I haven't tested it yet, but given that migration works for lots of people I assume that migrating from a host CPU with tsc_scale to another one with it will also work perfectly. e.g. an FX-8150 to/from an FX-8320. 2. What doesn't work: Migrating from a CPU with tsc_scale to one without it **appears** to migrate successfully, but the VM on the migration-target host uses 100% CPU and hangs. e.g. from an AMD FX-8150 to an AMD Phenom II x4 940. Migrating it back to the original host doesn't fix it. The only things that can be done with the VM are force-reboot and force-shutdown. There's no console or log output on the VM itself, the only indication of any problem (apart from the 100% CPU utilisation & hang) is a message in /var/log/libvirt/qemu/vmname.log on the migration-target host saying: qemu-system-x86_64: warning: TSC frequency mismatch between VM and host, and TSC scaling unavailable IMO, that's shouldn't be just a warning. it's a fatal error.This is the code in current (10.1) qemu: if (r < 0) { /* When KVM_SET_TSC_KHZ fails, it's an error only if the current * TSC frequency doesn't match the one we want. */cur_freq = kvm_check_extension(cs->kvm_state, KVM_CAP_GET_TSC_KHZ) ?kvm_vcpu_ioctl(cs, KVM_GET_TSC_KHZ) : -ENOTSUP; if (cur_freq <= 0 || cur_freq != env->tsc_khz) { warn_report("TSC frequency mismatch between " "VM (%" PRId64 " kHz) and host (%d kHz), " "and TSC scaling unavailable", env->tsc_khz, cur_freq); return r; } } So it is not always an error, really, and qemu itself can't know if guest is actually using TSC or not, so it allows migration in a hope for the best. All this should now be handled by the upper layers (eg, libvirt), which should either mask the features which might be unavailable on all nodes, or with current hardware where tsc scaling is generally available. I don't think this bug report is worth to keep at this time, so am closing it now. Please feel free to reopen it if you think it is incorrect. Thanks, /mjt
--- End Message ---
