Learn › RHCSA (EX200) › Operate Running Systems

tuned Profiles

tuned-adm - a hands-on Linux lab on a real virtual machine.

Tune a RHEL 10 machine by naming its kind, not turning knobs by hand. Read the running profile with tuned-adm active, see the menu with tuned-adm list, ask what fits with tuned-adm recommend, switch with sudo tuned-adm profile NAME, and keep the daemon on with sudo systemctl enable --now tuned. Serves EX200 operating-systems task 21: apply the profile the machine recommends and enable tuned at boot. Graders assert against the node own recommend output, never a hardcoded name.

A RHEL machine has dozens of small performance knobs. How aggressively the kernel writes dirty pages to disk. How the CPU scales its frequency. How the network stack buffers. Set them for a laptop and a database server chokes. Set them for a database and a laptop drains its battery in an afternoon.

You could learn every one of those knobs and turn them by hand. Or you could name the KIND of machine this is, once, and let the system set them all for you. RHEL ships a daemon that does exactly that. Picking the right setting for it is EX200 operating-systems task 21: apply the tuning profile the system recommends, and make sure the daemon is on at boot. By the end of this lesson you will read the active profile, ask the machine what it recommends, and switch to it.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs shown are from a real RHEL 10 machine (AlmaLinux 10.2) running as a virtual guest. On a different machine the recommended profile and the list of profiles will differ. That is exactly why the exam grades against what YOUR machine recommends, not a name you memorized. The commands are identical everywhere, and those are the lesson.

tuned is a background service, a daemon, whose job is to apply a bundle of performance settings all at once. That bundle is called a profile. Instead of editing a dozen kernel and disk and network values by hand, you hand tuned the name of a profile and it applies every value in that bundle for you.

You never talk to the daemon directly. You talk to its admin tool, tuned-adm. The daemon is tuned (the thing running in the background); the tool is tuned-adm (the thing you type). Keep those two names straight and the rest of this lesson is four short subcommands.

tuned was built by Red Hat to solve a real support problem: engineers kept hand-tuning the same handful of kernel knobs for the same handful of workloads, and getting one wrong. Bundling those knobs into named profiles turned a page of sysctl edits into a single choice. Because it is Red Hat's own tool, it is exactly what the RHCSA exam expects you to reach for.

A profile is just a named collection of settings. balanced is the general-purpose default. powersave trades performance for battery life. virtual-guest is tuned for a machine running inside a hypervisor, which is what your exam machine is. You do not memorize what each profile changes; you learn how to see the active one, ask which one fits, and switch.

Start with the simplest question: which profile is running right now? The subcommand is tuned-adm active, and it prints one line naming the profile currently in force. Before you run it, know what you expect: your exam machine is a virtual guest, so a sensible default here is virtual-guest.

Ask the machine which profile is active:

tuned-adm active

prompt: student@servera:~$ answer: tuned-adm active output: Current active profile: virtual-guest hint: The subcommand for the running profile is active: tuned-adm active

Current active profile: virtual-guest. That one line is the whole answer: the daemon is running the virtual-guest profile, which makes sense because this machine is a virtual guest. This is the first thing to check before and after any change, because it is the only proof that a profile actually took hold.

Your machine may print a different name after the colon. A bare-metal laptop might read balanced, a fresh install might read something else. The FORMAT is fixed (Current active profile: NAME); the NAME follows your machine. Read the name, do not assume it.

Before you switch, you want the menu. tuned-adm list prints every profile installed on the machine, each with a one-line description of what it optimizes for. This is how you learn the exact spelling of a profile name, which matters because tuned-adm rejects a name it does not recognize.

List the available profiles:

tuned-adm list

prompt: student@servera:~$ answer: tuned-adm list output:

A dash, the profile name, then a short description of what it tunes for. balanced is the general default, powersave cuts power draw, and the network line is for high-throughput links. The full output on a real machine is longer than these four lines; the point is that this is where you confirm a name's exact spelling before you type it into a switch.

The set of profiles on your machine may be longer or shorter than what you see here, because installed packages add profiles. Never memorize this list. Run tuned-adm list on the machine in front of you and read the names it actually offers.

Here is the subcommand the exam is really testing. tuned-adm recommend inspects THIS machine, its hardware and how it is running, and prints the single profile name it believes fits best. On a machine running inside a hypervisor, it detects the virtualization and recommends virtual-guest.

This is the honest way to answer a task worded like set the recommended profile: you do not guess a name, you ask.

tuned-adm recommend

prompt: student@servera:~$ answer: tuned-adm recommend output: virtual-guest hint: The subcommand that asks the machine what fits is recommend: tuned-adm recommend

