← Back to Course Index

Week 9 Lab 2: Compute Lifecycle Operations

Module: Operating Systems 3 (Virtualisation & Cloud Technologies)

Estimated Time: 45 Minutes
Lab Type: Operations / Troubleshooting

Lab Overview

In Lab 1, you successfully launched nebula_web_01. Now, you must manage it. Real-world cloud engineering is rarely just "firing and forgetting." You need to debug boot issues, scale resources up when traffic hits, and perform maintenance.

In this lab, you will act as the Nebula Operations Team to perform "Day 2" actions on your infrastructure.

Objectives:

1. Deep Inspection: Identify which physical hypervisor is hosting your VM.
2. Troubleshooting: Use the Console Log to debug "headless" servers.
3. Vertical Scaling: Resize the instance to add more RAM.
4. Power Management: Pause and Unpause the instance.

Prerequisites:

• Week 9 Lab 1 Completed (Instance nebula_web_01 exists).
• SSH Access to the controller.
• source admin-openrc.

Part 1: Deep Inspection (Where is it?)

The dashboard tells you the VM is "Running," but where? In a private cloud, you handle the hardware too.

1. Show Instance Details: bash openstack server show nebula_web_01

2. Identify the Host:

   • Look for the field OS-EXT-SRV-ATTR:host.
   • Question: What is the name of the Compute Node (Hypervisor) running your VM? [ ________________ ]

3. Identify the Hypervisor Type:

   • Look for the field OS-EXT-SRV-ATTR:hypervisor_hostname.
   • This confirms strictly which physical kernel controls your process.

Part 2: "Headless" Debugging (Console Log)

You cannot plug a monitor into a cloud VM. If SSH fails, how do you see why it didn't boot? You read the Serial Console log.

1. Fetch the Log: bash openstack console log show nebula_web_01

2. Analyze:

   • Scroll through the output. This is the exact text you would see on a physical screen during boot.
   • Find: The line where it requests an IP address from DHCP (Sending discover...).
   • Find: The line where it finishes booting (CirrOS 0.5.1 login:).
   • Note: If your VM is stuck in BUILD or ERROR, this log is empty or contains the crash report.

Part 3: Vertical Scaling (Resize)

Scenario: The marketing team says nebula_web_01 is crashing under load. The 512MB RAM (m1.nebula_micro) is insufficient.

1. Create the Target Flavor: We need a "Small" flavor to upgrade to. bash openstack flavor create --id auto --ram 1024 --disk 5 --vcpus 1 m1.nebula_small

2. Request Resize: OpenStack will prep the new resources. bash openstack server resize --flavor m1.nebula_small nebula_web_01

3. Poll Status: bash openstack server list

   • Wait until Status is VERIFY_RESIZE.
   • Concept: The VM is now paused, and the files have been migrated to a new localized spot with higher limits. OpenStack allows you to "Rollback" if the app fails on the new size.

4. Confirm Resize: We accept the change. bash openstack server resize confirm nebula_web_01

   • Status should return to ACTIVE.

5. Verify: bash openstack server show nebula_web_01

   • Check the flavor field. It should now say m1.nebula_small.

Part 4: Maintenance (Pause vs Suspend)

You need to patch the underlying hypervisor. You want to freeze the VM without shutting it down fully.

1. Pause (Freeze in RAM): This keeps the state in memory but stops the CPU. Instant resume. bash openstack server pause nebula_web_01

   • Check status: PAUSED.

2. Unpause: bash openstack server unpause nebula_web_01

3. Suspend (Freeze to Disk): This writes the RAM to the hard drive (like Hibernate). Slower, but survives a power cut. bash openstack server suspend nebula_web_01

   • Check status: SUSPENDED.

4. Resume: bash openstack server resume nebula_web_01

5. Clean Up (Termination)

Our shift is over. We will delete the resources to save money (simulated).

1. Delete the Instance: bash openstack server delete nebula_web_01

2. Delete the Security Group: bash openstack security group delete nebula_web_sg (Note: You cannot delete a group if a generic VM is still using it).

Lab Checkpoint

• I have identified the Hypervisor Host (OS-EXT-SRV-ATTR:host).
• I have viewed the boot logs using console log.
• I have successfully resized the VM from Micro to Small.
• I have tested Pause and Suspend states.
• I have cleaned up my environment.

Reflection: 1. Why does Resize require a generic "Confirm" step? Why isn't it automatic? 2. What is the main difference between Pause and Suspend regarding where the data lives?

Instructor Signature: ___________________________ Date: ______________

← Back to Course Index