What is a virtual machine?

A virtual machine is a small assembly:

• A hypervisor - the layer that partitions the host and enforces isolation between guests.
• A guest operating system - booted inside the VM, with no view of its neighbours.
• Virtual devices - disk, network and clock interfaces presented to the guest, emulated or paravirtualised.
• An image - the template a machine is created from, holding the operating system and whatever else was baked into it.
• A lifecycle - create, start, pause, snapshot, resize, migrate, destroy, each addressable through an API.

Isolation is the property people buy. Two workloads sharing a physical host are separated by the hypervisor rather than by an operating system process, which is a stronger boundary and a heavier one - every guest carries its own kernel, and that cost is measured in memory and startup time rather than in risk.

The nearest rival to a VM is the container: a package sharing the host kernel, isolated by kernel features rather than by a separate operating system. Containers start faster and cost less memory; VMs give a hardware-level boundary and can run a different operating system on the same host.

Most systems use both. Virtual machines provide the nodes - the isolated, replaceable machines a control plane manages - and containers run on those nodes as the unit of deployment. Choosing between them is usually a question about the boundary you need, not a verdict on either technology.

VMs are what infrastructure as a service actually sells: an instance is a defined shape of machine created from an image on demand. The machinery behind that request is a cloud control plane, and OpenStack is the best-known open source example - it exposes the create, resize and destroy calls, plus the images, networks and quotas around them.

Beneath the control plane sits the hypervisor itself, commonly KVM on Linux hosts. The separation matters when evaluating a provider: the control plane determines what you can request, while the virtualisation layer determines how strongly the resulting machines are isolated from one another.

Images carry most of the operational weight. An instance is only as reproducible as the image it started from, so teams that treat images as build artefacts - versioned, rebuilt from a definition, discarded when obsolete - can treat machines as disposable. Teams that patch them in place after creation tend to discover that the control plane's idea of a machine and the machine's real state have drifted apart.

On VirtEngine, an instance is chosen by describing it: processor count, memory, image, region, network rules. That description is matched against published infrastructure listings where a provider states which shapes it will serve and on what terms, so the comparison happens on specification rather than on a sales conversation.

The tenant funds an escrow account when placing the order, the match becomes a lease binding the three parties together, and the provider's control plane builds the machine and meters its runtime. Usage arrives as signed records, drawn from escrow as line items after the dispute window, with anything unspent returned when the lease closes.

Choosing by attribute also makes the trade-offs visible. A shape picked for a steady workload can be resized when demand changes, and a snapshot offers a route back that a rebuild does not. What none of that repairs is a workload which assumed it owned the hardware underneath: kernel modules, timing assumptions and device access are the usual surprises when a machine stops being a fixed thing.