Creating a Virtual Machine

Lesson purpose

Creating a VM means more than completing a wizard. A supportable workload begins with a clear purpose, a suitable host, deliberate virtual hardware, trusted installation media, guest integration, and evidence that the resulting service works. This lesson covers two paths into virtualization: converting an existing physical workload and building a new VM from the ground up. The recurring classroom rule is simple: wizard completion creates virtual hardware; validation creates a usable and supportable workload.

Learning objectives

By the end of the lesson, students should be able to:

Explain P2V, consolidation, containment, V2V, V2P, and rebuild choices.
Assess dependencies, compatibility, downtime, consistency, and rollback before a conversion.
Distinguish hot and cold capture methods.
Prepare a host with sufficient hardware, firmware, storage, permissions, media, and network support.
Configure firmware, CPU, memory, disks, network attachment, and installation media from requirements.
Install guest tools and updates, then test protection, monitoring, security, recovery, and ownership.

1. Two ways workloads enter virtualization

Consolidation converts existing physical servers into VMs and retires unnecessary hardware after validation. Containment deploys new applications directly into a virtual infrastructure so future growth stays inside a managed platform. P2V is therefore a consolidation technique, while creating a new VM is commonly associated with containment, development, or a new service.

Other migration directions exist. V2V moves or converts a VM between formats or products. V2P places a virtual workload back onto physical hardware when a requirement demands it. A rebuild creates a clean VM and migrates application data instead of preserving every detail of the physical source. Rebuilding can be safer for an obsolete or compromised system, but it may require more application knowledge and testing.

2. P2V assessment and capture

Inventory the source before choosing a tool. Record services, startup order, schedules, service accounts, databases, shares, DNS, certificates, identities, external systems, hardware dongles, unusual controllers, drivers, firmware, and licensed devices. Define downtime tolerance, backup status, test criteria, rollback steps, and the decision point for retiring the physical source.

Hot conversion captures while the source remains active. It reduces downtime, but application data may change during the copy. Use application-aware quiescing or other consistency controls when the workload requires them. Cold conversion captures while the source is inactive. It improves state consistency at the cost of an outage. A rapidly changing database may need a cold window or an application-aware method even when the tool advertises hot cloning.

The controlled P2V workflow is:

Assess: inventory dependencies, capacity, downtime, compatibility, and rollback.
Capture: create a consistent image with a supported hot or cold method.
Adapt: map firmware, drivers, disks, networks, identity, and guest tools.
Validate: test function, performance, security, monitoring, backup, and recovery.

Keep the physical source intact and isolated until the virtual service passes acceptance tests. A successful image import does not prove that the application works.

3. Risks inherited from the source

P2V changes the platform, not the quality of the installed software. Legacy physical drivers may conflict with virtual devices. Duplicate hostnames, addresses, identifiers, or certificates can disrupt services if the physical and virtual copies are online together. An old disk layout may oversize the VM or consume unnecessary datastore capacity. Unpatched software, weak accounts, and technical debt survive the conversion.

Ask students which setting must change before both copies can be connected to the same network. The best answer should mention identity and addressing, not just “install guest tools.” This keeps P2V grounded in service dependencies rather than disk imaging alone.

4. Prepare the lab platform

The assigned desktop platform may be VirtualBox, VMware Workstation or Fusion, or another current course standard. Product labels change, but the conceptual choices remain: VM definition, virtual hardware, storage, networking, installation media, and guest integration. Avoid relying on outdated VMware Player download instructions when the course has selected a current product.

Before creating a guest, verify:

Hardware support: processor virtualization features and required firmware settings.
Capacity: enough CPU, memory, storage, and I/O for both the host OS and the VM.
Permissions: authorized installation, driver, network, and folder access.
Media: trusted OS images, checksums, licensing, updates, and guest tools.

A host with 8 GB of RAM cannot safely assign nearly all 8 GB to a guest and still provide a stable host environment. Hardware capability alone does not prove that firmware is enabled or that capacity is available.

5. Build the new VM from requirements

Start with workload requirements rather than wizard defaults:

