This simulator exposes a virtualization stack with a physical server, a hypervisor scheduling layer and two guest operating systems, each with its own virtual CPU and memory reservation. You set the CPU weights and memory sizes; the model then decides who is admitted and who owns each scheduling slot.
• An exploded 3D view of the host motherboard, the hypervisor scheduling layer, Guest A and Guest B with their vCPUs, and the guest memory mapping, each selectable for an explanation. • Controls for Guest A and Guest B CPU weight (1 to 4), each guest's memory reservation (1 to 7 GiB), and a Power on Guest B checkbox, with a Restart trial button. • Live readouts for A's scheduled CPU share, A and B executed slots, admitted memory, whether Guest B's admission was denied, and which guest currently owns the CPU. • One scheduling slot lasts 0.25 animation seconds, so you can watch ownership alternate and count slots over whole cycles.
When both guests run, A's share of CPU slots equals its weight divided by the sum of both weights, so weights 3 and 1 give A three times B's slots over complete cycles. Memory is handled separately and first: A is admitted first, and B boots only if the two reservations together fit in 8 GiB. If they do not, B is denied, A keeps its reservation and receives every slot. Stopping B has the same scheduling effect. The lab separates the two ideas on purpose — CPU is time-shared and proportional, memory here is reserved and fixed.
Reservations are fixed, with no overcommit, swapping, ballooning, nested virtualization or instruction emulation. The weighted policy is a generic teaching scheduler, not a description of any particular hypervisor product, and all capacities are teaching parameters rather than cloud-provider performance figures. A virtual CPU is a schedulable thing, not a promise of a dedicated physical core, and each guest keeps its own kernel and address space.
Yes. The hypervisor runs independent guest operating systems, each with its own kernel and address space. That is the main structural difference from a container, which shares the host kernel.
No. Virtual CPUs are time-scheduled on shared hardware. In this lab you can see it directly: with both guests powered on, the scheduler alternates ownership of the single CPU according to the weights.
Memory admission is checked before scheduling. A is admitted first, and B is admitted only if the sum of both reservations is at most 8 GiB. When B is denied, the readout shows the denial and A receives all scheduled CPU slots.
A's share is weightA divided by weightA plus weightB while both guests are running. With equal weights each gets half the slots; with weights 3 and 1, A gets three quarters. Over complete cycles the executed-slot counters match that ratio.