- Generate Database Activity in the Test VM
- Check for Overcommitment of VM Memory
- Configure esxtop to Report VM Memory Statistics
- Observe Memory Statistics
- Start a Memory Test on ResourceHog01 and ResourceHog02
- Record Memory Statistics
1: Generate Database Activity in the Test VM
You start the test program to generate database activity.
If necessary, log in to the Linux01 VM as user root and the standard lab password.
In the Linux01 console, start the test script
starttest2 from the folder
/root in Linux01 VM.
This test program performs continuous database operations to a medium-size database. The number of threads is set to 2. The script must run uninterrupted
2: Check for Overcommitment of VM Memory
You use resource allocation reports to determine whether memory is overcommitted for a VM.
Using the vSphere Client, select Menu > Hosts and Clusters.
In the left pane, select the Linux01 VM.
In the right pane, click the Monitor tab and click Utilization on the left.
Find theVirtual Machine Memory panel.
Record the value for VM Consumed. __________
Find the Guest Memory panel in the lower-left corner of the right pane.
Record the value for Active Guest Memory. __________
Q1. Is the consumed host memory greater than the active guest memory?
A1. Answers vary depending on the current workload.
If the consumed host memory is greater than the active guest memory, memory is not overcommitted. If the consumed host memory is less than active guest memory, then overcommitment is occurring and might cause degraded performance
3: Configure esxtop to Report VM Memory Statistics
esxtop and configure it for memory statistics.
Open the MTPuTTY window to monitor statistics for the VM on the host.
- open SSH Session to access the host that the linux01 vm reside in k SA-ESXi-04.
- logged in to sa-esxi-04.vclass.local as user root.
esxtop, enter m to view the memory statistics screen.
Set a 10-second update delay.
- Enter s to display the delay prompt.
- At the delay prompt, enter 10.
To display only VM statistics, enter Shift+v .
Remove all statistics columns from the output table, except D, H, J, and K.
Removing counters that are not monitored during the test can make isolation of the desired counters easier.
- Enter f to access the field order screen.
- If an asterisk appears to the left of the field name, for fields other than D, H, J, and K, press the corresponding letter to remove the asterisk.
- If an asterisk does not appear to the left of the field name, for the D, H, J, and K fields, press the corresponding letter to add an asterisk.
- Press Enter to return to the memory statistics output.
4: Observe Memory Statistics
esxtop counters to determine memory conditions.
- In the
esxtopoutput, view the Linux01 VM statistics.
- To change the view to the memory view, enter m
- Verify that the MCTLSZ, MCTLTGT, SWCUR, SWTGT, SWR/s, and SWW/s values are at or near zero.
- If you cannot see all values listed in step b, close the left pane in the MTPuTTY application – collapsing the Servers list in MTPuTTY.
.Record the operations per minute (OPM) value in the test script.
The counter value is reported with each iteration that the test script performs.
Use the counter reported in the last iteration.Change to the Linux01 console tab.
Record the OPM value reported by the test script.
The counter value is reported with each iteration that the test script performs. Use the counter reported in the last iteration.
5: Start a Memory Test on ResourceHog01 and ResourceHog02
You start a memory test on the ResourceHog01 and ResourceHog02 VMs.
Power on and monitor VM ResourceHog01.
You must enter the console within 30 seconds.
- Return to the vSphere Client tab.
- In the left pane, select ResourceHog01.
- If it is not there already, migrate ResourceHog01 VM to host sa-esxi-04.vclass.local.NOTE: Keep all VMs for this exercise on sa-esxi-04.vclass.local.
- Right-click ResourceHog01 and select Power > Power On.
- Click the Summary tab of ResourceHog01 and click the Launch Web Console link.
- Click anywhere in the console window.
- At the BIOS screen, press Enter.
- At the
boot:prompt, press Enter to load the Ultimate Boot CD menu.If you see a
Booting...prompt, you did not enter the console within 30 seconds. You must restart the process from substep a and enter the console to the VM within 30 seconds. Repeat this process until the Ultimate Boot CD menu appears.
- Use the arrow keys and the Enter/Return key to select Mainboard Tools > Memory Tests > Memtest86+ V1.70.
- The exact keystroke sequence is Enter, down arrow, down arrow, Enter, down arrow, down arrow, Enter.
- After the memory test utility is running, press Ctrl+Alt to release the pointer focus.
Repeat step 1 for the ResourceHog02 VM
6: Record Memory Statistics
You record and evaluate memory statistics with a significant load consuming ESXi host memory.
.Return to the SSH session on esxi-04.vclass.local window.
After at least one minute of statistics collection, record the values for the ResourceHog02, ResourceHog01, and Linux01 VMs in the class configuration handout.
Q1. For Linux01, does the value of MCTLSZ converge with the value of MCTLTGT?
A1. Yes, the values should converge over time.
Q2. For Linux01, does the value of SWCUR converge with the value of SWTGT?
A2. Depending on many factors, the values might converge over time.
Monitor the statistics output until the host reaches a steady state where the counters in each set are close in value to each other.
If the counters in each set are close in value to each other, the host has reached a steady state.
To determine which VMs do not have the balloon driver installed, examine the MCTL? value for each VM.
The MCTL? field indicates the presence of the balloon driver. If the MCTL? value is Y, then that VM has a balloon driver installed. Otherwise, the VM lacks a balloon driver.
Q3. Which VMs do not have the balloon driver installed?
A3. ResourceHog02 and ResourceHog01.
To determine whether the VMs are swapping, examine the values for SWR/s and SWW/s for each VM.
Q4. Which VMs are swapping?
A4. Although all three VMs might be swapping, the levels of swapping on ResourceHog01 and ResourceHog02 will be much larger than the level of swapping on Linux01.
Determine which VMs have experienced degraded performance as a result of swapping.
Enter lowercase c to change to the CPU screen.
Press Shift+V to display only VM statistics.
Examine the %SWPWT value for each VM identified as actively swapping.%SWPWT is the percentage of time the world is waiting for the ESX VMkernel swapping memory. As %SWPWT exceeds 5 percent, the performance of the VM degrades significantly. If you do not see the %SWPWT field, expand your console window.
Q5. What are the %SWPWT values for each of the VMs?
A5. ResourceHog01 and ResourceHog02 should experience high %SWPWT values because their memory is being swapped out and they must wait whenever those pages are accessed.
Linux01 should experience low %SWPWT values, possibly zero.
Enter m to return to the
esxtop memory screen.The memory state can be found at the end of the third row from the top of the
Q6. What is the memory state: high, clear, soft, hard, or low?
A6. Answers vary.
Record the OPM value in the test script.
Change to the Linux01 console tab.
Record the OPM value reported by the test script. __________
Compare this OPM value with the value that you recorded in task 4 (step 2, substep b).
Q7. Has the performance of the test script degraded?
A7. Answers vary.