When working with modern Xeon processors (like the referenced E5504 series) in KVM virtualization environments, we face an important architectural consideration:

# Sample output from /proc/cpuinfo showing HT capabilities
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 26
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4

Hyperthreading (HT) presents logical processors to the OS, but these aren't equivalent to physical cores:

• Physical cores: Independent execution units with dedicated resources
• HT threads: Share execution resources of a physical core (ALU, cache)
• Best case HT gain: 15-30% throughput improvement per core

For optimal VM performance without overcommitment:

# Recommended libvirt domain XML configuration for 4-core host
<vcpu placement='static'>4</vcpu>
<cpu mode='host-passthrough'>
  <topology sockets='1' cores='4' threads='1'/>
</cpu>

Sample sysbench results comparing configurations:

For latency-sensitive workloads, consider CPU pinning:

# CPU pinning example in libvirt domain XML
<cputune>
  <vcpupin vcpu='0' cpuset='0'/>
  <vcpupin vcpu='1' cpuset='1'/>
  <emulatorpin cpuset='2-3'/>
</cputune>

Remember to monitor actual performance using tools like perf stat and adjust allocations based on workload characteristics.

Modern Xeon processors with Hyper-Threading Technology (HTT) present unique considerations for virtualization. A quad-core CPU like the Intel Xeon X5570 actually exposes 8 logical processors to the OS through simultaneous multithreading. This creates both opportunities and challenges when allocating virtual CPUs in KVM environments.

When examining /proc/cpuinfo on an Ubuntu KVM host, you'll see entries like:

processor       : 0
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4

This reveals the hardware truth - 4 physical cores presenting 8 logical processors via HTT. KVM/QEMU interprets these as 8 available vCPUs.

The optimal approach depends on workload characteristics:

CPU-Bound Workloads

For computation-intensive tasks (e.g., scientific computing), allocate based on physical cores:

<vcpu placement='static'>4</vcpu>
<cputune>
    <vcpupin vcpu='0' cpuset='0'/>
    <vcpupin vcpu='1' cpuset='1'/>
    <vcpupin vcpu='2' cpuset='2'/>
    <vcpupin vcpu='3' cpuset='3'/>
</cputune>

I/O-Bound Workloads

For databases or web servers, HTT can provide benefits:

virsh vcpu-pin domain_name 0 0,4
virsh vcpu-pin domain_name 1 1,5
virsh vcpu-pin domain_name 2 2,6
virsh vcpu-pin domain_name 3 3,7

Key metrics to monitor:

• CPU ready time (virsh domstats)
• CPU steal time (mpstat -P ALL)
• Context switches (pidstat -w)

Our tests on MySQL workloads showed:

For NUMA systems, add topology awareness:

<numatune>
    <memory mode='strict' nodeset='0'/>
</numatune>
<vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='yes' hotpluggable='no' order='2'/>
</vcpus>