Virtualization, TPM, HSM

Virtual machines often fail for simple reasons, a missing firmware setting, a blocked CPU feature, or a security chip that isn’t ready. CompTIA A+ Core 1 (220-1201) Objective 3.5 expects you to spot those issues fast and fix them with safe, repeatable checks.

This section focuses on virtualization support and basic encryption hardware that shows up in modern PCs. You’ll learn what to look for in BIOS or UEFI when a hypervisor won’t install or a VM won’t start, including common settings tied to CPU virtualization. You’ll also review encryption support through the Trusted Platform Module (TPM) and when an external Hardware Security Module (HSM) is used.

The goal is practical: understand what these tools do, where you’ll find them, and what to verify when something breaks. That includes checking firmware options, confirming device status in the OS, and knowing the limits of each technology. No deep cryptography is needed, only clear troubleshooting habits that match the exam and real help desk work.

Virtualization support, what it is and what a tech is expected to do

Virtualization support is the set of features and checks that let one physical computer run one or more virtual machines (VMs). On the A+ exam, this usually means you can identify the moving parts, confirm the right firmware settings, and fix common install and start-up failures without risky changes.

In the field, a tech is often asked to do three things: confirm the PC can run VMs, enable the correct BIOS or UEFI options, and troubleshoot conflicts between hypervisors and security features. Your goal is stability first. Make one change at a time, document what you touched, and verify the result after reboot.

The key terms you will see on the exam, hypervisor, VM, host, and guest

These terms show up in questions, logs, and vendor docs, so it helps to keep them straight.

Virtual machine (VM): A software-based computer that uses virtual CPU, RAM, disk, and network devices. It behaves like a normal PC, but it runs as an app or service.
Example: A Linux VM used to practice command line tasks.
Host: The physical computer that provides the real CPU, RAM, storage, and network.
Example: A Windows 11 desktop with 16 GB RAM.
Guest: The operating system running inside the VM.
Example: Ubuntu Linux installed inside a VM on that Windows 11 host.
Hypervisor: The software layer that creates and manages VMs. It controls how guests access host hardware.

At a high level, you will see two hypervisor types:

Type 1 (bare-metal): Runs directly on the hardware (common in servers and enterprise).
Example: Microsoft Hyper-V Server (or Hyper-V running as the primary virtualization layer in Windows).
Type 2 (hosted): Runs on top of a normal desktop OS like an application.
Examples: VMware Workstation, Oracle VirtualBox.

For exam purposes, remember the simple picture: host hardware runs a hypervisor, which runs one or more guests inside VMs.

Hardware virtualization features, how to spot them in BIOS or UEFI

Most modern VMs rely on CPU features that help the hypervisor run guest operating systems safely and with good performance. If those features are disabled, a VM may refuse to start, or the hypervisor may not install.

The two key CPU extensions are:

Intel VT-x: Intel’s hardware virtualization support.
AMD-V: AMD’s hardware virtualization support.

When VT-x or AMD-V is off, you may see messages like “hardware-assisted virtualization is not enabled” or “VT-x is disabled in the BIOS.” Some 64-bit guests also fail to boot if the hypervisor cannot use these extensions.

In BIOS or UEFI, vendors use different names for similar settings. Common labels include:

Virtualization Technology (often Intel systems)
SVM Mode (common on AMD systems)
Intel VT-d or IOMMU (often tied to device pass-through, not always required for basic desktop VMs)
IOMMU (AMD term, similar idea)

A safe support approach matters as much as knowing the setting name. Use a simple, repeatable workflow:

Document current settings before you change anything (photos work well).
Change only what is needed (usually VT-x, AMD-V, or SVM Mode).
Save and reboot, then confirm the OS and hypervisor detect the change.

If you are working on a managed device, follow the organization’s change process. Some environments lock firmware settings with an admin password, which changes what you are allowed to do.

Common symptoms and quick fixes when virtualization will not work

Virtualization issues often look complex, but the root causes are usually basic. Start with quick checks that match the exam’s troubleshooting style: verify requirements, confirm settings, and check for conflicts.

Common symptoms include a hypervisor that will not install, a VM that will not start, or an error that says virtualization is not supported.

Practical checks that solve many cases:

Virtualization is disabled in BIOS or UEFI: This is the most common cause. Enable VT-x, AMD-V, or SVM Mode, then reboot.
Hyper-V conflicts with other hypervisors: On Windows, enabling Hyper-V (and related features) can block VMware Workstation or VirtualBox from using hardware virtualization. If the user needs a different hypervisor, you may need to disable Hyper-V features (using Windows Features), then reboot.
Nested virtualization limits: Running a VM inside a VM is possible in some setups, but it depends on the hypervisor, CPU, and settings. If a “guest VM” won’t run its own hypervisor, nested virtualization is a likely limit.
Not enough RAM, CPU, or disk: If the host is low on memory or storage, VMs may fail to power on or run very slowly. Confirm free space and available RAM before changing settings.
Windows features not installed: If the user expects Hyper-V but it is missing, check whether the correct Windows edition and optional features are enabled.
Firmware and driver issues after enabling features: Some systems need a BIOS or UEFI update for stable virtualization support. Treat firmware updates as a controlled change, follow vendor guidance, and avoid doing it casually.

