A virtual private server (VPS) is a virtual machine on a shared physical host that runs its own operating system and reserves a defined share of CPU, memory and disk. The provider manages the hardware and the virtualization layer; the customer manages the server, usually with root access. The reservation is a share of the host, not a promise that the host is idle.
VPS in one paragraph
A physical server has a fixed amount of processors, memory, disk and network capacity. A virtualization layer divides that machine into isolated virtual servers. Each VPS receives an operating system image, a set of virtual processors, a memory allocation and a disk allocation. The provider keeps control of the physical host, the hypervisor and the network; the customer controls the guest operating system and the software on it [1].
That boundary is the useful definition. A VPS is not a smaller dedicated server, and it is not a shared hosting account with a new label. It is a server boundary drawn inside a shared machine. The boundary changes who patches the operating system, who chooses the software stack and what happens when another customer on the host uses more than its share.
VPS compared with shared and dedicated hosting
| Question | Shared hosting | VPS hosting | Dedicated hosting |
|---|---|---|---|
| What is reserved | An account on a server shared with many sites. | A virtual server with its own operating system and a defined CPU, memory and disk share. | The whole physical server. |
| Operating system | The host's stack; the customer usually has no choice. | An OS image chosen by the customer; KVM also allows a custom kernel. | Any supported OS, with full control. |
| Root access | No. | Usually yes. | Yes. |
| Who manages the server | The host manages the server, OS and control panel. | The customer manages the OS and application; the provider manages the host. | The customer manages the full stack, unless a managed service covers it. |
| How it scales | Change the plan. | Change the plan; the provider may need to reboot or move the virtual server. | Change the hardware, which takes longer. |
| Typical fit | A small site that needs a managed environment. | Custom software, a specific OS, root access or predictable resources. | A heavy database, a large workload or a single-tenant requirement. |
The three labels describe the isolation boundary, not the quality of the provider. A well-run shared account can be faster than a poorly configured VPS, and a VPS can be slower than a dedicated server if the application is the bottleneck. Compare the limit that matches the workload.
What the virtualization layer does
A hypervisor pools the physical CPU, memory, storage and network and allocates them to virtual machines. Each virtual machine is presented with virtual hardware: processors, memory, disks and a network adapter. The guest operating system runs on that virtual hardware and does not see the other guests. The provider can start, stop, clone or move a virtual machine without touching the other tenants on the physical machine [1][2].
The hypervisor is also the isolation boundary. It decides how much processor time a virtual machine receives, how memory is mapped and how disk and network requests are scheduled. The isolation is not absolute: the guests still share the physical CPU, memory bus, storage devices and network. A provider can oversubscribe a host, which means the sum of the virtual limits is larger than the physical capacity. The plan and the provider's policy decide how much contention is possible.
KVM and OpenVZ are different boundaries
Two VPS products can use the same word and behave differently. KVM is full virtualization: the Linux kernel acts as a hypervisor and each virtual machine runs its own kernel [3]. OpenVZ uses OS-level virtualization: isolated containers run on the host's Linux kernel instead of booting a separate kernel for each server [4][5]. The difference decides what you can change inside the server.
| Question | KVM VPS | OpenVZ VPS |
|---|---|---|
| Kernel | Each virtual machine runs its own kernel. | Containers use the host's Linux kernel. |
| Operating systems | Linux, FreeBSD and other systems from an ISO, depending on the provider. | Linux distributions that match the host kernel. |
| Kernel modules and settings | You can load modules and change kernel settings. | The host kernel is outside the container; you cannot replace it. |
| Isolation | A hypervisor boundary between the guest and the host. | A container boundary with a shared kernel. |
| Typical fit | A custom kernel, a non-Linux OS, cPanel or a stronger boundary. | A standard Linux stack on a smaller budget. |
OpenVZ containers are not virtual machines in the hardware sense. They have their own root access, users, IP addresses, memory, processes, files, applications, libraries and configuration files, but they use the host's kernel [4][5]. That design can be dense and efficient because there is no second kernel to boot. The trade-off is that the kernel is shared: a kernel change or a kernel-level requirement is a host decision, not a container decision. KVM avoids that limitation by giving each guest its own kernel [3].
What a VPS reserves, and what it still shares
A VPS plan usually states CPU cores, memory, disk, traffic and sometimes a CPU share. The numbers are limits or allocations, not a private machine. The physical host's processor, memory bandwidth, disk subsystem and network uplink are shared with the other virtual servers. A busy neighbour can still affect disk latency or network throughput, even when the CPU allocation is respected.
Three details deserve a place in the comparison:
- CPU. A core count describes how many virtual processors the guest sees. A share describes how much host CPU time the guest may use. The two are not the same, and providers measure them differently. Ask whether the plan is capped, burstable or oversubscribed.
- Memory. Reserved memory is not the same as available memory. A plan may include a dedicated allocation, a burst allowance or a ballooning policy. Check what happens when the host is under memory pressure.
- Disk and network. Disk type, disk I/O limits, port speed and monthly traffic decide the real ceiling. A large disk with slow I/O is not a performance plan. A fast port with a low traffic cap is not a busy site's plan.
The provider's service level agreement and backup policy are part of the product. A snapshot is not a tested restore. A network uptime guarantee is not an application uptime guarantee. Read both before comparing price.
When a VPS is the right choice
- You need root access. Installing a system package, changing a web server configuration or running a background service requires control that shared hosting does not give.
- You need a specific operating system or runtime. A project may depend on a distribution, a PHP version, a database version or a library that the managed plan does not offer.
- You need a predictable boundary. A VPS gives a defined CPU, memory and disk allocation, even though the host is shared. That is useful for staging, testing and workloads with a known ceiling.
- You run several sites or services. A single VPS can host more than one site, a mail server, a VPN or a small database, provided the plan's limits and the provider's policy allow it.
- You want to learn or migrate. A VPS is a practical place to run a staging copy, test an upgrade or move a site before a larger change.
When a VPS is not the right choice
If nobody on the team wants to patch an operating system, configure a firewall or watch disk usage, a managed plan is the better boundary. A VPS moves work to the customer; it does not remove the work. A small site with steady traffic may also fit shared hosting at a lower cost, and a site that needs the whole machine for a large database or a compliance rule may need a dedicated server.
A VPS is also not a fix for a slow application. A page builder that queries the database on every request, a missing cache or an unindexed table will consume the same CPU on a larger plan. Measure the bottleneck before moving up. The hosting layer can remove a resource limit; it cannot redesign the application.
How to read a VPS plan
- CPU. Note the core count and whether the plan states a share or a cap. Ask how the provider measures usage and what happens at the limit.
- Memory. Check the allocation, the swap policy and whether the value is guaranteed or burstable.
- Disk. Check the size, the technology and the I/O policy. Ask whether the disk is local or network storage and how snapshots are taken.
- Traffic and port speed. Find the monthly allowance and the port speed. A high port speed does not help if the traffic cap is low.
- IPv4 and IPv6. Confirm how many addresses are included and whether additional addresses are available.
- Location. Choose the region closest to the people who use the service, then test from that location. Distance is part of the budget.
- Control panel and support. Decide whether you want a panel, managed services or a bare server. Confirm who handles the operating system, the network and the application.
- Backup and recovery. Check the backup frequency, retention and restore path. Test a restore before you need it.
- Migration. Ask whether the provider helps move an existing server and what the cutover involves.
How DataExtend lists VPS plans
DataExtend separates KVM and OpenVZ because the two products have different boundaries. KVM plans start at $15.20 a month, with 2 to 8 CPU cores and 4 GB to 32 GB of memory. OpenVZ plans start at $13.00 a month, with 2 to 8 CPU cores and 4 GB to 16 GB of memory. KVM servers run in Chicago, Coventry and Sydney; OpenVZ servers run in Pori and Sofia. The order form shows the current operating systems, control panels, prices and stock.
Start with the boundary you need. If the project needs a custom kernel, FreeBSD, cPanel or a location that only KVM offers, compare the KVM VPS plans. If a standard Linux distribution covers the stack and the lower entry price matters, compare the OpenVZ VPS plans. The VPS overview puts both families side by side.
If the problem is a resource ceiling rather than a server boundary, a managed plan may be the smaller step. Semi-dedicated hosting adds CPU and database capacity without root access or operating system maintenance.