Managing CPUs for a Virtual Machine

Lesson purpose

CPU virtualization is primarily a scheduling problem. A VM does not usually receive a permanently assigned physical processor. Instead, the hypervisor schedules the VM’s virtual CPU work on available physical cores. Good CPU management therefore depends on understanding instructions, cores, vCPUs, contention, multiprocessor scheduling, hyper-threading, and workload evidence.

Learning objectives

By the end of the lesson, students should be able to:

• Explain what a CPU does and how a hypervisor virtualizes access to it.
• Distinguish a vCPU, a physical CPU, a core, and a logical processor.
• Describe why multiple vCPUs can increase scheduling delay.
• Configure vCPU counts from application requirements and measured demand.
• Explain hyper-threading’s benefit and limits.
• Compare Intel and AMD migration constraints and follow current platform guidance.

1. CPU work and apparent performance

The central processing unit executes instructions against data. A program’s apparent performance depends on how much useful work can be completed in the required time, not only on a clock-speed label or a raw instruction count. An application can appear slow because it needs more CPU work, because the CPU is older, or because it is waiting behind contention for a shared resource.

The lesson uses the historical contrast between ENIAC and modern processors to show how much computing capacity has changed. The operational point is more important than the specific numbers: virtualization can pool a large amount of modern CPU capacity, but the hypervisor still has to schedule it among competing guests.

2. How CPU virtualization works

The hypervisor normally does not emulate every instruction as if it were a different processor. Emulation can add substantial overhead. Instead, it schedules time slices on physical processor resources:

1. An application asks the guest operating system to perform work.
2. The guest presents the work through its virtual CPU context.
3. The hypervisor selects an available physical core and a scheduling interval.
4. The physical processor executes the instructions.
5. Results return through the hypervisor to the guest and application.

A vCPU is not permanently mapped to one pCPU. The hypervisor can run a VM’s vCPU on different physical cores over time. This mobility makes consolidation possible, but it also means that a busy host can delay a VM even when the guest sees a familiar processor.

3. Cores, processors, and vCPUs

Use precise terms:

• Physical CPU or socket: a processor package installed in the server.
• Core: an individual processing unit inside a package.
• pCPU: a schedulable physical processing resource; platform documentation may use the term differently, so define it when measuring.
• vCPU: a virtual processor context presented to a guest operating system.
• Logical processor: a schedulable hardware thread, such as one exposed by Intel hyper-threading.

The slide table illustrates the multiplication of resources. One quad-core package exposes four cores; two quad-core packages expose eight; four expose sixteen; and eight expose thirty-two. The exact usable capacity still depends on the architecture, firmware, hypervisor, workload, and reserve policy.

When sizing, it is reasonable to compare vCPU demand with physical cores as a first estimate, but a ratio is not a performance guarantee. A mostly idle single-vCPU VM can share time with others. A database, build server, or analytics workload that needs sustained parallel execution may consume much more.

4. Configure and right-size vCPUs

The primary VM CPU setting is the number of vCPUs. Some guest operating systems and hypervisors support hot-add, which allows additional vCPUs while the VM remains powered on. Hot-remove is less commonly supported, so reducing vCPUs often requires a shutdown and reboot. Platform limits differ, and the current vendor documentation is authoritative.

A reliable sizing process is:

1. Identify the application’s parallelism and licensing requirements.
2. Measure the physical workload before P2V when possible.
3. Start with the smallest supported vCPU count that meets the workload.
4. Monitor utilization, scheduling delay, latency, and application response.
5. Add vCPUs only when evidence shows that CPU capacity is the bottleneck.
6. Re-test after every material change.

The course deck recommends starting a new VM with one vCPU and increasing it when needed. That is a sizing convention, not a rule that every VM must have one processor. The reason is that extra vCPUs can make a VM harder to schedule and can add overhead when the application does not use them.

5. Multiprocessor VMs and contention

A VM with multiple vCPUs may need multiple physical execution resources at once or in a coordinated schedule. On a busy host, a four-vCPU VM can wait longer than a one-vCPU VM because the scheduler must find more available capacity. Modern relaxed scheduling can stagger execution rather than requiring strict lockstep, and priorities can protect important workloads, but overprovisioning still creates contention.

Teach the tradeoff explicitly:

• Too few vCPUs: the application may queue work and miss its service target.
• Too many vCPUs: the VM can experience scheduling delay, the host has fewer resources for other guests, and an application may not use the extra capacity.
• Right-sized vCPUs: the VM receives enough parallel capacity while leaving room for the host and neighboring workloads.

Some platforms present multicore virtual sockets or cores for guest compatibility, licensing, or operating-system limits. A multiprocessor layout can expose similar raw capacity through a different topology, but the guest’s licensing and CPU-topology behavior must be checked.

6. Hyper-threading

Intel hyper-threading exposes two logical processors per physical core so the processor can schedule two threads more efficiently. It does not double the physical execution capability. The text and deck use “up to about 30 percent” as an illustrative improvement under favorable workloads, not as a guaranteed multiplier.

For hyper-threading to help, the physical processor, operating system, and hypervisor must support it. Check the host’s processor and logical-processor counts in a system tool such as Task Manager, but interpret the result with the platform’s performance metrics. A logical processor is not equivalent to a full independent core.

7. Intel, AMD, and migration

Both Intel and AMD x86 platforms can run virtualization workloads well. The migration constraint is instruction-set compatibility. A running VM can generally live-migrate within a cluster that presents a compatible CPU feature set, such as Intel-to-Intel or AMD-to-AMD. Moving between different vendors may require powering off the VM before restarting it on the other host.

Clusters should be designed around the platform’s CPU-compatibility or masking features rather than assuming that all x86 hosts are interchangeable. Verify the current hypervisor’s compatibility matrix, firmware settings, feature baselines, and workload requirements before promising live migration.

Classroom application

Have students compare three hypothetical workloads: a lightly used web server, a highly parallel database, and a desktop lab VM. For each, document:

• A starting vCPU count and the evidence supporting it.
• The metric that would justify adding a vCPU.
• The likely impact of overallocating vCPUs.
• Whether hot-add is supported and what change would require a reboot.
• Whether the VM could live-migrate between the proposed hosts.

Use a capacity sketch such as a four-socket, quad-core host to show that a 1:1 allocation exposes sixteen physical cores, while an oversubscription ratio exposes more vCPUs than cores. Emphasize that the ratio is a planning input, not permission to ignore latency or workload behavior.

Checks for understanding:

• Why is a vCPU not permanently attached to one pCPU?
• Why can a four-vCPU VM perform worse than a one-vCPU VM on a busy host?
• Why does hyper-threading not double CPU capacity?
• Why might live migration work within an Intel cluster but fail across Intel and AMD hosts?

Common misconceptions

• “One vCPU equals one dedicated physical core.” It is a virtual execution context scheduled over time.
• “More vCPUs always improve performance.” Extra vCPUs help only when the workload can use them and the host can schedule them efficiently.
• “Hyper-threading creates a second full core.” It exposes another logical thread and improves utilization under suitable workloads.
• “Any x86 host is interchangeable.” CPU feature compatibility matters for live migration.
• “A vendor ratio is a guaranteed number of VMs.” Ratios must be validated against demand, contention, service levels, and reserve capacity.

Lesson summary

CPU virtualization schedules guest work on shared physical cores. vCPUs are movable virtual contexts, not dedicated chips, and a VM with many vCPUs can face greater scheduling difficulty than a smaller VM. Begin with measured workload requirements, add capacity when evidence supports it, and preserve host reserve. Hyper-threading can improve utilization without doubling physical power. Intel and AMD systems both support virtualization, but CPU compatibility and feature baselines determine whether a VM can move between hosts while running.