Install VirtualBox or VMware

02Choose a route before changing the host

This walkthrough uses VirtualBox. Its 7.1 guide supplies the interface reference; choose a currently supported installer for your actual host. Windows, macOS and Linux use different packages. Check both the host OS release and CPU architecture. Do not install an old release only to copy a tutorial's screens.

Hardware virtualization support helps a compatible processor run guests. Processor support, firmware settings, host policy and hypervisor compatibility all matter. A driver is software that lets the OS work with hardware; hypervisors can need host drivers. If a driver or virtualization requirement is unclear, use the text route and seek host-specific guidance before changing settings.

An existing compatible VMware installation is another possible route: Workstation for supported Windows/Linux hosts or Fusion for supported macOS hosts. Check Broadcom's current download, account and license requirements. You need only one hypervisor. This page's button names describe VirtualBox; use the vendor's own guide for a VMware installation.

ARM64 hosts, including Apple silicon Macs, need a supported host and guest combination. The amd64 Ubuntu image used by this walkthrough is not a universal ARM image. On a managed, mobile, unsupported or resource-limited device, choose the text route. Buying hardware or a service is unnecessary for the question.

03Prepare the host record

Read your host's About or System information: Windows Settings > System > About, macOS About This Mac, or your Linux desktop's About panel. For a Linux desktop, names may differ. Use its storage view for free disk space and system monitor for memory availability. Record the displayed units and architecture without changing settings.

Save ongoing work before installation. Installer permissions can allow changes to host drivers and networking, so read prompts before accepting them. If device policy prohibits installation, stop this route. Do not alter firmware, disable protections or bypass administrator controls to finish a lesson.

Prepare a hypervisor on the host
Keep this record private. Do not include passwords or serial numbers.

Your actual setup, if available:
Installation allowed by owner or administrator:
Host OS and release:
CPU architecture (x86-64 / ARM64 / other):
Installed RAM / currently available RAM:
Free storage / planned VM folder:
Vendor-supported host and guest combination:
Virtualization support/status, if shown:
Hypervisor name / full version / installer filename / official URL:
Current license and download requirements:
Result: manager opens / installation deferred, with reason

No-install reasoning cards (fictional):
A: Owned Windows 11 x86-64 laptop; installation allowed;
   16 GiB RAM, 7 GiB in use, 120 GiB free storage.
   Hypervisor compatibility and current installer have not been checked.
B: Managed ARM64 laptop; installation prohibited by its administrator.
   No permission to change the host or create a guest.
For each card, decide the next allowed action and what still needs checking.
Separate a host hypervisor installer from the future guest's Ubuntu ISO.

Conceptual order, not recorded screens:
Inspect host and permission -> choose compatible host installer ->
install on host -> open VM manager -> later create and install a guest.

Separate question case:
An empty VM manager has no guest OS yet.
Where must the hypervisor installer run?
Answer format: host or guest.

04Try the host installation route

Use these steps only if your host is compatible and installation is allowed. Otherwise continue to the no-install route below.

1. Fill the checklist's permission, OS release, architecture, RAM and free-storage fields. Compare the host with the vendor's current supported combinations. If compatibility or sufficient resources cannot be established, record the uncertainty and switch to the text route.
2. Use the official VirtualBox download link below. Select the host package matching your OS and architecture, then record its filename, full version and source. Read its license and prerequisites. The Extension Pack adds optional features and Guest Additions install inside a guest; neither is needed for this activity.
3. On Windows, open the downloaded installer and follow its prompts. On supported macOS, open the downloaded disk image and its installer package. On Linux, follow the vendor's instructions for your exact distribution and release. If installation requests a prerequisite you cannot explain, pause and keep the message for help rather than improvising commands.
4. Open VirtualBox Manager from the host's application list. Find About and record the full version. A new manager may show no VMs. Its opening establishes that the manager is available; it does not establish that Ubuntu is installed or that a guest can boot.
5. Close the manager and keep the installation for the next lesson. If you decide to remove the hypervisor, follow its host-specific uninstall instructions. Do not delete unrelated files or VM disks manually.

05Complete the no-install route

Use cards A and B in the host checklist. For each, write whether installation is allowed, whether the x86-64 walkthrough applies, and the next permissible action. Name the separate jobs of the host installer and the future Ubuntu ISO.

Review your reasoning: card A still needs vendor compatibility and installer checks before proceeding. Card B prohibits installation, so use the text route without changing that host. For both cards, an empty manager would still lack a guest OS. Write installation deferred in your note; a paper decision does not establish that the manager was opened.

06Optional challenge

Explain why the word 64-bit is insufficient to match a host and an ISO. Compare x86-64 with ARM64 and name the vendor compatibility table you would consult. No second hypervisor or image download is needed.

07Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Reading exercise only. Do not download, install or change a setting.
Host S: Windows, release W, x86-64. Owner approval for installation is recorded.
The case’s checked support matrix lists:
H1: Windows release W + x86-64 -> host package manage-W-x64.exe; amd64 guests supported.
H2: Linux release L + x86-64 -> host package manage-L-x64.pkg; amd64 guests supported.
H3: Windows release W + ARM64 -> host package manage-W-arm.pkg; ARM64 guests supported.
These are fictional route requirements, not current vendor support claims.
Also in the manifest: ubuntu-24.04.3-desktop-amd64.iso, guest installation media.
Resources, drivers and virtualization requirements for S have been checked for H1.

Host T is a managed Windows release W, x86-64 computer.
Its administrator has not approved installing software or changing drivers.
For this case, support, virtualization and driver requirements are already confirmed.
Installed RAM: 18 GiB. Existing OS/app reservation: 8 GiB. Guest proposal: 4 GiB.
Free storage: 100 GiB. Guest disk allowance: 32 GiB. Other setup allowance: 12 GiB.
The case requires at least 3 GiB unallocated RAM and 40 GiB free storage after allowances.
These simplified allowances are sufficient for this case, not a performance guarantee.

Start a separate case using the matrix on card A.
Host U has Windows release W and ARM64 architecture.
Approval, resource, driver and virtualization checks for H3 have passed in this case.
Available guest images: Desktop amd64 and Desktop ARM64.
No translation between instruction families is supplied by any route in this matrix.

An installer completed on the host.
The VM manager opens; its About panel shows a full version.
Its VM list is empty.
No guest has been created, installed or started.
This is fictional evidence for interpretation, not work you have performed.

08Write a setup decision with its evidence

Optional self-check: write a decision for host T. Include both resource calculations, the missing permission gate, the system that would run a host installer, and the separate role of the future guest ISO.

Review your note: technical checks passing does not grant administrator permission. Keep RAM and storage separate, use the exact supplied support row, and describe guest installation and boot as untested when all you have is an empty manager. These are reading decisions; record live installation as deferred.