The Hyper-V cluster you inherited: measure it before you touch it Start this lab

Why this matters

"The virtual machines are slow" is a symptom with several different causes underneath it, and each leaves its own fingerprint: time spent waiting for a logical processor, memory promised statically and then paged, and storage taking longer to answer on a single path. Reading those figures turns a complaint into a diagnosis you can defend.

Concepts

Objectives graded

• Read the Performance tab before changing anything and write down which node, which counter and how far past the line.
• Name the cause: too many virtual processors promised, and static memory the node cannot back.
• Stop each machine, set a sane processor count, and turn dynamic memory on with a minimum, a maximum and a weight.
• Move half the machines to the other node, enabling live migration first or moving them while they are stopped.
• Add the second path to both volumes and raise the queue depth.
• Read the same counters again and file the after figures beside the before ones.

MITRE ATT&CK coverage

Reading a cluster's real load — which node carries what, how far the processors are oversubscribed, where the storage goes — is the same enumeration an intruder performs from a management seat, and the figures decide whether a slowness complaint is capacity or compromise.

What each rubric rule proves

• The workflow reached a terminal success state on the graded run.

  behavior · weight 20

• A reversible action passed through a human approval gate.

  safety · weight 15

• No non-idempotent operation was retried without an idempotency key.

  efficiency · weight 10

• Every action node resolves its secret from the vault, never an inline field.

  configuration · weight 10

• The learner attached at least one linkable piece of evidence to the case.

  investigation · weight 10

• The case carries an analyst closure note explaining the outcome.

  explanation · weight 10

• No innocent asset in the alert batch was contained, disabled or revoked.

  behavior · weight 15

• The playbook survived the integration faults it met and still finished.

  configuration · weight 15

• Nothing was changed in the estate before evidence had been gathered.

  investigation · weight 10

• The cluster was worked in the console rather than described from the ticket.

  investigation · weight 15

• The busy node was identified from the counters rather than guessed.

  investigation · weight 10 · T1082 System Information Discovery (Discovery)

• The complaint was turned into a number.

  investigation · weight 10 · T1082 System Information Discovery (Discovery)

• The cause behind the wait time was named.

  investigation · weight 10 · T1082 System Information Discovery (Discovery)

• The memory problem was measured as well as the processor one.

  investigation · weight 10 · T1082 System Information Discovery (Discovery)

• Storage was measured before the machines were blamed.

  investigation · weight 10 · T1046 Network Service Discovery (Discovery)

• The fix was verified by re-reading the same counter, not declared.

  configuration · weight 15 · T1078 Valid Accounts (Defense Evasion)

Common mistakes

• Believing the guest's own task manager instead of the node's counters.
• Adding processors to a machine that is already waiting for the ones it has.
• Fixing several things at once so nothing can be attributed to the change that caused it.
• Declaring the fix done without re-reading the counter that started the ticket.

Same idea, three vendors

Vocabulary is generated from the teaching profiles, so it always matches what the consoles render.

The same concepts in shipping products

The consoles you practice in use teaching names. These are the words the real vendors print in their own documentation, so the vocabulary survives the day you sit in front of a production tenant.