instances silently wedge when migrated to a less-capable node

[Daniel Howard]

Same hardware, new cluster.

Old Ganeti: Ubuntu 18.04 LTS, ganeti 2.16.1-1~ubuntu18.04.1

Never had any issues migrating between heterogeneous hardware.

New Ganeti: Ubuntu 22.04 LTS, ganeti 3.0.2-1ubuntu1

Migrations from node type A to node type A, B to B, or A to B work fine.

Migrations from node type B to node type A succeed from ganeti's point of view, but the instance is wedged until I issue a reboot.

I deploy the QMP timeout patch, but this is not a factor.[1]

Node type A, Dell R430, cpuinfo:

model name      : Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts md_clear flush_l1d
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs pml
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit mmio_stale_data

Node type B, Dell R640, cpuinfo:

model name      : Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs pml ept_mode_based_exec tsc_scaling
bugs            : spectre_v1 spectre_v2 spec_store_bypass swapgs taa itlb_multihit mmio_stale_data retbleed

The easiest solution is to pull the minority of type A nodes out of the cluster ... or migration tags ... or node groups ... does anyone have an idea if there's a lever I can pull to tell the cluster to run the instances in a mode that would be capable of migration to the less capable nodes?

Also, per my other message ... hspace is messed up, and convinced that my new, un-filled cluster is hopelessly full and incapable of taking any new VMs due to a lack of memory. However, I can create new instances and run hbal just fine ... could this be related?

Thanks!

1: https://github.com/ganeti/ganeti/pull/1597

--

http://dannyman.toldme.com

[Daniel Howard]

On my clusters, the cpu_type attribute is unset.

On any running instance, I see the same flavor of CPU:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 107
model name      : QEMU Virtual CPU version 2.5+

On the older cluster:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 6
model name      : QEMU Virtual CPU version 2.5+

The OS package names and versions have changed greatly.

Old:

Package: qemu-kvm
Version: 1:2.11+dfsg-1ubuntu7.40

New:
Package: qemu-system-x86
Version: 1:6.2+dfsg-2ubuntu6.5

--

http://dannyman.toldme.com

[Daniel Howard]

Here we go: https://github.com/ganeti/ganeti/issues/1382

Sascha provides a script to sniff out your common CPU type: https://github.com/ganeti/ganeti/issues/1382#issuecomment-608390192

# bash qemu-common-cpu.sh
checking for intel-microcode package: good
testing the Nehalem-IBRS CPU: good
testing the Westmere-IBRS CPU: good
testing the SandyBridge-IBRS CPU: good
testing the IvyBridge-IBRS CPU: good
testing the Haswell-noTSX-IBRS CPU: good
testing the Haswell-IBRS CPU: failed
testing Haswell-noTSX-IBRS with flag pcid: good
testing Haswell-noTSX-IBRS with flag stibp: good
testing Haswell-noTSX-IBRS with flag ssbd: good
testing Haswell-noTSX-IBRS with flag pdpe1gb: good
testing Haswell-noTSX-IBRS with flag md-clear: good
your common cpu_type is: Haswell-noTSX-IBRS,+pcid,+stibp,+ssbd,+pdpe1gb,+md-clear,enforce

Okily dokily.

> sudo gnt-cluster modify -H kvm:cpu_type=Haswell-noTSX-IBRS,+pcid,+stibp,+ssbd,+pdpe1gb,+md-clear,enforce
Parameter Error: Unknown parameter '+pcid'

Uh.

> sudo gnt-cluster modify -H kvm:cpu_type=Haswell-noTSX-IBRS

I'll take it.

Test VM?

gnt-info says "cpu_type: default (Haswell-noTSX-IBRS)"

Log in to the test VM:
> head -5 /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 6

model : 60
model name : Intel Core Processor (Haswell, no TSX, IBRS)

Okay, so there is a moment of truth here ...

No, it is still wedged up, but I like the thought.

With or without this application, I can migrate a VM from a node type A to a node type B, but then that same VM that was originally rooted on node type A, when migrated back, will wedge. A -> B -> A is a wedge. 🤔

At any rate, perhaps I now have a "CPU upgrade" for my VMs?

-danny

--

http://dannyman.toldme.com

[Sascha Lucas]

Hi Daniel,

On Thu, 3 Nov 2022, Daniel Howard wrote:

>> *sudo gnt-cluster modify -H
> kvm:cpu_type=Haswell-noTSX-IBRS,+pcid,+stibp,+ssbd,+pdpe1gb,+md-clear,enforce*

