Cloud Architecture & Virtualization

Chapter 2
Virtualization Technologies and Resource Abstraction

Post Graduate Program in Information Technology
Cloud Architecture & Virtualization   •   Post Graduate

Virtualization Technologies and Resource Abstraction

Introduction

Cloud computing depends on the ability to separate physical infrastructure from the logical resources consumed by applications. Virtualization is the principal technology that creates this separation. It allows one physical server, storage system, network, or graphics processor to support multiple isolated consumers while presenting each consumer with a controllable logical environment.

Virtualization is not synonymous with cloud computing. A virtual machine may run in a private data centre without elasticity or self-service, while cloud computing adds automation, measured service, elasticity, and broad network access. Nevertheless, virtualization supplies many of the abstraction mechanisms on which infrastructure-as-a-service platforms are built.

This chapter examines hypervisors, virtual machines, containers, hardware-assisted virtualization, virtual networking, storage virtualization, desktop virtualization, and GPU virtualization. It also evaluates isolation, consolidation, scheduling, image management, performance, governance, and operational trade-offs.

Learning Objectives

After studying this chapter, the reader should be able to:

  1. Explain how hypervisors abstract processor, memory, storage, and network resources.
  2. Compare Type 1 and Type 2 hypervisors and distinguish virtual machines from containers.
  3. Analyse hardware-assisted virtualization and its effect on performance and isolation.
  4. Design and evaluate virtual networking and storage architectures.
  5. Explain desktop and GPU virtualization use cases and limitations.
  6. Evaluate consolidation, scheduling, image management, security, and performance trade-offs.
  7. Select an appropriate abstraction technology for a given workload and risk profile.

1. Resource Abstraction and the Virtualization Layer

A physical computing system contains processors, memory, buses, storage devices, network interfaces, and accelerators. Virtualization inserts a control layer that maps logical resources requested by guests to physical resources supplied by hosts. The mapping may be one-to-one, multiplexed, partitioned, emulated, or passed through directly.

A useful abstraction is:

Logical resource → virtualisation control layer → physical resource

The abstraction layer performs several functions:

  • Multiplexing: sharing one physical resource among multiple consumers.
  • Isolation: preventing one consumer from directly corrupting another.
  • Encapsulation: representing a workload as files, metadata, and configuration.
  • Portability: moving a workload between compatible hosts.
  • Policy enforcement: applying quotas, priorities, reservations, and security controls.
  • Measurement: attributing CPU time, memory, storage, and network use.

Abstraction introduces overhead and can obscure physical contention. Consequently, a virtual resource is not automatically equivalent to a physical resource. A virtual CPU may wait for a physical CPU; a virtual disk may share an array controller; and a virtual network interface may compete for a host uplink.

Important terminology

A host is the physical or operating environment providing resources. A guest is the operating system or workload using virtual resources. A virtual machine (VM) is an isolated software-defined computer. A hypervisor, or virtual machine monitor, controls VMs and mediates access to hardware. A container isolates application processes while sharing a host kernel. Overcommitment assigns more virtual capacity than the physical capacity available, relying on non-simultaneous demand. Pass-through gives a guest substantially direct access to a physical device.

2. Hypervisors and Virtual Machines

2.1 Type 1 and Type 2 hypervisors

A Type 1, or bare-metal, hypervisor runs directly on hardware. It manages guest operating systems, virtual CPUs, memory mappings, devices, and scheduling. It is common in data centres because it provides strong control, efficient I/O paths, and centralized management.

A Type 2 hypervisor runs as an application above a conventional host operating system. The host operating system owns hardware drivers and provides services to the hypervisor. Type 2 systems are convenient for laboratories, software development, testing, and desktop use, but add another software layer and a larger host attack surface.

The distinction is architectural rather than a complete measure of quality. Modern Type 2 products may use hardware acceleration, while some Type 1 products include substantial management software. Security, device support, operational tooling, and workload requirements should therefore be evaluated in addition to the label.

2.2 CPU virtualization

A guest operating system executes privileged instructions as if it controlled a processor. The hypervisor must ensure that such instructions cannot bypass isolation. Historically, this was achieved through trap-and-emulate techniques, binary translation, or paravirtualization. Modern processors provide hardware mechanisms that make this task more efficient.

A virtual CPU, or vCPU, is a schedulable execution context. The hypervisor maps vCPUs to physical CPUs or hardware threads. A VM with four vCPUs does not necessarily receive four physical cores continuously. It receives an entitlement governed by shares, limits, reservations, affinity, and current contention.

Important CPU scheduling concepts include:

  • Shares: relative priority when contention exists.
  • Reservation: guaranteed capacity, subject to platform conditions.
  • Limit: an upper bound on consumption.
  • Affinity: restricting execution to selected physical CPUs or NUMA nodes.
  • Co-scheduling: attempting to run related vCPUs together; useful for some parallel workloads but potentially harmful if it causes waiting.
  • Steal time: time a guest believes it could run but the hypervisor schedules another workload.

A basic utilization measure is:

U = Tbusy / Tobserved

where U is utilization, Tbusy is time spent executing useful work, and Tobserved is the observation interval. Both times must use the same unit. In a virtual system, host utilization and guest-reported utilization may differ because guest measurements do not always include scheduling delay, I/O wait, or steal time.

2.3 Memory virtualization

Memory virtualization maps guest virtual addresses to guest physical addresses and then to host physical addresses. The mapping can be implemented using shadow page tables or hardware-assisted second-level address translation, such as nested paging. The latter reduces software management overhead but still incurs translation and memory-access costs.

When memory is oversubscribed, a hypervisor may use page sharing, ballooning, compression, or host swapping. These techniques have different effects:

  • Page sharing identifies identical pages among guests, reducing duplication but creating scanning and security considerations.
  • Ballooning asks a guest driver to release memory voluntarily.
  • Compression stores inactive pages in compressed form, trading CPU cycles for reduced storage pressure.
  • Swapping writes memory pages to storage and can cause severe latency when active pages are repeatedly evicted.

NUMA systems divide memory into nodes associated with processor sockets. Accessing local memory is generally faster than accessing remote memory. A VM that spans NUMA nodes may gain capacity but experience higher and less predictable latency. NUMA-aware placement and sizing are therefore important for databases, analytics, and large in-memory applications.

2.4 Virtual I/O

Virtual devices may be emulated, paravirtualized, or passed through. Emulated devices maximize compatibility but require the hypervisor to imitate a hardware device and may have greater overhead. Paravirtualized devices use guest-aware drivers to communicate through efficient queues. Pass-through can approach native performance but reduces portability, live migration flexibility, and sharing.

The choice is a design trade-off rather than a simple hierarchy. A highly portable general-purpose VM may use paravirtualized devices, whereas a latency-sensitive network function or GPU workload may justify pass-through.

3. Hardware-Assisted Virtualization

Processor vendors provide virtualization extensions that introduce additional privilege modes and address-translation support. These extensions allow the hypervisor to control guest execution while reducing the need for complex instruction rewriting.

Hardware assistance commonly supports:

  1. Controlled entry into and exit from guest execution.
  2. Trapping of selected privileged operations.
  3. Second-level address translation for guest memory.
  4. Interrupt virtualization.
  5. Device isolation through an I/O memory-management unit.

The I/O memory-management unit translates device-generated addresses and restricts devices to assigned memory regions. This is essential for safe device assignment and protection against malicious or defective DMA operations.

Hardware assistance does not eliminate overhead. VM exits, translation misses, interrupt handling, synchronization, and shared-resource contention remain. Performance depends on workload characteristics, processor generation, device path, memory locality, and configuration.

4. Containers and Operating-System-Level Virtualization

A container packages an application and its dependencies while sharing the host operating-system kernel. Kernel mechanisms such as namespaces provide process, network, mount, user, and other forms of view isolation. Control groups, commonly called cgroups, regulate resource consumption. Union or copy-on-write filesystems support layered images.

Containers usually start faster and consume less memory than full VMs because they do not require a separate guest kernel. They are well suited to microservices, continuous integration, batch jobs, and portable application delivery. However, the shared kernel creates a different security boundary from that of a VM. A kernel vulnerability or unsafe privilege can affect multiple containers.

A VM is generally preferable when:

  • Different operating-system kernels are required.
  • Stronger tenant isolation is necessary.
  • The workload uses privileged kernel features.
  • Regulatory or organizational boundaries require independent operating systems.

A container is often preferable when:

  • Rapid startup and high density are important.
  • Applications are already designed as independently deployable services.
  • The organization can maintain a secure common kernel and image pipeline.

