KooLabs Lab Notes: Creating Two ECS Instances, Three Lessons

Today I worked through the paired lab of the Huawei Cloud Computing Service Practice micro-certification on KooLabs. The plan was straightforward on paper: create a Linux ECS and a Windows ECS, change the Linux specification, build a private image, configure an Auto Scaling group and policy, and finish the Docker steps. I got both servers created and running, shut the Linux server down for its spec change, and then the 90-minute lab session expired before the remaining steps. This post is an honest review of what actually happened, and the three practical lessons I took away.

Lesson 1: Availability zone capacity is a runtime constraint, not a given

The manual specifies Availability Zone 1. The Linux server (s6.small.1, CentOS 7.6 64-bit, 40 GB High IO disk) was created in AZ1 without trouble. But when I searched for s6.medium.2 for the Windows server in AZ1, the console returned no available resources and suggested switching AZ or region. Switching to AZ2 worked immediately, and the Windows server (s6.medium.2, Windows Server 2019 Standard 64-bit Simplified Chinese) was created there.

The lesson: do not treat the manual’s AZ as guaranteed. Check the filtered specification list in each AZ, and be ready to move AZs when a flavor is out of stock. Both servers still landed in the same preset VPC (192.168.0.0/16) and preset security group, with static BGP EIPs at 1 Mbit/s, so the network design stayed intact despite the AZ change.

Lesson 2: A spec change is a state machine, not a single button

Changing a specification requires the instance to be powered off first. The correct sequence is: shut down with a normal shutdown (not forced) from the More menu, wait until the status becomes powered off, then choose Change Spec, select the target flavor (s6.medium.4 in this lab), submit, and power on again before verifying with commands such as checking processor count and memory inside the system.

I completed the shutdown of ecs-linux successfully, but the session expired before the spec change itself. The practical point is sequencing: do the shutdown and spec change early in the session, not at the end, because every later step (SSH verification, image creation, Auto Scaling, Docker) depends on the resized instance being back up.

Lesson 3: The remote lab desktop has its own input rules

Three small behaviors cost me the most time:

First, clicks in the remote desktop often need two attempts: the first click only focuses a control, the second actually selects it. This applied to AZ buttons, specification radio buttons, and the agreement checkbox.

Second, host security did not behave as the manual describes. The manual says to leave it unchecked, but the current console shows an enable-host-security checkbox plus Basic, Enterprise, and Flagship cards. My attempts to uncheck it toggled inconsistently, and both final configurations showed the free Basic protection enabled. No paid edition was selected, but the deviation from the manual is real and worth recording rather than hiding.

Third, password entry in the remote desktop needs Shift for uppercase letters and special characters. Typing the password without Shift produced only lowercase letters and digits and failed the complexity check; with Shift held for the uppercase letter and the @ sign, all complexity checks turned green.

A related display trap: narrow input fields truncate server names, so a name can look wrong when it is actually right. Always verify the full name in the configuration overview before submitting.

Time management: the lesson that ended the session

A 90-minute lab session cannot be extended for free once the daily free quota is used, and extending costs lab points. Long steps such as private image creation (about six minutes of waiting alone) must start early, with a buffer at the end for verification. My session ended during a desktop reconnection, and the platform began cleaning up resources. The lab is therefore honestly incomplete, and the micro-certification exam stays untaken until the lab is fully done and reviewed.

Checklist for the next attempt

Create both servers first, then do the shutdown, spec change, and SSH verification second, the private image third, and Auto Scaling and Docker last, keeping at least fifteen minutes of buffer. Record every deviation (AZ change, host security state) as it happens, because the review at the end is only useful if the notes match reality.