> Parameter Error: Unknown parameter '+pcid'

If I remember correctly comma is a ganeti internal separator, which needs
to be escaped. Additionally use shell quoting to pass escape character
into ganeti/python:

gnt-cluster modify -H kvm:cpu_type='Haswell-noTSX-IBRS\,+pcid\,+stibp\,+ssbd\,+pdpe1gb\,+md-clear\,enforce'

> With or without this application, I can migrate a VM from a node type A to
> a node type B, but then that same VM that was originally rooted on node
> type A, when migrated back, will wedge. A -> B -> A is a wedge. 🤔

Please take a look at node-A:/var/log/ganeti/kvm/<wedge-instance>.log. Is
there something valuable in there?

Mostly qemu suspends the migrated VM if something went wrong. You could
check your wedge-instance state with:

@node-A # echo 'info status' | socat STDIO UNIX-CONNECT:/var/run/ganeti/kvm-hypervisor/ctrl/<wedge-instance>.monitor

Thanks, Sascha.

[Rudolph Bott]

Hi Daniel,

On Fri, Nov 4, 2022 at 12:38 AM Daniel Howard <dann...@toldme.com> wrote:

On my clusters, the cpu_type attribute is unset.

Setting this to a common baseline for your entire cluster will generally greatly improve your VM's performance :-) (e.g. AES-NI support).

However, the version gap between your qemu versions is quite large (2.11 vs 6.2). "back in the days" live migration was only possible between the same minor versions. This seems to have relaxed a bit in the past years, but I would simply assume the migration to fail due to other circumstances than the CPU (e.g. PCI architecture). I think qemu never had any mechanisms in place to actually stop you from doing a live migration between different versions and neither has Ganeti. Your safest bet would be to get on the same QEMU version on all nodes.

Cheers,

Rudi

 

--
You received this message because you are subscribed to the Google Groups "ganeti" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/CAKU%3DtE8bMAdQZy%2BCD1fFwN7QVigFaBO3KO8LdBDiNSuP0QZKig%40mail.gmail.com.

--

 Rudolph Bott - bo...@sipgate.de

 Telefon: +49 (0)211-63 55 55-55

 Telefax: +49 (0)211-63 55 55-22

 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf

 HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois

 Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391

 www.sipgate.de - www.sipgate.co.uk

[Daniel Howard]

Sascha, thank you!

On the destination mode, when the VM wedges:

root@dr43-tonga:/var/log/ganeti/kvm# tail -F <instance>.log
kvm: terminating on signal 15 from pid 817349 (/usr/bin/python3)
tail: djh0.ops.sv4.quantifind.com.log: file truncated
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
kvm: warning: TSC frequency mismatch between VM (2194812 kHz) and host (1997678 kHz), and TSC scaling unavailable
^C
root@dr43-tonga:/var/log/ganeti/kvm# echo 'info status' | socat STDIO UNIX-CONNECT:/var/run/ganeti/kvm-hypervisor/ctrl/<instance>.monitor
QEMU 6.2.0 monitor - type 'help' for more information
(qemu) info status
VM status: running

At this point, the VM is wedged. A quick Google indicates that maybe there's a bug around this TSC scaling I can look into further.

-danny

--
You received this message because you are subscribed to the Google Groups "ganeti" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ganeti+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ganeti/alpine.DEB.2.22.394.2211070742420.396211%40eyu.loc.

--

http://dannyman.toldme.com

[Daniel Howard]

Yup!

https://unix.stackexchange.com/a/296767/5571

> It turns out that you can migrate a VM from a host without tsc_scale to a host with it, but a VM running on a host with tsc_scale can ONLY be migrated to another host with it.

The destination hosts that cause the VM to wedge do indeed lack the tsc_scaling feature.

Our old cluster did mix hardware in this way, so ...?

https://bugzilla.redhat.com/show_bug.cgi?id=1839095 is above my understanding, but it sounds like they've been re-working TSC scaling in KVM, so maybe I've surfed into a reversion.

The bug concludes:

This is now fixed upstream by

commit f7c40b5c716fea5d2a4179569146307ebebc76ba
Refs: v6.10.0-309-gf7c40b5c71

And here I am with Ubuntu 22.04 LTS version:

Package: qemu-system-x86
Version: 1:6.2+dfsg-2ubuntu6.5

In our case, it is probably easiest to stick with hosts that have tsc_scaling capability.

-danny

--

http://dannyman.toldme.com