Many cloud platforms use both: containers execute inside VMs, combining VM-level tenant isolation with container-level deployment agility.

Image management

A VM image typically contains a virtual disk and metadata describing hardware, firmware, networking, and initialization. A container image is commonly composed of immutable layers referenced by content digests. In both cases, image management must address provenance, vulnerability scanning, patching, signing, retention, rollback, and secrets handling.

Images should be minimal, reproducible, versioned, and built through automated pipelines. Credentials should not be embedded in images. A digest or cryptographic signature provides stronger identity than a mutable human-readable tag. Golden images simplify compliance, but excessive standardization can produce large, infrequently patched images and hidden dependencies.

5. Virtual Networking

Virtual networking reproduces switching, routing, filtering, and connectivity functions in software. A typical design contains virtual network interface cards, virtual switches, port groups or segments, virtual routers, firewalls, load balancers, and physical uplinks.

A virtual switch forwards frames between VMs on the same host and toward physical interfaces when external connectivity is required. VLANs provide logical segmentation at Layer 2, while overlays such as virtual tunnel networks create logical networks over an IP underlay. Overlays improve mobility and tenant isolation but introduce encapsulation overhead, tunnel management, and troubleshooting complexity.

Network virtualization supports:

  • Tenant isolation through segmentation and policy.
  • Micro-segmentation between workloads.
  • Software-defined routing and firewalling.
  • Network-function virtualization.
  • Independent provisioning from physical cabling.

A simple throughput relationship is:

Reffective ≤ min(Rguest, RvSwitch, Ruplink, Rpath)

Here Reffective is achievable end-to-end throughput, while the other terms represent guest, virtual-switch, physical-uplink, and complete-path capacities. The inequality expresses a bottleneck bound, not a guarantee. CPU overhead, packet size, encryption, congestion, and queueing may reduce actual throughput further.

Virtual networks require observability. Administrators should correlate guest metrics, virtual-switch counters, overlay tunnel statistics, physical interface errors, flow records, and firewall logs. A healthy physical link does not prove that a virtual workload has adequate performance.

6. Storage Virtualization

Storage virtualization presents logical volumes, virtual disks, or object interfaces independently of the physical media. It may occur within a host, storage array, storage-area network, software-defined storage cluster, or cloud control plane.

Core mechanisms include thin provisioning, snapshots, replication, deduplication, erasure coding, caching, and automated tiering. Each mechanism changes capacity, performance, durability, or recovery characteristics.

Capacity efficiency can be expressed as:

Ecapacity = Clogical / Cphysical

where Clogical is the provisioned logical capacity and Cphysical is installed physical capacity. This ratio may exceed 1 under thin provisioning, but it does not mean that physical capacity has disappeared. If actual demand approaches physical capacity, allocation failures can occur.

Storage performance is multidimensional. IOPS measure operations per second, throughput measures bytes per second, and latency measures response time. A workload may require low latency rather than maximum throughput. Queue depth, access pattern, block size, cache effectiveness, replication traffic, and noisy neighbours affect results.

Snapshots are point-in-time representations, often implemented through copy-on-write metadata. They are useful for short-term recovery and testing but should not automatically be treated as independent backups. A failure affecting the underlying storage may affect both the original and its snapshots. Backups should have appropriate independence, retention, integrity verification, and restoration testing.

7. Desktop Virtualization

Desktop virtualization separates a user’s desktop environment from the endpoint device. In virtual desktop infrastructure, desktops execute in centralized VMs and are accessed through a remote display protocol. In session-based systems, multiple users share an operating-system instance through isolated sessions. Desktop-as-a-service extends these capabilities through a cloud provider.

Benefits include centralized patching, controlled data location, rapid provisioning, and support for contractor or remote workforces. Limitations include dependence on network quality, licensing constraints, endpoint security, user-experience variability, and high infrastructure demand during login storms.

A desktop design should analyse user personas rather than assume one universal VM size. Office workers, software developers, designers, call-centre agents, and data analysts have different CPU, memory, storage, graphics, peripheral, and availability requirements. Profile management and application delivery are as important as the desktop image itself.

8. GPU Virtualization

GPU virtualization enables multiple workloads to share a graphics processor or allows a VM to access an assigned GPU. Common models include:

  • Full pass-through: a physical GPU is assigned to one VM.
  • Mediated or partitioned access: a GPU is divided into virtual functions or profiles.
  • API remoting: graphics commands are processed through a service or protocol.
  • Time sharing: workloads take turns using GPU execution resources.

