Explain virtual machines and concurrency basics

## 1) Virtual machines (VMs) ### What a VM is A VM is an abstraction that makes a single physical machine appear as multiple isolated “machines,” each running its own OS and applications. Key goals: - **Isolation/security:** faults or compromise in one VM should not affect others. - **Resource multiplexing:** share CPU/memory/disk/network across workloads. - **Portability:** package an OS + apps as an image. ### Hypervisors: Type 1 vs Type 2 - **Type 1 (bare-metal):** runs directly on hardware (common in servers). Better performance and isolation. - **Type 2 (hosted):** runs as an application on a host OS (common on laptops). Easier to use, more overhead. ### CPU virtualization (high level) - The hypervisor schedules **virtual CPUs (vCPUs)** onto physical CPUs. - Uses hardware support (Intel VT-x/AMD-V) to run guest code safely. - Privileged instructions trap to the hypervisor. - Concepts you can mention: - **Context switching** between VMs - **Overcommitment:** more vCPUs than physical cores; can cause “noisy neighbor” effects ### Memory virtualization - Each VM believes it has contiguous physical memory. - Hypervisor maps **guest virtual → guest physical → host physical**. - Uses shadow page tables historically; now mostly **nested page tables** (EPT/NPT) with hardware assistance. - Techniques: - **Ballooning:** reclaim memory from VMs under pressure. - **Copy-on-write** for fast cloning. ### Storage virtualization - Virtual disks (VMDK/QCOW2/etc.) map to files or block devices. - Benefits: snapshots, cloning, migration. - Tradeoffs: snapshot chains can degrade performance; write amplification. ### Network virtualization - Virtual NICs connect to virtual switches/bridges. - Overlay networks (VXLAN) allow multi-tenant segmentation. - Security: security groups/ACLs, microsegmentation. ### VMs vs containers (tradeoffs) - **VMs:** strong isolation (separate kernels), heavier, slower to boot, more resource overhead. - **Containers:** share kernel, lightweight and fast, but weaker isolation boundary (mitigated by seccomp/AppArmor/gVisor/Kata). --- ## 2) Concurrency ### Concurrency vs parallelism - **Concurrency:** multiple tasks making progress in overlapping time (can be on 1 core via interleaving). - **Parallelism:** tasks literally run simultaneously (requires multiple cores). ### Common primitives and what they’re for - **Mutex/lock:** mutual exclusion around shared state. - **Read-write lock:** many readers or one writer. - **Semaphore:** allow up to N concurrent accesses. - **Condition variable:** wait for a predicate to become true (avoid busy-wait). - **Atomics/CAS:** lock-free coordination for simple shared counters/queues. ### Race conditions and how to prevent them Race condition: correctness depends on timing/interleaving. Mitigations: - Reduce shared mutable state (immutability, message passing, actor model). - Protect shared state with locks; define clear ownership. - Use thread-safe data structures. - Make critical sections minimal; avoid blocking calls inside locks. ### Deadlocks: how they happen and prevention Deadlock typically requires all four: 1. Mutual exclusion 2. Hold and wait 3. No preemption 4. Circular wait Prevention strategies: - **Global lock ordering** (most practical). - Timeouts + retries (careful: can cause livelock). - Reduce lock granularity or use lock-free structures where appropriate. - Avoid calling unknown code while holding locks. ### Debugging concurrency issues in production A senior approach includes: - **Symptoms:** spikes in latency, CPU, thread count, or lock contention. - **Data collection:** - thread dumps / stack traces - mutex contention metrics - profiling (on-CPU vs off-CPU) - tracing spans to see blocking points - **Reproduction:** stress tests, deterministic schedulers where possible. - **Tools:** sanitizers (TSan), race detectors, deadlock detectors. - **Fix validation:** targeted tests + canary + rollback plan. ### Common pitfalls to mention - Assuming atomic operations imply overall thread safety. - Forgetting memory visibility/happens-before relationships. - Using condition variables without a loop around the predicate. - Holding locks across I/O or network calls.