virtual-guest, and nothing else. Unlike active, recommend prints the bare profile name with no label. It is meant to be read by a script or piped straight into the next command. This machine is a KVM guest, so tuned looked at the virtualization it detected and named virtual-guest. On different hardware it would name a different profile. That is the point: recommend reflects the machine, not a fixed answer.

This is the trap graders set. recommend returns the profile for the machine it runs on, so the correct answer on a bare-metal box is NOT virtual-guest. When a task says apply the recommended profile, run tuned-adm recommend on that machine and use whatever name it prints. Never hardcode virtual-guest, or any name, from memory.

Switching takes tuned-adm profile NAME, where NAME is a profile from the list. It applies every setting in that bundle immediately, and the choice persists across reboots because tuned records it. Because it changes system-wide settings, it needs root, so you run it with sudo.

The disciplined pattern is two commands: switch, then read active to confirm. Switch to the profile tuned recommended for this machine:

sudo tuned-adm profile virtual-guest

prompt: student@servera:~$ answer: sudo tuned-adm profile virtual-guest output: hint: The subcommand to switch is profile, followed by the name, run with sudo: sudo tuned-adm profile virtual-guest

profile prints nothing on success, which is normal for a command that just did its job. That silence is why the pattern is always two steps: you switch, then you run tuned-adm active again to see Current active profile: virtual-guest and PROVE the change landed. On the exam, an unverified change is a change you are guessing about. Switch, then confirm, every time.

Here you switched to virtual-guest because that is what recommend returned on this virtual machine. On a machine that recommends a different profile, you would type that name instead. The command shape, sudo tuned-adm profile NAME, is fixed; the NAME comes from recommend.

There is a second half to task 21 that is easy to forget. A profile only stays applied if the tuned daemon is running, and it only survives a reboot if the daemon is enabled, meaning set to start automatically at boot. Setting a profile while the daemon is off, or leaving it disabled, is the classic way to lose points on a task you thought you finished.

One command both starts the daemon now and enables it for every future boot. enable turns on the boot-time start; --now also starts it this instant. It needs root:

sudo systemctl enable --now tuned

prompt: student@servera:~$ answer: sudo systemctl enable --now tuned output: hint: enable sets it to start at boot, --now also starts it immediately: sudo systemctl enable --now tuned

enable --now is the two-birds command: enable writes the boot-time link so tuned starts on every reboot, and --now starts it this second so your profile applies without waiting. Confirm it with systemctl is-enabled tuned (expects enabled) and systemctl is-active tuned (expects active). A profile plus a disabled daemon is a task half done; the daemon being enabled is what makes the setting survive the reboot the grader may perform.

Scaffolding off. No command is shown this time. You have every piece you need.

A task tells you to apply the tuning profile the system recommends. You have already seen that this machine recommends virtual-guest. Do not guess and do not hardcode: switch to that recommended profile with the admin tool, as root. Think about which subcommand switches a profile, and that changing system settings needs sudo.

prompt: student@servera:~$ answer: sudo tuned-adm profile virtual-guest output: hint: You confirmed recommend returns virtual-guest here. The switch subcommand is profile, and it needs sudo: sudo tuned-adm profile <the recommended name>.

sudo tuned-adm profile virtual-guest, and the command returns silently because it succeeded. You did the honest version of the task. You knew recommend had returned virtual-guest on this machine, so you applied that exact name rather than a memorized guess. On a machine that recommended something else, you would run tuned-adm recommend first and feed its answer into tuned-adm profile. Follow it with tuned-adm active to see Current active profile: virtual-guest, and with the daemon enabled at boot, task 21 is genuinely done.

You earned this cheat sheet. Every row is a command you just ran:

The one habit to burn in for the exam: for apply the recommended profile, run tuned-adm recommend, feed its exact output into tuned-adm profile, verify with tuned-adm active, and make sure the daemon is enabled at boot.

tuned is the daemon, tuned-adm is the tool you type. If tuned-adm ever errors with a message about not being able to talk to the daemon over DBus, the service is not running. Start and enable it with sudo systemctl enable --now tuned, then retry.

The practice terminal has shown you the whole of tuned: tuned-adm active to read the running profile, tuned-adm list to see the menu, tuned-adm recommend to ask the machine what fits, sudo tuned-adm profile NAME to switch, and sudo systemctl enable --now tuned to keep the daemon on across boots. Every one of those you typed yourself.

The operating-systems module mission is where you run these against a real RHEL 10 machine. A full VM boots for you, its own live machine with its own recommendation to read. The mission hands you objectives that use exactly what you practiced here: ask what the machine recommends, apply that profile, and confirm the daemon is enabled at boot. One difference from this lesson: the mission shows no commands. You read the objective, recall tuned-adm recommend and tuned-adm profile, and type them. That recall is what makes it stick on exam day.

Finish the other operating-systems lessons, then go tune a real machine to what it asks for.

Practice tuned Profiles in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.