GPU virtualization supports virtual desktops, computer-aided design, scientific computing, machine learning inference, video processing, and rendering. The appropriate model depends on isolation, compatibility, memory requirements, latency, and the need for live migration.

GPU scheduling is complicated by long-running kernels, device memory pressure, context switching, and vendor-specific features. A workload that appears to have a fractional GPU may experience variable performance when neighbouring workloads use memory bandwidth or specialized execution units. Capacity planning should therefore use representative benchmarks rather than nominal allocation alone.

9. Consolidation, Scheduling, and Performance Trade-offs

Consolidation increases average hardware utilization by placing multiple workloads on fewer physical hosts. It can reduce capital cost, floor space, power consumption, and administrative effort. However, excessive consolidation increases contention, correlated failure impact, and performance unpredictability.

A basic consolidation ratio is:

CR = Nvirtual / Nphysical

where Nvirtual is the number of logical instances and Nphysical is the number of physical hosts or comparable physical capacity units. The ratio is only meaningful when the denominator and numerator are defined consistently; a VM-to-host ratio does not reveal CPU, memory, storage, or network pressure.

Scheduling policies may be fair-share, priority-based, reservation-based, deadline-oriented, or energy-aware. Cloud schedulers also consider affinity, anti-affinity, availability zones, licensing, data locality, NUMA topology, accelerator compatibility, and maintenance constraints.

The principal performance trade-offs are:

Design choiceMain benefitMain cost or risk
Higher consolidationBetter utilization and lower costContention and correlated impact
CPU overcommitmentMore flexible capacitySteal time and latency variation
Memory overcommitmentHigher VM densitySwapping and severe slowdown
Thin provisioningEfficient apparent capacityAllocation failure if growth is unmanaged
Pass-through devicesNear-native performanceLower portability and sharing
ContainersFast deployment and high densityShared-kernel risk
Strong reservationsPredictable performanceLower utilization
Live migrationMaintenance flexibilityNetwork, memory-copy, and device constraints

Performance evaluation should distinguish throughput, latency, tail latency, utilization, availability, and recovery time. Mean latency alone can conceal unacceptable 99th-percentile behaviour. Benchmarks should represent production access patterns and should be repeated under realistic co-tenancy.

10. Isolation, Security, and Governance

Isolation is multidimensional. CPU scheduling prevents direct execution interference but not necessarily side-channel leakage. Memory translation prevents ordinary address access but does not eliminate speculative-execution risks. Virtual networks isolate traffic only when segmentation and policy are correctly configured. Storage ACLs must protect both active volumes and snapshots.

Security controls include secure boot, measured boot, least-privilege management, signed images, dedicated administrative planes, patching, hardware-backed keys, tenant-aware logging, and strict control of privileged containers. The control plane is particularly sensitive because compromise may allow an attacker to manipulate many guests simultaneously.

Governance should define:

  • Who may create, modify, migrate, or delete workloads.
  • Which images and device types are approved.
  • How resource quotas and cost allocation operate.
  • How logs, snapshots, and images are retained and destroyed.
  • How personal, confidential, or regulated data is protected.
  • How failures and security incidents are reported.

Virtualization can improve governance by centralizing policy, but it can also create systemic risk. A single faulty template, orchestration rule, or management credential may affect an entire cluster.

11. Applied Case: Consolidating a University Research Data Centre

This is an illustrative case. A university operates 180 physical servers. Average CPU utilization is 12%, but several database and laboratory workloads require predictable latency. Researchers use Linux and Windows, and a machine-learning group requires GPUs. The institution wants to reduce energy use without weakening research isolation.

Background and problem

The existing environment contains underused servers, inconsistent backup practices, and several applications tied to particular physical machines. Some research groups require privileged kernel modules, while others run containerized services. A single consolidation policy would therefore be inappropriate.

Analysis

The architecture team classifies workloads into four groups:

  1. General administrative applications.
  2. Latency-sensitive databases.
  3. Containerized research services.
  4. GPU-intensive machine-learning and visualization workloads.

The team measures CPU, memory, storage latency, network throughput, peak demand, and dependency relationships over several weeks. It also identifies licensing restrictions and recovery objectives.

Approach and solution

