What is Virtual Machine?
Updated: 3 days ago
A virtual machine, usually shortened to VM, is a software-defined computer that runs an operating system and applications using virtual CPU, memory, storage and networking supplied from a physical host. The key distinction is that the VM behaves like a separate computer, but its hardware is virtualised rather than being a separate physical machine.
A hypervisor or virtualisation platform controls access to the underlying hardware. Multiple VMs can therefore share one physical system while remaining logically separated, although they still compete for finite host resources and their isolation is not the same as having completely independent physical hardware.
How does a virtual machine work?
A VM is presented with virtual hardware that resembles the components of a physical computer. The guest operating system sees virtual processors, memory, disks and network adapters. The virtualisation layer maps those resources onto the host's real CPU, RAM, storage and network interfaces.
vCPU: virtual processors scheduled onto the host's physical CPU resources.
Virtual memory: RAM allocated or made available to the VM from host memory.
Virtual disk: storage presented to the guest, commonly backed by files, logical volumes or other storage systems.
Virtual network adapter: a software-defined network interface connected through a virtual switch or equivalent networking layer.
Guest operating system: the operating system installed inside the VM, such as Windows or Linux.
What is a hypervisor?
A hypervisor is the virtualisation layer that creates and manages virtual machines and controls their use of host resources. It provides the abstraction that allows multiple guest operating systems to use the same physical hardware without each guest directly controlling that hardware.
Hypervisors are commonly described as Type 1 or Type 2. A Type 1 hypervisor runs directly on, or as the primary virtualisation layer of, the host platform. A Type 2 hypervisor runs as software on top of a conventional host operating system. Real implementations can blur this simplified distinction, so the architecture of the specific platform matters more than the label alone.
Virtual machine vs physical machine
Physical machine: has direct physical CPU, RAM, storage and network hardware dedicated to that system.
Virtual machine: is allocated virtual hardware backed by resources from a physical host.
Physical isolation: separate machines do not normally compete for the same local CPU and RAM.
Virtual consolidation: several VMs can share one host, improving utilisation but introducing resource contention if the host is overcommitted.
Portability: VM configuration and virtual disks can often be moved or replicated more easily than an entire physical server, subject to platform compatibility.
Virtual machine vs container
A VM and a container both provide isolated execution environments, but they operate at different layers. A VM normally includes its own guest operating system and virtual hardware. Containers generally share the host operating system kernel while isolating processes, filesystems and other resources.
That means containers can often start faster and use fewer resources, while VMs provide a stronger separation of operating system environments and can run different guest operating systems supported by the virtualisation platform. Neither approach is automatically better for every workload.
What resources does a VM use?
A VM consumes real host resources even though its devices are virtual. Allocating four vCPUs does not create four new physical CPU cores, and assigning 8 GB of memory does not create extra RAM. The hypervisor schedules and maps virtual resources onto what actually exists in the host.
Storage and networking work in the same way. A virtual disk ultimately depends on physical or networked storage, while a virtual network adapter ultimately depends on the host networking path unless the traffic remains entirely inside the virtual environment.
Techie Broadband calculation: VM network transfer capacity
Consider a practical example where a VM needs to transfer a 10 GB virtual disk image across a network. Using decimal units, 10 GB equals 80 gigabits. On a theoretical 1 Gbps path, 80 Gb ÷ 1 Gb/s = 80 seconds. On a theoretical 2.5 Gbps path, 80 Gb ÷ 2.5 Gb/s = 32 seconds.
These are theoretical payload-only calculations. Real transfer time will be longer because of protocol overhead, storage read and write performance, CPU processing, encryption, congestion and other traffic. The example shows why VM migration, backup and replication can become network-intensive even when normal interactive VM traffic is light.
How virtual machine networking works
A VM usually connects through a virtual network adapter to a virtual switch or equivalent software networking layer. From there, traffic may remain between VMs on the same host, reach the physical LAN through the host network interface, or travel across the broadband connection to remote services.
The VM can have its own IP address and can use IPv4, IPv6 or both, depending on the guest, virtual network and wider network configuration.
Virtual switches, VLANs and network segmentation
Virtualisation platforms can connect VMs to different virtual networks and, where supported, use VLANs to separate traffic. This can form part of a wider network segmentation design, but simply putting a workload in a VM does not automatically make its network secure.
Does a virtual machine need broadband?
No. A VM can run completely offline. Broadband becomes relevant when the guest needs internet access, remote administration, cloud services, software updates, off-site backups, remote storage, replication or migration between locations.
For remote VM workloads, available bandwidth affects how much data can be moved, while latency affects responsiveness. A faster broadband tier cannot compensate for a host that is CPU, memory or storage constrained.
VMs on UK broadband connections
For home labs and small business environments in the UK, the broadband connection matters most when VMs are accessed remotely or exchange substantial data with cloud services. FTTP can provide much higher upstream capacity than many legacy FTTC products, but actual upload speed, symmetry, IP addressing and other capabilities depend on the ISP, access network, retail product and location.
Hosting a service inside a VM also requires the wider network design to support inbound access where that is intended. Router configuration, firewall policy, CGNAT, public addressing, IPv6 and ISP terms can all matter. The VM itself does not bypass those network constraints.
Common uses for virtual machines
Server consolidation: run several server workloads on one physical host.
Development and testing: create disposable environments without changing the main computer.
Operating system testing: run another supported operating system without dedicating another physical machine.
Network labs: build routers, servers and client systems in a controlled virtual topology.
Legacy applications: maintain an older supported guest environment where the platform and licensing permit it.
Cloud computing: many cloud compute services are built around virtualised infrastructure.
Backup and disaster recovery: replicate or restore VM disks and configuration as part of a recovery design.
Snapshots and checkpoints
A snapshot or checkpoint records VM state or disk state so that a previous point can be restored, depending on the platform and checkpoint type. It is useful for testing and short-term rollback, but it should not automatically be treated as a complete backup strategy. Long chains of snapshots can consume storage and affect management or performance.
Microsoft's current Hyper-V documentation, for example, documents checkpoints as a VM feature and lists platform-specific limits. Those limits vary by host version and should be checked against the exact virtualisation platform rather than assumed universally.
Virtual machine performance and bottlenecks
VM performance is end to end. The guest can only perform as well as the resources and paths underneath it allow. A workload may appear to have adequate vCPU and memory but still be limited by shared storage, host CPU scheduling, memory pressure or network contention.
CPU contention: too many active vCPUs competing for physical processor time.
Memory pressure: insufficient host RAM, excessive overcommit or guest paging.
Storage latency: slow disks, overloaded arrays or heavy competing I/O.
Network contention: multiple VMs sharing the same physical interface or upstream connection.
Host overhead: virtualisation and device emulation consume some processing resources.
Guest limitations: the operating system, drivers or application can become the bottleneck.
How to troubleshoot a slow virtual machine
Check whether the problem exists inside the guest, on the host or across the network.
Inspect guest CPU, memory, disk and network utilisation.
Inspect host CPU scheduling, available RAM and storage latency rather than looking only at the VM.
Check whether other VMs are creating contention at the same time.
Confirm virtual network adapter and virtual switch configuration.
If the workload is remote, test network latency, packet loss and available throughput separately.
Check storage performance for the VM disk files or backing volumes.
Confirm that guest integration drivers or virtual device drivers are current and appropriate.
Compare performance at quiet and busy periods to identify shared-resource contention.
Change one resource or configuration variable at a time and retest.
Are virtual machines secure?
Virtual machines provide isolation boundaries, but they are not automatically secure. The guest operating system still needs patching, authentication, firewalling and appropriate access control. The host and hypervisor also become critical security components because compromise at that layer can affect multiple guests.
Remote administration should use appropriately secured protocols such as SSH where relevant, and management interfaces should not be exposed unnecessarily to the public internet.
Examples of virtualisation platforms
Examples include Microsoft Hyper-V and Linux KVM, alongside other commercial and open-source virtualisation platforms. The Linux kernel KVM documentation describes interfaces for creating VMs and virtual CPUs, while Microsoft's Hyper-V documentation covers virtual processors, memory, storage, networking, checkpoints and other VM capabilities.
Microsoft Hyper-V documentation explains current Hyper-V virtual machine features. The Linux kernel KVM documentation documents KVM's virtualisation interfaces and capabilities.
Frequently asked questions
What does VM stand for?
VM stands for virtual machine. It is a software-defined computer environment with virtual hardware on which a guest operating system and applications can run.
Can a virtual machine have its own IP address?
Yes. A VM can have one or more IP addresses just like other networked systems, subject to its guest configuration and the virtual network mode used by the host.
Can a VM run a different operating system from the host?
Often yes, provided the virtualisation platform and processor architecture support that guest operating system. Compatibility requirements vary by platform.
Is a virtual machine the same as remote desktop?
No. A VM is a computer environment. Remote desktop is a way of interacting with a computer across a network. You can use remote desktop technology to access a VM, but the two concepts are different.
Does a VM make broadband faster?
No. A VM does not increase the capacity of the broadband connection. Its network traffic still depends on the host networking, router, access network, ISP path and remote service.
Can multiple VMs share one network connection?
Yes. Multiple VMs can share a host's physical network interfaces and broadband connection. Their combined traffic can therefore contend for the same finite capacity.
Key takeaway
A virtual machine is a software-defined computer that receives virtual CPU, memory, storage and networking from a physical host through a virtualisation layer. VMs make it practical to run multiple isolated operating system environments on the same hardware, but they do not create unlimited resources. Real performance depends on the physical host, storage, virtual networking and, for remote workloads, the complete broadband and internet path.
To explore the related technical concepts used in this Virtual Machine guide, visit our broadband terminology guide.
