Ubuntu 26.04 Tutorial / Plan a Virtual Machine Lab and Console Recovery

Plan an Ubuntu lab by deciding where it will run, what you will change, and how you will recover if remote access stops working. For an Ubuntu 26.04 VM, allocate suitable resources and a new virtual disk, then distinguish the roles of NAT networking, the virtual console, snapshots, and independent backups before installation.

Start with one VM and a clear purpose

A virtual machine (VM) is a separate execution environment that uses a share of a host computer's resources. If Windows is your host, for example, Ubuntu installed in the VM is the guest. The goal is an independent place to change settings and restore them. You do not need a complex network of several VMs at the start.

Use one Ubuntu Server VM for accounts, SSH, services, and backup restoration. Add a second Server VM as a client only when an exercise needs communication or access-policy comparisons. Several simultaneous VMs are unnecessary at the outset.

The existing Linux VM practice-environment guide covers the overall creation, installation, and recovery workflow. This article focuses on the configuration plan to complete before installing Ubuntu. Decide the following items for your own computer before working through the VM creation screens.

Check host and virtualization-tool requirements

Your virtualization software must support both the host operating system and its CPU architecture. Do not assume that an Intel or AMD x64 host and an ARM64 host support identical guests and features. Conventional VM instructions in this tutorial can follow the VirtualBox 7.2 workflow, but first confirm that the product and version support your host.

1. Record the host operating-system version and CPU architecture. Use Settings → System → About on Windows, or About This Mac on macOS.
2. Check memory available while your usual applications are open, as well as total installed memory. On Windows, Task Manager → Performance → Memory shows current usage.
3. Check free space on the drive that will store the VM. ISO files, virtual disks, snapshots, and exported VM files all use storage.
4. Check the tool's official host, guest, and hardware-virtualization requirements. Review coexistence with other virtualization features for your installed version.

See the VirtualBox 7.2 introduction for support and architecture, and the VM creation guide for resource allocation. If startup fails, compare the error with documented compatibility conditions before disabling Windows security or other virtualization features.

Plan CPU, memory, and disk allocation

The following figures are examples for planning a tutorial VM. They are not Ubuntu's official minimum requirements or a performance guarantee. Adjust them to host capacity and the software you will run. Memory allocated to a running VM reduces what remains available to the host, so leave enough for the host's own work.

Server requirements depend on installation method and workload. Check the Server installation guide together with service requirements. The allocation above is a lab-planning example, not an official minimum or performance guarantee.

A dynamically allocated virtual disk can grow towards its configured maximum. A small initial file does not remove the need to reserve future host space. Increasing the virtual disk's maximum size and expanding a partition and filesystem inside the guest are also separate operations. Starting with one new virtual disk, without directly passing through a physical host disk, reduces confusion about the installation destination.

Choose NAT, bridged, or host-only networking

Network Address Translation (NAT) is a convenient starting point for guest connections out through the host's network, such as package downloads. It does not guarantee that another computer, or the host, can connect directly to the guest's private address. SSH practice requires NAT port forwarding or another network arrangement suited to the exercise.

Bridged networking connects the guest as a device on the physical LAN. It follows that network's address allocation and security policies, so check permission on company, school, and public networks. Host-only networking can provide a lab segment between the host and VMs, but does not by itself provide internet access. The VirtualBox networking documentation explains the modes.

This tutorial starts with NAT and does not pre-expose ports for services that have not been installed. When you later need SSH from the host, you can consider port forwarding restricted to the host's loopback address. Select actual port numbers and permitted sources in that exercise. Bridging, cloud security rules, and router port forwarding are different settings.

Remote exercises use NAT on adapter 1 for internet access and a host-only network on adapter 2. Example addresses are host 192.168.56.1, Server VM .20, and Linux Server client .10. Create adapters in the VM creation lesson and configure both VMs through the static IP lesson’s networkd/Netplan procedure.

Do not invent an internet gateway or DNS server for the host-only interface. The 192.168.56.x plan assumes a new dedicated network. If it overlaps a VPN or another VM network, select a supported unused subnet and update all examples together. This differs from bridging onto the physical LAN or replacing the initial NAT address.

Prepare virtual-console recovery independently of SSH

SSH is remote access that depends on working networking and server configuration. An incorrect IP address, DNS setting, firewall rule, or SSH configuration can interrupt it. The virtual console in your VM window provides a guest-network-independent route to a display or login prompt. It does not fix failures of the host or virtualization program itself.

During installation, prepare a regular user account with the necessary administrative privileges and keep its password securely. After configuring SSH, confirm that the same regular user can still sign in through the VM window. Having an SSH key without knowing the console login credentials leaves you with fewer recovery options when remote access fails.

• Confirm console login in the VM window before changing networking.
• Keep an existing SSH session open until you have verified a new connection.
• Record original configuration contents, the commands used to apply changes, and how to undo the current change.
• If console login also fails, assess a known-good snapshot or another recovery route before changing accounts or boot settings blindly.

Distinguish snapshots, backups, and host sharing

A snapshot lets you return a VM to a saved state. Meaningful names for the clean installation and pre-network-change states make exercises easier to repeat. Snapshots stored on the same host device do not protect against that device failing or the VM folder becoming corrupted. Plan separate copies or exports of the shut-down VM and independent backups of important data. Check snapshot scope and restoration behavior in the VirtualBox VM management guide.

Do not assume that restoring a guest snapshot also rolls back data written to a host shared folder or an external server. Start with shared folders, bidirectional clipboard, and drag and drop disabled, then enable only the scope you need for a file-transfer task. Keep disposable practice files separate from originals that must be preserved.

Complete the configuration plan before installation

This Server lab template uses illustrative allocations, not measurements from tested hardware. Adapt it to your host and add the reason whenever you change a setting.

Goal: SSH, Nginx, and backup-restoration practice
Guest: Ubuntu Server 26.04 LTS, amd64
Host and virtualization tool: record actual OS and tool versions
Example resources: 2 CPUs / 4 GB RAM / new 30 GB dynamic disk
Initial network: NAT, no port forwarding
Console recovery: regular-user login in the VM window
Snapshot plan: clean-install after checking installation and updates
Independent storage: important settings, work, and recovery notes outside the VM
Initial sharing: shared folders and bidirectional clipboard disabled

Blank items identify preparation still needed before opening the installer. Being able to explain the host resources, destination disk, image, network route, console login, and location of recovery material gives you clear criteria for the choices in the VM creation process.