virtualization
/virtualization
Opisuje architekturę wirtualizacji i izolacji: hypervisory typu 1 i 2, wnętrze kontenerów (namespaces, cgroups), microVM i kompromis między izolacją a narzutem.
- Autor
- claude-dev-suite ↗
- Repozytorium
- claude-dev-suite ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 21.10.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 21.10.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Opisuje architekturę wirtualizacji i izolacji: hypervisory typu 1 i 2, wnętrze kontenerów (namespaces, cgroups), microVM i kompromis między izolacją a narzutem.
Wyzwalacze z opisu
Oryginalny opis (EN)
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`).
Jak działa
- The isolation ↔ overhead spectrum (pick the weakest sufficient boundary)
- Mechanics worth pinning down
- When to recommend what
Podgląd 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.
Wersje
W bazie nie ma innych skilli o nazwie virtualization.
Migawka bazy z 28.10.2026 · wersja paczki 31aa54fbb14e (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100sota-sandboxing
Wspiera projektowanie i audyt izolacji dla niezaufanego kodu, wieloużytkownikowych obciążeń i agentów AI: najmniejsze uprawnienia, microVM, gVisor, kontenery, WASM, seccomp i cgroups. - 100sandbox
Kieruje do właściwej metody izolowania agentów AI według systemu operacyjnego, poziomu izolacji i skali wdrożenia, porównując gVisor, Kata, Apple Container i Docker. - 100overview
Pomaga dobrać platformę wirtualizacji i hypervisor, planować live migration, HA oraz migracje V2V między platformami. - 100containers-internals
Wyjaśnia wnętrze kontenerów Linux: namespaces (clone, unshare), limity cgroups v2, overlayfs, runc, profile seccomp, capabilities, specyfikację OCI oraz środki zaradcze przed ucieczką z kontenera. - 100containers-internals
Wyjaśnia prymitywy kontenerów Linux: przestrzenie nazw, cgroups v2, overlayfs, runc ze specyfikacją OCI, seccomp-bpf i capabilities, gdy trzeba je opisać lub na nich budować. - 100kata-on-gke
Instaluje Kata Containers na samodzielnie zarządzanej puli węzłów GKE, aby uruchamiać obciążenia agentów w mikromaszynach wirtualnych z izolacją sprzętową przez kubernetes-sigs/agent-sandbox.