General applications are moved to Type 1 hypervisor clusters using VM templates, paravirtualized devices, and moderate CPU overcommitment. Databases receive memory reservations, NUMA-aware placement, low-latency storage, and anti-affinity rules. Containerized services run in a managed container platform inside VMs; images are signed and scanned in the registry.

GPU workloads are divided between partitioned GPU profiles for interactive visualization and dedicated pass-through GPUs for experiments requiring predictable performance. Virtual networks separate administration, research, storage, and user traffic. Storage snapshots support short-term recovery, while independent backups are sent to a separate failure domain.

The institution retains several physical servers for applications requiring specialized hardware or unsupported drivers. This illustrates an important principle: modernization need not mean virtualizing every workload.

Outcome

The resulting design reduces the physical server count substantially while preserving reserved capacity for latency-sensitive systems. Resource dashboards expose steal time, memory pressure, storage latency, GPU utilization, and network drops. A quarterly capacity review prevents silent growth from exhausting thin-provisioned storage.

Learning points

The case demonstrates that consolidation is a classification and measurement problem, not merely a server-count exercise. Mixed abstraction layers can be beneficial, provided that their security boundaries, operational tools, and failure modes are understood.

12. Contemporary Developments and Best Practices

Several developments are shaping virtualization architecture:

  • Confidential computing uses hardware-protected execution environments to reduce exposure of data in use, although it may impose compatibility and performance costs.
  • Composable infrastructure pools compute, memory, storage, and accelerators for software-defined assembly.
  • Serverless and microVM technologies seek VM-like isolation with container-like startup times.
  • Infrastructure as code makes virtual networks, images, policies, and clusters reproducible and reviewable.
  • AI-assisted operations can detect anomalous utilization, forecast capacity, and suggest placement, but automated decisions require explainability, guardrails, and human oversight.
  • Disaggregated and accelerated systems increasingly combine CPUs, DPUs, GPUs, and specialized processors through programmable fabrics.

Recommended practices are to establish workload requirements before selecting an abstraction; maintain tested golden images; patch hypervisors and management planes promptly; use least privilege; monitor tail latency and contention; avoid uncontrolled overcommitment; design independent backups; test migration and restoration; apply anti-affinity to correlated failures; and document exceptions for pass-through or physical deployment.

Chapter Summary

Virtualization abstracts physical compute, memory, storage, networking, desktops, and accelerators into manageable logical resources. Type 1 hypervisors are common in data centres, while Type 2 hypervisors are useful for desktop and laboratory scenarios. Hardware-assisted virtualization improves execution and address translation but does not remove contention or configuration overhead.

VMs provide a strong operating-system-level boundary and broad compatibility. Containers provide rapid, dense application packaging but share a kernel and therefore require disciplined security. Virtual networking enables segmentation, overlays, software-defined routing, and policy enforcement. Storage virtualization improves flexibility through logical volumes, snapshots, replication, and thin provisioning, but capacity and recovery assumptions must be tested.

Desktop and GPU virtualization address specialized user and accelerator requirements. Consolidation and scheduling must balance utilization against predictability, isolation, failure impact, and cost. Effective architecture combines measurement, image governance, secure control planes, workload-aware placement, observability, and tested recovery procedures.

Key Terms

Hypervisor: Software that controls virtual machines and mediates access to hardware.

Type 1 hypervisor: A hypervisor that runs directly on physical hardware.

Type 2 hypervisor: A hypervisor that runs above a host operating system.

Virtual machine: An isolated software-defined computer with virtual hardware.

Container: An isolated application environment sharing the host kernel.

Overcommitment: Assigning more logical capacity than physically available, assuming demand is not simultaneous.

vCPU: A virtual processor execution context scheduled by a hypervisor.

NUMA: Non-uniform memory access architecture in which memory access cost depends on location.

Ballooning: A memory-reclamation technique using a guest driver.

Pass-through: Direct or near-direct assignment of a physical device to a guest.

Virtual switch: Software that forwards traffic among virtual interfaces and physical uplinks.

Overlay network: A logical network built over an underlying physical IP network.

Thin provisioning: Allocating logical capacity without immediately reserving equivalent physical capacity.

Snapshot: A point-in-time representation of a virtual disk or volume.

Image: A packaged template containing software, configuration, and metadata for deployment.

GPU virtualization: Sharing or assigning graphics-processing resources among virtual workloads.

Consolidation ratio: The ratio of logical instances or capacity to physical instances or capacity.