Fast verification steps that are both exam-aligned and realistic:

In Task Manager (Windows), go to Performance > CPU and look for Virtualization: Enabled/Disabled.
Check Windows Features to confirm the needed virtualization components are installed (or disabled if they are causing conflicts).
If settings look right but detection is inconsistent, consider a BIOS or UEFI update from the system vendor.

Avoid deep registry edits for A+ level troubleshooting. The exam expects safe, visible checks and reversible changes.

Virtualization and security, why it changes your risk picture

Virtual machines provide isolation, which is helpful for testing and containment. Isolation is not the same as security. A VM can still be compromised, and a weak host can put every guest at risk.

A few common risks show why virtualization changes the security picture:

Shared clipboard and shared folders: These features improve convenience, but they also create data paths between host and guest.
Unpatched hypervisor or host OS: If the host is compromised, the attacker may access VM files, credentials, or networks.
VM sprawl: It is easy to create many VMs and forget them. Unused VMs often miss patches and keep old credentials.
Snapshots used carelessly: Snapshots are useful, but rolling back can re-introduce old vulnerabilities and outdated software.

Basic best practices a tech can apply without overstepping:

Keep the host OS and hypervisor patched on a regular schedule.
Restrict local admin rights on hosts that run VMs.
Separate test and production networks when possible, even if it is just using a different virtual switch or VLAN.
Use snapshots for short-term testing, and delete old snapshots when they are no longer needed.
If policy requires it, encrypt VM files and protect access to VM storage, since VM disks often contain sensitive data.

A good mental model is simple: the host is the foundation. If the foundation is weak, every VM on top of it becomes easier to attack.

Encryption basics for A+ techs, what you protect and what you can break

Encryption is how systems keep data unreadable to anyone who does not have the right key. For A+ support work, you do not need to explain math or cipher names. You need to recognize what is being protected, where the keys are stored, and why a normal change (like a BIOS update) can trigger a recovery screen.

A helpful way to think about it is this: encryption is a strong lock, but it only works if the key stays controlled. Your day-to-day job is to keep users working while you protect that key material. That means you can often restore access, but you should not try to bypass encryption without authorization.

At-rest vs in-transit encryption, how to tell the difference fast

The fastest distinction is based on when data is protected.

At-rest encryption protects stored data, even if someone steals the device or removes the drive. A common example is BitLocker on Windows. If a laptop is lost, BitLocker helps prevent a thief from reading the disk by plugging it into another computer. The user’s files are still there, but the disk contents remain unreadable without the proper keys.

In help desk work, at-rest issues often show up during startup, not during web browsing. You might see:

The PC cannot boot into Windows after a change.
A BitLocker recovery key prompt appears before Windows loads.
The user reports they never saw this screen before, and they are locked out.

In-transit encryption protects data while it moves across a network. The classic example is HTTPS (TLS) between the browser and a website. Another common case is a VPN, which encrypts traffic between the device and a company network.

In help desk tickets, in-transit issues often look like trust or connection errors. You might see:

A browser warning about a certificate (for example, “Your connection is not private”).
A VPN that fails to connect, drops often, or blocks certain apps.
A user who can reach the internet but cannot sign in to a secure site.

Keep the core idea clear: at-rest encryption is about stolen or lost devices, while in-transit encryption is about sniffing or tampering during network travel. If the symptoms appear before the OS loads, think at-rest. If the symptoms appear inside the OS when using a network service, think in-transit.

Where encryption keys live, passwords, recovery keys, and hardware-backed keys

Encryption depends on keys, not just passwords. A password can unlock access to a key, but the key is what actually encrypts and decrypts data. This matters because a user may “know their password” and still get stuck at a BitLocker recovery screen. The system is asking for proof that the device is trusted, not proof that the user remembers a login.

For BitLocker, organizations often rely on a recovery key as the safe fallback. This is a special key used to regain access when the system thinks something changed. Good environments store recovery keys centrally so support can retrieve them when needed. Common storage locations include:

Microsoft Entra ID (Azure AD) for cloud-joined devices
Active Directory for domain-joined devices
An MDM platform for managed endpoints (the device management tool may escrow keys)

From a support view, recovery key storage is not a “nice to have.” It is the difference between a quick fix and a full wipe and reload.

This also connects to hardware-backed key storage, which is the bridge to TPM and HSM topics.