Skip to content
Back to skills

Virtualization

ASecurity

Virtualization and isolation architecture: hypervisors (type-1/type-2), container internals (namespaces, cgroups), microVMs, and the isolation-vs-overhead spectrum. Architect-level choice of isolation boundary. USE WHEN: choosing an isolation/virtualization boundary, "hypervisor", "KVM", "type-1/type-2", "container", "namespaces", "cgroups", "microVM", "Firecracker", "gVisor", "Kata", multi-tenant isolation, sandboxing untrusted workloads. DO NOT USE FOR: Kubernetes/Docker operational confi...

  • 31 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 8, 2026
ai-agentsrustdockerkubernetessecurity

Security analysis

A100/100

Scanned September 8, 2026

npx -y skills add claude-dev-suite/claude-dev-suite --skill virtualization --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Virtualization?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Virtualization
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/claude-dev-suite-virtualization/badge)](https://www.skillsdirectory.com/skills/claude-dev-suite-virtualization)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: virtualization
description: |
  Virtualization and isolation architecture: hypervisors (type-1/type-2),
  container internals (namespaces, cgroups), microVMs, and the
  isolation-vs-overhead spectrum. Architect-level choice of isolation boundary.

  USE WHEN: choosing an isolation/virtualization boundary, "hypervisor", "KVM",
  "type-1/type-2", "container", "namespaces", "cgroups", "microVM", "Firecracker",
  "gVisor", "Kata", multi-tenant isolation, sandboxing untrusted workloads.

  DO NOT USE FOR: Kubernetes/Docker operational config (use infrastructure skills);
  OS internals (use `os-kernel-architecture`).
allowed-tools: Read, Grep, Glob
---
# Virtualization & Isolation

## The isolation ↔ overhead spectrum (pick the weakest sufficient boundary)

| Boundary | Isolation | Overhead / density | Boot | Fits |
|---|---|---|---|---|
| **Process + namespaces/cgroups (containers)** | Shared kernel → weakest | Lowest, highest density | ms | Trusted multi-service |
| **gVisor / user-space kernel** | Syscall interception | Moderate; some perf loss | ms | Semi-trusted, k8s-friendly |
| **microVM (Firecracker, Kata)** | Own kernel, tiny device model | Low-ish; ~125ms boot | fast | Untrusted multi-tenant (FaaS) |
| **Full VM (type-1 KVM/Xen, type-2)** | Strong, own kernel + devices | Highest per-VM | s | Strong tenant isolation, mixed OS |

Decision driver: **trust level of the workload**. Untrusted/multi-tenant code →
at least a microVM; trusted internal services → containers.

## Mechanics worth pinning down

- **Type-1** (bare-metal: KVM, Xen, Hyper-V, ESXi) vs **type-2** (hosted:
  VirtualBox). Hardware-assisted virt (VT-x/AMD-V, EPT/NPT) is assumed.
- **Containers** = namespaces (pid/net/mnt/user/…) + cgroups (CPU/mem/io limits)
  + capabilities + seccomp + (often) a userns for rootless. NOT a security
  boundary against kernel exploits by themselves.
- **microVMs**: minimal device model + own guest kernel → VM-grade isolation at
  near-container speed/density; the FaaS sweet spot (Lambda uses Firecracker).
- **Confidential computing**: SEV-SNP/TDX encrypt guest memory from the host —
  for untrusted-host scenarios (pairs with security architecture).

## When to recommend what
- Internal trusted microservices → containers + cgroups, seccomp, rootless.
- Run untrusted/tenant code → Firecracker/Kata microVMs or gVisor.
- Mixed OS / strong tenant separation / legacy → full VMs on type-1.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…