Steal time: Time during which a guest is ready to execute but is not scheduled on a physical CPU.

Micro-segmentation: Fine-grained network policy applied between workloads.

Confidential computing: Protection of data during processing through hardware-supported trusted execution.

Review Questions

Short Answer Questions

  1. What are the principal differences between Type 1 and Type 2 hypervisors?
  2. Why can a VM with four vCPUs fail to obtain the performance of four physical cores?
  3. What is the role of namespaces and control groups in containers?
  4. Why should a storage snapshot not automatically be considered a backup?
  5. Identify two benefits and two limitations of desktop virtualization.

Long Answer Questions

  1. Explain the mechanisms used for CPU, memory, and I/O virtualization, including the effects of hardware assistance.
  2. Compare VMs and containers in terms of isolation, portability, startup time, security, and operational management.
  3. Discuss the architecture and governance requirements of a virtual networking and storage environment.
  4. Evaluate the trade-offs among consolidation, overcommitment, reservations, and predictable performance.
  5. Explain the use cases and limitations of GPU virtualization models.

Analytical / Application Questions

  1. A service requires a different operating-system kernel, privileged modules, and strong tenant isolation. Should it be deployed as a container or VM? Justify the decision and identify any exceptions.
  2. A cluster shows low average CPU utilization but high 99th-percentile application latency. Which virtualization metrics and placement factors should be investigated?
  3. Design a mixed VM-container-GPU architecture for a research organization with administrative applications, latency-sensitive databases, containerized services, and machine-learning workloads. Explain isolation, scheduling, image, network, and recovery choices.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a Type 1 hypervisor?

A. It runs as an application on a host operating system.

B. It runs directly on physical hardware and manages guest environments.

C. It is a container image format.

D. It is a virtual storage protocol.

Correct Answer: B. It runs directly on physical hardware and manages guest environments.

Question 2

What is the principal isolation limitation of conventional containers compared with VMs?

A. Containers cannot use networks.

B. Containers require a separate physical server.

C. Containers share the host operating-system kernel.

D. Containers cannot be versioned.

Correct Answer: C. Containers share the host operating-system kernel.

Question 3

What does CPU steal time indicate?

A. Time spent encrypting a virtual disk

B. Time a guest was ready but was not scheduled on a physical CPU

C. Time required to create a container image

D. Time spent copying a snapshot to backup storage

Correct Answer: B. Time a guest was ready but was not scheduled on a physical CPU

Question 4

Which technique asks a guest operating system to release memory to the hypervisor?

A. Ballooning

B. Pass-through

C. Overlay routing

D. GPU partitioning

Correct Answer: A. Ballooning

Question 5

A virtual network overlay primarily provides which capability?

A. Replacement of all physical network hardware

B. A logical network constructed over an underlying network

C. Guaranteed elimination of latency

D. Automatic conversion of VMs into containers

Correct Answer: B. A logical network constructed over an underlying network

Question 6

A system provisions 120 TB of logical storage on 80 TB of physical storage using thin provisioning. What is the apparent capacity-efficiency ratio Ecapacity = Clogical / Cphysical?

A. 0.67

B. 1.00

C. 1.50

D. 2.00

Correct Answer: C. 1.50

Question 7

Which GPU virtualization approach normally provides the strongest dedicated performance for one VM but reduces sharing flexibility?

A. Full pass-through

B. Time sharing among containers

C. API remoting only

D. Text-based terminal access

Correct Answer: A. Full pass-through

Question 8

Why is a snapshot not necessarily an independent backup?

A. Snapshots cannot represent point-in-time states.

B. A failure in the underlying storage may affect both the source and snapshot.

C. Snapshots always require a physical tape drive.

D. Snapshots cannot be restored.

Correct Answer: B. A failure in the underlying storage may affect both the source and snapshot.

Question 9

Which placement policy reduces the risk that two replicas fail with one host?

A. Affinity placement

B. Anti-affinity placement

C. Unlimited overcommitment

D. Single-host co-location

Correct Answer: B. Anti-affinity placement

Question 10

Which metric is especially useful for detecting unacceptable occasional delays hidden by a low mean latency?

A. 99th-percentile latency

B. Image file size only

C. Number of VLAN names

D. Number of installed keyboards

Correct Answer: A. 99th-percentile latency

Cloud Architecture & Virtualization
Chapter 2 of 15