← BACK TO THE SIMPLE VERSION
PROPER INSTRUCTIONS

Install Linux in a virtual machine: proper instructions

Photograph of a monitor displaying Ubuntu 24.04 system information and an Ubuntu logo in a terminal window.
Photo by Cong Long Vu (@vclong2003) on Unsplash; free to use under the Unsplash License.

A virtual machine runs Linux as a guest inside a window on an existing computer. Its virtual disk is normally a file on the host, which makes it a good place to learn installation, command-line work and application testing without partitioning the host drive. It is still a real operating system: allocate resources sensibly, update it and make a snapshot before experiments.

Prerequisites

Prepare the host

  1. Install host updates and update the hypervisor. Restart if its installer asks.
  2. On Windows, open Task Manager, Performance, CPU and confirm Virtualization says Enabled. On Linux, run
    lscpu

    and inspect the virtualisation line.

  3. If it is disabled, enter UEFI or BIOS setup and enable only the VT-x, AMD-V or SVM option. Save and boot the host again.
  4. Verify the ISO before use. PowerShell can calculate it with
    Get-FileHash ./linux.iso -Algorithm SHA256

    . Linux and macOS use

    sha256sum linux.iso

    .

Create the guest

  1. Create a machine with a meaningful name such as Ubuntu-Lab, select Linux as the type and attach the ISO as optical media.
  2. Allocate two virtual processors and 4 GB memory for a usual graphical desktop when the host can afford it. Do not give the guest all cores or most host memory.
  3. Create a 25–40 GB virtual disk. Dynamic allocation initially uses only written space but can still grow to its configured maximum; ensure the host has room.
  4. Use NAT networking for a first VM. It usually gives the guest web access without placing it as a directly reachable device on the local network.
  5. Review the machine settings before starting. The virtual disk should be new, the ISO should be attached, and the guest should not have access to a physical host disk.

Install and check

  1. Start the VM and select the installer or live environment. Set language, keyboard and time zone, then test the keyboard in a text field.
  2. For storage, select the newly created virtual disk shown by its expected small size. It is normal for guided partitioning to erase this virtual disk. Stop if an unfamiliar physical drive appears.
  3. Create a standard user and unique passphrase, finish installation, then detach the ISO before rebooting. Otherwise the VM can restart the installer.
  4. Log in and run
    cat /etc/os-release

    to confirm the installed distribution. Run

    lsblk

    and

    df -h

    to confirm disk and free space.

  5. Apply updates using the distribution’s updater. For Ubuntu or Debian, review the summary from
    sudo apt update
    sudo apt upgrade

    before accepting it.

  6. Install supported guest tools for display resizing and pointer integration, reboot, cleanly shut down, then create a snapshot named Fresh install.

Safety, rollback and mistakes

A snapshot returns the VM configuration and virtual disk to an earlier state. It is not an independent backup; important guest files need a copy outside the VM. Before untrusted software, disable shared folders, shared clipboard and drag-and-drop, use NAT and make a powered-off snapshot. Never configure raw physical disk access for a learning machine.

The combination of verified media, bounded resources and a fresh-install snapshot makes the VM useful without making it disposable by accident.

Practical review before relying on it

Repeat the complete check once after a restart or on a different day. This catches assumptions caused by cached state, a forgotten setting or an incomplete first run. Record the exact version, device or location involved and keep the successful configuration with the project. When something fails, change one condition at a time, repeat the relevant check and note the result. That approach is slower than random adjustment for one attempt, but much faster when the process must be repeated or explained to someone else.

Do not treat a successful screen message as the only evidence. Check the intended output directly, check that the original data or host system is still healthy, and keep a known-good fallback. A small reversible workflow is more valuable than a complicated one that only works once. When the task becomes routine, keep the same final verification rather than assuming automation removes the need to inspect outcomes.