Fixed hands-on lab instructions for two exercises as per the provided lab infrastructure

modules/container-resource-detection/pages/determining-cpu-availability-within-containers.adoc

@@ -60,14 +60,84 @@ cpu_shares: 51
 == Hands-on Exercise: Inspecting CPU Awareness
 In this short task, you will verify the JVM's CPU detection.
 
-1. **Inspect current CPU perception:**
-   Inside your running container, identify the Java process ID:
-   `jps`
+. **Create new project:**
++
+Use the following command to create a new OpenShift project:
++
+[source,bash]
+----
+oc new-project my-java-app
+----
+
+. **Launch the container:**
++
+Use the following command to launch a new container:
++  
+[source,bash]
+----
+oc create deployment my-java-app --image=quay.io/hummingbird/openjdk:latest
+----
+
+. **Connect to the container:**
++
+Use the following command to connect to your running container:
++
+----
+oc get pods
+oc rsh <pod-name>
+----
+
+. **Inspect current CPU perception:**
++
+Inside your running container, identify the Java process ID:
++
+[source,bash]
+----
+jps
+----
++
+Example output:
++
+----
+sh-5.3$ jps
+1 JShellToolProvider
+84 Jps
+27 RemoteExecutionControl
+sh-5.3$ 
+----
 
-2. **Query the VM metadata:**
-   Run the following command to see the active processor count:
-   `jcmd <pid> VM.info | grep active_processor_count`
+. **Query the VM metadata:**
++
+Run the following command to see the active processor count:
++
+[source,bash]
+----
+jcmd 1 VM.info | grep active_processor_count
+----
++
+Example output:
++
+----
+sh-5.3$ jcmd 1 VM.info | grep active_processor_count
+active_processor_count: 32
+sh-5.3$ 
+----
+
+. **Compare with OS-level tools:**
++
+Run `nproc` in the same terminal.
++
+[source,bash]
+----
+nproc
+----
++
+Example output:
++
+----
+sh-5.3$ nproc
+32
+sh-5.3$ 
+----
 
-3. **Compare with OS-level tools:**
-   Run `nproc` in the same terminal.
-   *Note: If `nproc` returns the node's total CPUs (e.g., 64) but `active_processor_count` returns your container limit (e.g., 2), your application is correctly container-aware.*
+NOTE: If `nproc` returns the node's total CPUs (e.g., 64) but `active_processor_count` returns your container limit (e.g., 2), your application is correctly container-aware. The above output indicates the currently running application is not container aware.

modules/risks-and-memory-management/pages/managing-off-heap-memory-in-containerized-environments.adoc

@@ -44,26 +44,127 @@ This activity guides you through identifying the native memory footprint of your
 === Step 1: Enable NMT and Inspect Memory
 Use `jcmd` to inspect the memory distribution of your running containerized application.
 
-1. Access the terminal of your running pod:
+. Access the terminal of your running pod:
 +
 [source,bash]
 ----
 oc rsh <pod-name>
 ----
 
-2. Run the NMT summary command:
+. Run the NMT summary command:
 +
 [source,bash]
 ----
-jcmd <pid> VM.native_memory summary
+jcmd 1 VM.native_memory summary
+----
++
+Example output:
++
+----
+sh-5.3$ jcmd 1 VM.native_memory summary
+1:
+Native memory tracking is not enabled
+sh-5.3$ 
+----
++
+NOTE: If you see "Native memory tracking is not enabled", you must enable it by adding the following JVM option:
+----
+-XX:NativeMemoryTracking=summary
+----
+
+. Delete the current deployment
++
+[source,bash]
+----
+oc delete deployment my-java-app
+----
+
+. Create a deployment configuration to enable NMT in the container:
++
+[source,bash]
+----
+cat > my-java-app.yaml << EOF
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: my-java-app
+spec:
+  replicas: 1
+
+  selector:
+    matchLabels:
+      app: my-java-app
+
+  template:
+    metadata:
+      labels:
+        app: my-java-app
+
+    spec:
+      containers:
+        - name: java-app
+          image: quay.io/hummingbird/openjdk:latest
+
+          env:
+            - name: JAVA_TOOL_OPTIONS
+              value: "-XX:NativeMemoryTracking=summary"
+EOF
+----
+
+. Create the deployment:
++
+[source,bash]
+----
+oc apply -f my-java-app.yaml
+----
+
+. Access the terminal of your new running pod:
++
+[source,bash]
+----
+oc rsh <pod-name>
+----
+
+. Inspect the memory distribution:
++
+[source,bash]
+----
+jcmd 1 VM.native_memory summary
+----
++
+Examle output:
+----
+sh-5.3$ jcmd 1 VM.native_memory summary 
+Picked up JAVA_TOOL_OPTIONS: -XX:NativeMemoryTracking=summary
+1:
+
+Native Memory Tracking:
+
+(Omitting categories weighting less than 1KB)
+
+Total: reserved=33545316KB, committed=288676KB
+       malloc: 59876KB #80575, peak=111544KB #81451
+       mmap:   reserved=33485440KB, committed=228800KB
+
+-                 Java Heap (reserved=31424512KB, committed=147456KB)
+                            (mmap: reserved=31424512KB, committed=147456KB, at peak)
+
+. . . 
+
+-      String Deduplication (reserved=1KB, committed=1KB)
+                            (malloc=1KB tag=String Deduplication #8) (at peak)
+
+-           Object Monitors (reserved=75KB, committed=75KB)
+                            (malloc=75KB tag=Object Monitors #385) (at peak)
+
 ----
 
-3. Analyze the output. Look specifically at:
+. Analyze the output. Look specifically at:
 * **Internal:** Memory used by the JVM internal structures.
 * **Symbol:** Memory used for string interning.
 * **Thread:** Memory consumed by stack spaces.
 
-=== Step 2: Simulate Constraint Pressure
+=== Step 2: Simulate Constraint Pressure (FIXME as per lab)
 To ensure your configuration is resilient, verify that your application does not exceed the container limit.
 
 1. View the current cgroup memory limit for your container: