This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
The host, the guest, and what a snapshot is not
A virtual machine is a guest with virtual CPU, memory, disk, and a network interface, running on a host that has real ones. Overcommit means promising guests more than the host has, and it works until the guests ask for it at the same time. CPU overcommit is common. Memory overcommit is how a host starts swapping for every guest at once. Disk overcommit is how a thin volume fills up and pauses everyone.
Size the guest from a measurement on a real workload, or from a modest start you can grow. The VM sizing calculator turns a CPU and RAM request into a number. The host capacity calculator asks whether the host still has room after this guest. A guess of 16 CPUs because the form allowed it is how a quiet application pins a host.
A snapshot is a short undo of a guest disk while you try a change. It is not a backup. It lives on the same storage. It slows the guest if you forget it. The backup guide is the copy on different media. Delete the snapshot when the change is known good, or roll back and then delete it. Do not keep a chain of snapshots as an archive.
The guest's network is a real VLAN or a real subnet from the network desk, not a detail you invent inside the hypervisor and forget to route. The provisioning guide is how the guest gets an identity on first boot. This page is the shape of the guest before that boot.
One lab guest with a written size
The lab guest gets 2 virtual CPUs and 4 GB of RAM unless the measurement says otherwise, one disk large enough for the OS and the test data, and one NIC on the lab network. Write those four numbers in the ticket. Confirm the host still has CPU, available memory, and free datastore after the guest exists. If the host would be full, the guest does not get created on that host.
Install nothing you do not need. A guest that is also a desktop, a build server, and a file share is three guests or a decision to combine them. The first boot can be the provisioning image. You still take a console screenshot or a note of the name before you walk away.
Take a snapshot only for a change you can undo today, such as a package test. After the test, delete the snapshot or revert. Confirm the datastore free space returned. A snapshot left for a month is a change you forgot.
The calculators do not talk to the hypervisor. Paste their result beside the host's own free-memory reading. If they disagree, the host wins.
A change you can finish
A production guest is created at the size in the ticket, on the host the capacity note allowed, on the datastore that has the free space. The first backup runs after the guest is useful and before users depend on it.
Rollback of a new guest is to power it off and remove it if it never held unique data. Rollback of a change inside a guest is the snapshot you took for that change, used the same day, or the backup if the snapshot is already gone.
- Write vCPU, RAM, disk, and network.
- Read host free CPU, available memory, and datastore free space.
- Create the guest only if all three still have room.
- Boot it and confirm the name and the address.
- Snapshot only for today's change, then delete or revert.
- Schedule the backup. Do not count the snapshot as that backup.
- Record which host and which datastore, so a later move is a choice.
Mistakes that outlive the command
virtualization fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- A snapshot kept as the backup.
- Thin disks on a datastore with no free-space alert.
- Memory overcommit until the host swaps.
- A guest sized by the maximum the form allowed.
- Two NICs on networks you cannot explain.
- Cloning a guest and leaving the clone on the same name and address.
- A desktop install on a server guest because the ISO was handy.
- Forgetting which host the guest runs on, so maintenance reboots the wrong box.
Decisions to write down before the window
One decision for virtualization: vCPU, RAM, disk, and VLAN are numbers in the ticket, not leftovers from a template you did not read. The host capacity note says this guest fits, using the host's own free numbers. Snapshots expire today. The backup is a different copy. Thin provisioning has an alert before the datastore fills. The guest name is unique. A clone gets a new name and a new address before it boots on the network. One NIC unless the ticket draws the second. Provisioning is how it gets accounts. You do not log in as a shared root password from a wiki. The first backup is scheduled before users arrive. Rollback of a brand-new guest with no unique data is deletion. You have console access to do it. The calculator result and the host reading are both in the ticket. And a second person read the datastore name.
Virtualization checks before the guest is someone else's
Confirm this before you call the change done: The four size numbers match the running guest. Host free memory and datastore free space were read after creation. The guest name is unique on this network. The NIC is on the VLAN in the ticket. No snapshot older than this change remains, or the ticket says why. A backup job names the guest. The template password was changed or the image had none. A clone does not share an address with its source. The calculator output is filed next to the host reading. Console access works. A second person saw the host and datastore names. The guest is not also an unplanned second role. Rollback of this new guest is still possible because it has no unique data yet, or the backup already ran. The hostname in the prompt matches the hostname in the ticket for virtualization. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for virtualization happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- Comparison: VMware vs Hyper-V vs Proxmox
- Explainer: VMware Licensing Changes Explained
- How-To: How to Size VMs Correctly
- How-To: Cluster Capacity and N+1 Planning
- How-To: Proxmox VE Guide for Beginners
- How-To: Hyper-V PowerShell Guide
- How-To: VMware PowerCLI Guide
- How-To: KVM and libvirt Guide
- Checklist: VM Snapshots Best Practices
- How-To: VDI Sizing Guide
- How-To: Converting Virtual Disk Formats
Companion: Cloud: Cloud Migration Strategies (7 Rs).