Define: name the workload and record the OS, application, security, and service needs.
Allocate: assign firmware, CPU, memory, storage, networking, and devices.
Install: load the guest OS, patches, guest tools, and applications.
Verify: test function, performance, security, recovery, and documentation.

Identity and firmware

Use a clear inventory name that identifies purpose without exposing secrets. Select the closest supported guest OS family so the platform can offer sensible defaults. Match BIOS or EFI to the guest OS, disk layout, security requirements, and migration source. A firmware mismatch can prevent an intact disk from booting after conversion. VM display name, guest hostname, and directory name may be related but are not automatically the same identity.

CPU and memory

Assign enough vCPUs for parallel demand without creating needless scheduling delay. Give the guest enough base memory for the OS and applications while preserving host capacity and headroom for peaks. Right-size from observed metrics and service requirements. Maximum settings are not target settings; oversizing shifts contention to the host.

Virtual disks

Size for the OS, applications, data, updates, logs, and expected growth. A dynamically allocated disk consumes backing space as guest data grows. A fixed disk commits space earlier and makes physical usage more predictable. Controller and disk-format choices should match guest support, portability, and performance needs. Dynamic provisioning defers consumption; it does not create free capacity.

Network attachment

NAT: simple outbound access through the host with limited direct inbound reach.
Bridged: the guest behaves more like another endpoint on the external network.
Host-only: the guest can communicate with the host and selected guests without normal external access.
Internal or isolated: selected VMs communicate inside a private virtual network.

Choose reachability before the VM boots. Use NAT for simple Internet access in a lab. Use host-only or isolated networking for potentially unsafe exercises. A bridged guest is a real network endpoint and must follow the same security and addressing rules as other systems.

Installation media and first boot

Attach a trusted ISO to the virtual optical drive, set a sensible boot order, and provide valid guest licensing. A new VM initially contains virtual hardware, not an operating system. After the first boot, install supported guest additions or integration services, patch the OS and tools, verify time and identity settings, test clean shutdown and restart, and check device status and connectivity. Remove the installer from the boot path if the guest keeps returning to setup.

6. Make the VM supportable

A build is not finished until it can be operated safely:

Harden: remove defaults, limit access, configure firewalling, and apply policy.
Protect: define backup scope, test restore, and use snapshots only for appropriate short-term changes.
Monitor: collect availability, capacity, performance, and security signals.
Document: record owner, purpose, dependencies, configuration, and recovery steps.

A VM that works today but has no owner or tested restore path is an operational risk. Shared clipboard and folder features can weaken isolation. Enable them only when the lab needs them and explain the tradeoff.

Classroom application

Have students write a build worksheet for a small web or file server. Require a purpose, guest OS, vCPU count, memory, disk type and capacity, network mode, ISO source, guest tools, patch plan, backup scope, and acceptance tests. Then give them four decisions:

A database cannot tolerate inconsistent in-flight capture: use cold or application-aware capture.
A wizard proposes excess CPU: right-size from evidence and host capacity.
The guest boots with poor device integration: install supported guest tools.
The VM works but no restore has been attempted: test recovery before handoff.

Students should explain the governing requirement for each answer, not repeat a product button name.

Common misconceptions

P2V is not “copy the disk and turn it on.” Dependencies, identity, drivers, licensing, and rollback matter.
Hot conversion does not guarantee application consistency.
Cold conversion improves consistency but does not remove compatibility or validation work.
Wizard defaults are not workload requirements.
More CPU or memory can make a shared lab slower by starving the host or increasing contention.
Dynamic disks defer physical consumption; they do not eliminate capacity planning.
A bootable VM is not necessarily secure, recoverable, monitored, or supportable.
Snapshots are change-management tools, not independent backups.

Lesson summary

Virtualization projects begin with a decision about whether to convert an existing workload or build a new one. P2V requires assessment, consistent capture, adaptation, validation, and rollback planning. New VM creation requires host readiness and deliberate choices about firmware, CPU, memory, disks, networking, media, and guest tools. The final standard is a tested service with protection, monitoring, documentation, and ownership. The next lesson can build on this foundation by installing and configuring the guest operating system.