Lesson 4: Virtual and Cloud Design Lab

Technology names are easy to shop for.

Requirements are harder.

That is why architecture should start with the job the system needs to perform, not with a favorite hypervisor or cloud provider.

Today you get one physical lab workstation and several competing requirements.

Your job is to decide where each workload boundary should live before configuring anything.

The host is finite

Supplied workstation:

CPU: 8 logical processors with virtualization support
RAM: 32 GB
free SSD space: 300 GB
network: Ethernet + Wi-Fi

That is enough for several training workloads.

It is not infinite.

Do not allocate every resource to guests and leave the host with nothing.

A system that technically accepts the configuration can still be badly designed.

Requirement A: complete Windows practice environment

Needs:

• complete Windows guest OS;
• 8 GB RAM target;
• 80 GB virtual disk;
• approved external network access;
• ability to preserve state before a major configuration exercise.

A full VM is a strong fit because the requirement needs an independent guest operating-system environment.

Now ask the second question:

Which host dependencies still matter?

• CPU capacity;
• host RAM;
• disk capacity and performance;
• virtual networking;
• snapshot location;
• host security.

The VM solves the environment boundary. It does not remove the host.

Requirement B: isolated Linux practice system

Needs:

• complete Linux guest;
• 6 GB RAM;
• 60 GB disk;
• no external network initially;
• ability to enable approved network access later.

A VM still fits.

What changes?

The network mode.

A host-only or internal/private virtual network may satisfy the initial isolation requirement better than bridged/external networking.

Later, the network can be changed deliberately when the exercise requires it.

Network mode is part of architecture, not a checkbox you click randomly until internet works.

Requirement C: packaged web tool

Needs:

• isolated application dependencies;
• repeatable deployment;
• no separate desktop or full guest OS requirement.

A container may be a better fit than a full VM.

Why?

Because the requirement is primarily an application/runtime boundary, not a complete machine boundary.

A VM could still run the workload, but it may add unnecessary guest-OS overhead.

Requirement D: centralized user desktops

Fictional organization requirement:

Users on lightweight endpoints should reach centrally hosted desktop sessions.

That points toward VDI.

Map the dependency:

endpoint
  ↓
network
  ↓
identity / authentication
  ↓
VDI broker / access service
  ↓
virtual desktop infrastructure
  ↓
user desktop / session

Now identify failure points outside the endpoint:

• network path;
• authentication service;
• VDI broker;
• virtualization host;
• profile or storage backend.

The user sees one desktop.

The technician sees a dependency chain.

Resource budgeting requires headroom

Suppose you plan:

Total guest RAM target: 22 GB.

Host physical RAM: 32 GB.

Is 10 GB of apparent headroom automatically enough?

Not necessarily.

You still need to consider host overhead, workload peaks, cache, other applications, and what the platform does under pressure.

The design should leave operating margin rather than maximizing allocation because the UI allows it.

Storage design includes recovery

For each virtual workload, ask:

• Where is persistent state stored?
• How large can it grow?
• What happens if the host SSD fails?
• Is a snapshot enough for the stated recovery goal?
• Is an independent backup or export required?

Example:

Snapshot before configuration exercise.

That is useful rollback protection.

If the host SSD fails, a snapshot stored on that same SSD disappears too.

Recovery design must match the failure you are trying to survive.

Security follows reachability

For every workload, record:

• which network it may reach;
• which shared folders or devices are exposed;
• who may start, stop, modify, or snapshot it;
• whether the guest or application is supported;
• what isolation must remain after the lab succeeds.

A sandbox that can reach everything is a very weak sandbox.

Cloud requirement E: hosted collaboration software

Users need a finished productivity application.

They do not need server administration.

Likely service model: SaaS.

Customer responsibilities still include identities, permissions, data-sharing decisions, retention, configuration, and user support.

Cloud requirement F: customer-controlled guest OS

The organization needs a cloud-hosted virtual server but wants control of the guest operating system and application stack.

Likely service model: IaaS.

The provider runs more of the physical infrastructure.

The customer still owns substantial guest and application responsibility.

Cloud requirement G: deploy code without managing the guest OS

The development team wants to deploy code into a provider-managed runtime.

Likely service model: PaaS.

The provider owns more of the underlying platform.

The customer still owns the application and data.

Deployment-model decisions are separate

Now decide whether each supplied organization fits public, private, hybrid, or community cloud.

Do not choose based on the word secure.

Choose based on:

• who shares the infrastructure;
• organizational requirements;
• integration needs;
• operational ownership;
• data and policy constraints.

A private cloud can be badly secured. A public cloud can be configured responsibly.

Deployment model and security quality are separate claims.

Add operational characteristics

For each cloud design, identify whether these matter:

• shared versus dedicated resources;
• multitenancy;
• elasticity;
• availability requirements;
• metered utilization;
• ingress and egress;
• file synchronization;
• independent recovery.

Do not add every cloud characteristic just to make the table look complete.

Use the characteristics that affect the requirement.

Fault injection: host memory exhausted

Evidence:

host RAM pressure: severe
paging: heavy
all VMs: slow
new large VM started immediately before symptom

Strong boundary: shared host resources.

Correction may involve reducing allocation, stopping an unnecessary workload, moving workloads, or adding capacity where the design supports it.

Verification should include host pressure and guest performance, not just "VM boots."

Fault injection: wrong virtual network mode

Evidence:

host network: healthy
VM NIC: connected
VM network: host-only
requirement: approved external access

The VM may be behaving exactly as configured.

The problem is the network-mode decision.

Correct the design deliberately, then verify both:

• required allowed path;
• required isolation boundary.

Do not define success as "internet works" if the environment was also supposed to remain isolated from another network.

Build the design record

For each workload, document:

requirement
chosen model
why the boundary fits
host/provider dependencies
CPU/RAM/storage requirement
network mode or path
security boundary
recovery requirement
responsibility split
one rejected alternative
one failure that would exist outside the guest/application

Include at least one full VM, container, VDI case, IaaS case, PaaS case, SaaS case, and cloud deployment-model decision.

Before you move on

Good infrastructure design begins with:

What needs to be isolated, who needs to control it, and which dependencies are acceptable?

Platform names come later.

Next we troubleshoot failures that deliberately cross those boundaries.