hypervisor是直接运行在物理硬件上的虚拟机管理器，负责创建和管理虚拟机；虚拟机是hypervisor创建的独立操作系统实例，依赖hypervisor分配资源并无法直接访问物理硬件。
要搞清Hypervisor和虚拟机的区别，不能只背定义——得看它们在物理服务器上各自干啥、谁依赖谁、谁先启动、谁管谁。比如你装好一台服务器，还没装任何系统时，Hypervisor可以直接“踩”在裸机硬件上运行；而虚拟机必须等Hypervisor建好虚拟环境后才能出生，它本质是一套独立的操作系统实例，连开机都要靠Hypervisor喂资源。
Hypervisor是管理者，虚拟机是被管理的“租户”
第一步：打开服务器电源→硬件初始化完成→BIOS/UEFI加载固件→直接跳过宿主操作系统，启动Hypervisor（如VMware ESXi或KVM内核模块）。
第二步：Hypervisor接管CPU、内存、磁盘控制器、网卡等全部物理资源，把它们切片、封装、抽象成可调度的虚拟资源池。
第三步：你在Hypervisor管理界面点击“新建虚拟机”→它分配一组虚拟CPU、虚拟内存、虚拟硬盘和虚拟网卡→再挂载ISO镜像→启动安装流程→最终跑起一个完整Linux或Windows系统——这个系统就是虚拟机。
这整个过程里，【虚拟机无法绕过Hypervisor直接访问物理硬件】。哪怕你在虚拟机里执行“lscpu”或“dmidecode”，看到的也是Hypervisor伪造出来的CPU型号和内存拓扑，不是真实物理设备信息。
两者存在不可逆的层级依赖关系
方法一：Type-1 Hypervisor（裸机型）场景下，Hypervisor = 底层操作系统。它不依赖Windows/Linux这类宿主OS，自身就是最小化内核+驱动+资源调度器。虚拟机完全运行在其之上，彼此隔离，故障互不影响。
方法二：Type-2 Hypervisor（宿主机型）场景下，Hypervisor只是Windows或Linux里的一个应用程序（如VirtualBox、VMware Workstation）。此时虚拟机启动路径变成：物理硬件 → 宿主OS内核 → Hypervisor进程 → 虚拟机Guest OS。多一层调用，性能损耗明显，且宿主OS崩溃则所有虚拟机瞬间断电。
注意：KVM是个特例——它本身不是独立Hypervisor，而是Linux内核的一个模块；但配合QEMU后，整体行为等效于Type-1，因资源调度由内核直接完成，不经过用户态中间层。
技术对比：从启动方式到资源控制粒度
① 启动时机：Hypervisor必须最先加载（甚至早于传统OS），否则无法接管硬件；虚拟机只能在Hypervisor就绪后手动或自动创建启动。
② 故障影响范围：Hypervisor崩溃=整台物理服务器所有虚拟机硬关机；单个虚拟机崩溃=仅该实例停止响应，其他虚拟机照常运行。
③ 资源分配权限：Hypervisor能精确到毫秒级分配CPU时间片、以KB为单位限制内存使用量、按IOPS上限管控磁盘吞吐；虚拟机内部的资源管理（如Linux cgroups）只能作用于自身进程，无法突破Hypervisor设定的硬边界。
④ 网络与存储栈位置：Hypervisor在物理网卡驱动之上构建虚拟交换机（vSwitch）和存储卷映射层；虚拟机看到的“eth0”实际是vSwitch端口，“/dev/sda”背后可能是NFS共享目录或iSCSI LUN——这些映射关系全由Hypervisor维护，虚拟机无权修改。
