GrooveYOU

root@ubuntu:/etc/apt#

root@ubuntu:/etc/apt# cat sources.list

#

deb [trusted=yes] file:/cdrom/dists/stable/main/binary-ppc64el ./

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html/release_notes/sect-subscriptions

http://www.cbs1.com.my/WebLITE/Applications/news/uploaded/docs/Linux%20on%20Power%20Update%20and%20Strategy%20V1.0.pdf

https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/How_Install_RHVM_Red_Hat_oVirt_Virtualization_Manager_on_Power_System_VM_or_LPAR?lang=en

https://www.ibm.com/developerworks/library/l-rhv-environment-trs/

https://www.ibm.com/developerworks/linux/library/l-openpower-firmware-ipmi/index.html

This article describes the capabilities and features of OpenPOWER hardware and reliability, availability, and serviceability (RAS) components. This article also describes different OpenPOWER firmware features that use Intelligent Platform Management Interface (IPMI).

Firmware plays a critical role in the initialization and booting processes in servers. IBM Power Systems servers are developed based on the IBM® POWER® processor architecture and can be categorized into the following types:

• IBM PowerVM®) based systems where the IBM POWER Hypervisor™ firmware is the hypervisor
• IBM Power® non-virtualization based systems that are running under Open Power Abstraction Layer (OPAL) firmware

Based on the management controller, there are two types of Power non-virtualization systems:

• Flexible service processor (FSP) based systems, where FSP is an IBM PowerPC® fourth-generation processor that manages the system.
• Baseboard management controller (BMC) or OpenPOWER based system, where BMC is an ASPEED Technology (AST) 2400/2500 system on chip (SOC) that manages the system.

This article focuses on OpenPOWER BMC-based Power non-virtualization systems that are running in the OPAL mode. The firmware for the OpenPOWER systems is a combination of the BMC firmware component and the host firmware component.

• BMC firmware stack is used to manage the server mostly for out-of-band or remote system operations such as power control operations, firmware flashing, field-replaceable unit (FRU) inventory information, local area network (LAN) configuration, and sensor readings.
• OpenPOWER host firmware is a system initialization and boot time firmware for Power Systems servers. It contains the following subcomponents:
  • Self-boot engine
  • Hostboot (system initialization firmware for POWER)
  • Skiboot (OPAL boot and runtime firmware for POWER)
  • Skiroot kernel
  • Petitboot (kexec based bootloader)
  • On Chip Controller (OCC) firmware
  • Op-build (buildroot overlay for OpenPOWER)

The host firmware is the main boot firmware that stores in the processor NOR (PNOR) flash chip, and is used to initialize the host processor and make the system boot until runtime state after which the boot process is taken over by the Linux® operating system. OpenPOWER systems firmware has the following boot sequence after you power on the system:

1. The hostboot firmware initializes the processor and memory subsystem.
2. The Skiboot firmware (OPAL) initializes Peripheral Component Interconnect (PCI) and the devices that are outside the chip subsystem.
3. The hostboot and Skiboot firmware generates a flatten-device-tree. 
   Device tree is a binary tree structure, where all the devices are nodes, and different features of the devices are property value pairs that are exposed to the Linux kernel to configure different device drivers.
4. After the host firmware (OPAL) completes the booting and generation of the device tree, Skiroot is loaded. Skiroot is a combination of the Linux kernel and boot loader (petitboot). Petitboot is a kexec-based boot loader that can detect and load the boot devices. Skiboot (OPAL) firmware also contains an OPAL application programming interface (API) which are runtime hardware abstraction calls used by the Linux operating system to interact with low-level hardware.

The important OpenPOWER firmware IPMI features that are used to monitor, control, and debug the OpenPOWER system are described here.

• System power control
• Sensors
• Thermal and Power management
• System event log (SEL)
• Field-replaceable unit (FRU) data
• Boot progress codes
• Serial-over LAN (SOL) console
• System time and boot management
• Firmware update procedure
• Virtual Universal Asynchronous Receiver/Transmitter (VUART) to video graphics array (VGA) rendering
• IPMI lock and unlock feature
• IPMI PNOR reprovision feature

For all the IPMI features described in this article, invoke the following out-of-band ipmitool command as the base string when you run the commands for all operations:

System power control

All system power control operations are controlled by the BMC. The different power control operations are power status, power on, power off, power cycle, and power reset.

• Power status: To know the power status of the OpenPOWER systems, run the following command:
  $IPMI_CMD chassis power status
• Power on: The system can be powered on by using one of the following methods:
  • Run the following command to power on the system.
    $IPMI_CMD chassis power on
  • Push the power on button.
  • Wake on local area network (LAN).

  To track the power status during the boot process of an OpenPOWER system, the host status sensor provides a system Advanced Configuration and Power Interface (ACPI) power state. This sensor is set to the following states during booting.

  • Soft off: Before power is on (that is, when the system is in off state)
  • Legacy on: When the hostboot firmware boots (that is, when hostboot firmware is able to communicate with the BMC)
  • Working state: When OPAL starts the Linux kernel.

  More details of sensors are provided in the Sensors section.

• Power off: The system can be powered off by using one of the following methods:
  • Graceful shutdown: Push the power button for less than 3 seconds or run the IPMI power soft command. BMC sends a System Management Software (SMS) attention (graceful operating system shutdown request) to the host operating system. Wait for the host status sensor to be set to the soft off state before BMC trigger hardware power off.
    $IPMI_CMD chassis power soft

    Before BMC issues hardware power off, it must set the host status sensor to the soft off state.

  • Forced power off: Push the power button for more than 3 seconds or run the following IPMI power off command:
    $IPMI_CMD chassis power off

    On forced power off, the system immediately goes to the standby state irrespective of the operating system status, and BMC sets the host status sensor to the softoff state.

• Power reset: This operation is a hardware power off followed by the IPMI power on sequence.
  $IPMI_CMD chassis power reset
• Power cycle: When the system is in the working state, the power cycle operation reboots the system. It is a graceful operating system shutdown followed by an IPMI power reset.
  $IPMI_CMD chassis power cycle
• Power policy: Based on the system power policy, BMC must restore to a particular power state when power supply is lost. What this means is that a server can be powered on automatically according to this power policy setting. To list the available supported power policies, run the following command:
  $IPMI_CMD chassis power policy list

  To set to a particular power policy, run the following command:

  $IPMI_CMD chassis power policy <always-on/always-off/previous>

Sensors

Sensors are software or hardware physical entities that are used to monitor the health of different system hardware devices or software components. There are two types of sensors.

• A virtual sensor that does not exist physically. However, it represents the status of some software or hardware operation such as processor/Dual Inline Memory Module (DIMM) functioning or host status.
  $IPMI_CMD sensor list

  or

  $IPMI_CMD sdr elist

  The following example shows the virtual sensor Host Status usage.

  During system run-time, the sensor status shows as S0/G0: WORKING, and when the system is in standby state or powered off state, the sensor status shows as S5/G2: SOFT-OFF.

  HOST STATUS      | 04H | OK  | 35.0 | S0/G0: WORKING HOST STATUS      | 04H | OK  | 35.0 | S5/G2: SOFT-OFF

• A physical sensor on the motherboard that reads the status of hardware devices such as processor/DIMM temperatures and frequencies.
  
  

  CPU Temp         | 64h | ok  |  3.0 | 42 degrees C Membuf Temp 0    | 65h | ok  |  7.0 | 42 degrees C DIMM Temp 0      | 69h | ok  | 32.0 | 28 degrees C DIMM Temp 1      | 6Ah | ns  | 32.1 | No Reading

System thermal or power management

This feature is mainly used to monitor and control system power and thermal levels. BMC keeps monitoring certain temperatures (processor, DIMM, and so on) with the help of the OCC and sets the fan speed based on the current readings. You can use the power reading and capping functions to read and maintain the power level of the system. You can run the following commands to deal with platform power limits:

• Run the following command to find the platform power readings:
  
  

  $IPMI_CMD dcmi power reading Instantaneous power reading:                   237 Watts Minimum during sampling period:                233 Watts Maximum during sampling period:                240 Watts Average power reading over sample period:      236 Watts IPMI timestamp:                                Mon Nov  7 13:20:22 2016 Sampling period:                               00000010 Seconds. Power reading state is:                        activated

• Run the following command to find the active power limit. The following output shows that the current power limit is 1000 watts.
  
  

  $IPMI_CMD dcmi power get_limit Current Limit State: Power Limit Active Exception actions:   Log Event to SEL Power Limit:         1000 Watts Correction time:     1000 milliseconds Sampling period:     10 seconds

• Run the following command to set the active power limit:
  
  

  $IPMI_CMD dcmi power set_limit limit 1050 Current Limit State: Power Limit Active Exception actions:   Log Event to SEL Power Limit:         1050 Watts Correction time:     1000 milliseconds Sampling period:     10 seconds

• Run the following command to activate the power limit:
  
  

  $IPMI_CMD  dcmi power activate Power limit successfully activated

• Run the following command to deactivate the power limit:
  
  

  $IPMI_CMD dcmi power deactivate Power limit successfully deactivated

System event log

The BMC is the master of system event log repository and maintains all firmware system event logs. All low-level events in the system firmware happen during system boot and runtime. Also, all the critical failures in the hardware and firmware are logged in the BMC System event log repository. 64 KB of system event log and extended system event log data can be stored.

Boot progress

System boot progress can be tracked by seeing the SOL console where hostboot and OPAL emit their appropriate progress codes or by updating system firmware progress and operating system boot sensors to their respective boot states (that is, processor initialization, motherboard initialization, and PCI initialization).

Hostboot progress codes:

OPAL or Skiboot progress codes:

System inventory or vital product data (VPD)

System VPD is stored on the BMC in the IPMI FRU inventory. The BMC collects the FRU data of the hardware that is directly connected to the BMC [for example, backplane, power supply, and voltage regulator module (VRM)]. Hostboot updates the processor, centaur, and DIMM VPD. OPAL updates Peripheral Component Interconnect Express (PCIe) VPD. By running the following command, you can collect the complete system VPD including data that contains manufacturing information, product name, serial, and part numbers.
$IPMI_CMD fru print

The example FRU description for the processor is as follows:

SOL console

SOL is a mechanism that redirects the input and output of a serial port of the remote system over LAN IP. BMC provides the IPMI SOL console with the help of Ethernet and serial ports that are attached to it. You can see the boot progress and failure messages on the console screen. SOL console is the main interface between the overall system and the user. By running the following command, you can connect to the SOL console: 
$IPMI_CMD sol activate

Also, BMC has 32 KB of circular log buffer that is assigned for SOL console data, which you can get from the BMC busy box.

When the system is at a checkstop (for example, when the processor is not able to complete any instructions for some time or it is in an impossible state) the corresponding console log data is archived for further debugging and analysis.

System time management

System time is maintained in the Real-Time Clock (RTC), which is controlled by the BMC. When the BMC boots the system, it sets its own time by reading the current Inter-Integrated Circuit (I2C) RTC time. The host (hostboot or OPAL) or the user can read or write the RTC time by running the following IPMI commands. BMC sets or obtains the current RTC time.

Boot failure management

OpenPOWER systems have two sides of the PNOR firmware: Primary side and golden side. BMC always boots the system from the primary side of the PNOR firmware. If the primary side boot fails twice due to system checkstop, watchdog conditions (conditions where the watchdog timer detects malfunctions of the operating system or server and recovers from them), or any other reason, BMC boots the system from the golden side of the PNOR firmware. For this process, BMC uses a boot count sensor, which is initially set to two. During the start of every boot operation, BMC decrements this sensor value by one. When the system reaches to the user-accessible level (that is, petitboot or when Linux boots), OPAL resets this sensor value back to two. Whenever the value of the boot count reaches zero due to boot failure, BMC starts booting the system from the golden side of the PNOR firmware.

During any boot failures, run the following command to know the value of boot count:

The BIOS golden side sensor has two discrete values (0x0080, 0x0180). The value of this sensor determines the side of the PNOR firmware boot.

The following example shows that the value of this sensor is set to 0x0180, which means that the system boots from the golden side of the PNOR firmware:

The following example shows that the value of this sensor is set to 0x0080, which means that the system boots from the primary side of the PNOR firmware:

Out-of-band firmware update

Usually, systems have general availability firmware installed. If the firmware gets corrupted or you want to upgrade the firmware to install bug fixes, you can select the out-of-band firmware update method. System firmware is a combination of the host firmware component (PNOR) and the BMC firmware component. It is a Hardware Platform Management (.hpm) file. To update the firmware code (xxxx.hpm) by using the out-of-band method, you need to complete the following steps:

1. Power off the system by running the following command: 
   $IPMI_CMD chassis power off
2. Issue a cold reset to BMC by running the following command:
   $IPMI_CMD mc reset cold

   Then wait until the BMC starts.

3. Before you update the BMC network settings, back up the network settings by running the following command: 
   $IPMI_CMD raw 0x32 0xba 0x18 0x00
4. Update the BMC and PNOR levels by the using the HPM upgrade option.
   $IPMI_CMD hpm upgrade <xxxx.hpm file> -z 30000 force

   Wait until the firmware upgrade is successful.

5. Power on the system by running the following command: 
   $IPMI_CMD chassis power on

VUART-to-VGA rendering

Generally, most of the users want to see boot messages or any boot failures during system boot. To view early boot messages in a system boot, the VUART-to-VGA rendering feature is implemented in OpenPOWER systems. By using this feature, when you power the system on, you can see all the early boot messages in a local VGA console. The BMC renders the output of the host UART to the VGA display.

Figure 1. Sample remote VGA console output

Firmware settings

The boot loader (petitboot) has the following settings in the user interface:

• Network settings
• Turbo mode setting (enable/disable)
• Boot device selection
• Boot device order

All these features can also be controlled by the BMC. By using IPMI commands, you can enable or disable the turbo mode, select a boot device, and configure the host network.

The settings that are changed by using the IPMI commands take preference, and the settings that are changed at petitboot in nonvolatile random access memory (NVRAM) configuration are overridden. Also, system information provides complete firmware versions (BMC and PNOR versions, including the golden side version), and the BMC MAC address.

IPMI lock and unlock feature

When a system is deployed to a customer, unauthenticated in-band IPMI must not be able to access certain BMC configuration information and functions. The OpenPOWER original equipment manufacturer (OEM) IPMI Lock command can be run in an authenticated interface to lock certain IPMI commands. After BMC is in the IPMI lockdown mode, further unauthenticated in-band IPMI messages must satisfy the allowed commands, added in a list called white list that is matched by NetFn command specification. To revert the BMC to a fully permitted configuration, you can run the OEM IPMI Unlock command in an authenticated interface.

• Lock IPMI interface command: You can run this command to lock the IPMI interface for safer executions. Only a predefined set of commands are allowed in this mode of operations. This is similar to the safe mode operations. 
  
  

  $IPMI_CMD raw 0x32 0xf3 0x4c 0x4f 0x43 0x4b 0x00; echo $?   0 # ipmitool chassis status Error sending Chassis Status command: Insufficient privilege level   Get SEL time # ipmitool raw 0x0a 0x48; echo $?  00 ae c0 57 0

  From these examples, you can see that the Chassis Status command does not produce any output because the command is not listed in the white list. However, when you run the Get SEL Time command, output is displayed because the command is available in the white list. Commands that are listed in the white list can work when BMC is in the IPMI lockdown mode.

• Unlock IPMI Interface command: By unlocking the IPMI interface, you can run all the commands again. 
  
  

  $IPMI_CMD raw 0x32 0xF4 0x55 0x4e 0x4c 0x4f 0x43 0x4b 0x00

IPMI PNOR reprovision

You can revert the modified system settings and modified configurations back to default settings. The OEM IPMI PNOR Reprovision command in OpenPOWER resets the system to the default settings. BMC clears any persistent data that is set by the user. Currently, in PNOR, the erasable partitions are GARD (hardware guard entries), NVRAM (boot loader configuration), hostboot attribute overrides (turbo mode non-default value to default), and FIRDATA.

The following procedure shows the PNOR re-provision process for an NVRAM partition:

1. Update the NVRAM partition with test data by running the following command: 
   
   

   # nvram --print-config "common" Partition ---------------------   # nvram --update-config test-name=test-value # nvram --print-config "common" Partition --------------------- test-name=test-value

2. Run the PNOR reset/reprovision command. 
   
   

   # $IPMI_CMD raw 0x3A 0x1C; echo $?   [392812400894,5] IPMI: PNOR access requested

3. Run the following command to get the reprovisioning status. Wait for reprovision to complete. 00 indicates successful reprovision. 03 indicates that the re-provisioning is still in progress. 
   
   

   # $IPMI_CMD raw 0x3A 0x1D; echo $? 03 0 # $IPMI_CMD raw 0x3A 0x1D; echo $? 03 0 [163479624724,5] IPMI: PNOR access released                   # $IPMI_CMD raw 0x3A 0x1D; echo $? 00 0

4. Read NVRAM data after reboot by running the following command:
   
   

   # nvram --print-config "common" Partition --------------------- test-name=test-value # reboot                                   # nvram  --print-config

NVRAM data is erased after a PNOR reset or reprovision operation.

The IPMI raw command data might change between different OpenPOWER BMC vendors. However, the functionality remains the same. All the examples mentioned in this article mainly refer to American Megatrends BMC vendor-based OpenPOWER systems.

References

• OpenPOWER GitHub
• IPMI Specification, V2.0

To check host hardware using ipmitool as an alternative to dsa, as root run the following commands:

ipmitool sdr (status on envir, fans, cpu's, etc)

ipmitool fru (fru's for memory/system bd, etc) 

ipmitool sel elist (errors in event log)

ipmitool sel save sellistsave.txt

ipmitool sel elist

ipmitool sel list

ipmitool sel get <entry>

ipmitool sel save <filename>

http://fibrevillage.com/storage/279-hot-add-remove-rescan-of-scsi-devices-on-linux

# lsscsi
[0:0:0:0]    disk    ATA      SEAGATE ST31000N SU0E  /dev/sda 
[0:0:1:0]    disk    ATA      SEAGATE ST31000N SU0E  /dev/sdb 
...
[1:0:1:0]    disk    ATA      SEAGATE ST31000N SU0E  /dev/sdj 
[1:0:2:0]    disk    ATA      SEAGATE ST31000N SU0E  /dev/sdk 
[1:0:3:0]    disk    ATA      HITACHI H7210CA3 A3CB  /dev/sdl 
[1:0:4:0]    disk    ATA      HITACHI HUA7210S AC5A  /dev/sdm 
...
[5:0:7:0]    disk    ATA      SEAGATE ST31000N SU0D  /dev/sdav
[6:0:0:0]    mediumx IBM      TS3500           0104  /dev/sch0
[6:0:1:0]    tape    IBM      ULT3580-TD5      0104  /dev/st0 
[6:0:2:0]    tape    IBM      ULT3580-TD5      0104  /dev/st1 

# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: SEAGATE ST31000N Rev: SU0E
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: ATA      Model: SEAGATE ST31000N Rev: SU0E
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: ATA      Model: SEAGATE ST31000N Rev: SU0E
  Type:   Direct-Access                    ANSI  SCSI revision: 05
...

Host: scsi0 Channel: 00 Id: 01 Lun: 00 
is the same device of [0:0:0:0] in the output of lsscsi

          h == hostadapter id (first one being 0)
          c == SCSI channel on hostadapter (first one being 0)
          t == ID
          l == LUN (first one being 0)

# lsscsi
...
[1:0:0:7]    disk    IBM      1814      FAStT  1060  /dev/sdb 
[1:0:0:8]    disk    IBM      1814      FAStT  1060  /dev/sdc 
[1:0:0:10]   disk    IBM      1814      FAStT  1060  /dev/sde 
# echo "- - -" > /sys/class/scsi_host/host1/scan
# lsscsi
...
[1:0:0:7]    disk    IBM      1814      FAStT  1060  /dev/sdb 
[1:0:0:8]    disk    IBM      1814      FAStT  1060  /dev/sdc
[1:0:0:9]    disk    IBM      1814      FAStT  1060  /dev/sdd 
[1:0:0:10]   disk    IBM      1814      FAStT  1060  /dev/sde

echo "scsi add-single-device 1 0 0 9" > /proc/scsi/scsi

    echo 1 > /sys/class/scsi_device/h:c:t:l/device/delete
    or
    echo 1 > /sys/block/<dev>/device/delete
    where <dev> is like sda or sdb etc..

# echo 1 > /sys/block/sdau/device/delete 
# lsscsi | grep sdau
# 

echo "scsi remove-single-device h c t l" > /proc/scsi/scsi

    echo "- - -" > /sys/class/scsi_host/host<h>/scan

    echo "c t l" >  /sys/class/scsi_host/host<h>/scan

    echo "scsi add-single-device a b c d" > /proc/scsi/scsi

echo 1 > /sys/block/sdau/device/rescan 
or 
echo 1 > /sys/class/scsi_device/h:c:t:l/device/rescan

ipmitool sel clear

How to disable the Nouveau driver and install the Nvidia driver in RHEL 7

modprobe.blacklist=nouveau

# grub2-mkconfig -o /boot/grub2/grub.cfg
# reboot

# sh nvidia_filename.run

# mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname  -r)-nouveau.img 

# dracut /boot/initramfs-$(uname -r).img $(uname -r)

# reboot

How to uninstall proprietary "Nvidia" module and switch back to Red Hat shipped "Nouveau" module ?

# ./Nvidia-???.run --uninstall   

# rpm -ev --nodeps mesa-libGL 
# yum install -y mesa-libGL

# mv /etc/X11/xorg.conf /etc/X11/xorg.conf.save   

# vim /etc/modprobe.d/blacklist.conf
# blacklist nouveau

# reboot

# lsmod | grep "nouveau"

# modprobe -i nouveau

# xrandr | grep "max"

# xrandr

# xrandr | grep -i "connected" | grep -v "disconnected" | cut -d " " -f1      

# gtf 1920 1200 60.0

# xrandr --newmode "1920x1200_60.00"  193.16  1920 2048 2256 2592  1200 1201 1204 1242  -HSync +Vsync
# xrandr --addmode DVI-I-1 1920x1200_60.00 
# xrandr --output DVI-I-1 --mode 1920x1200_60.00 

# xrandr -s 1024x768
# xrandr -s 1920x1200

How to remove Nvidia drivers and switch back to nouveau for Red Hat Enterprise Linux 7?

rd.driver.blacklist=nouveau nouveau.modeset=0

#grub2-mkconfig -o /boot/grub2/grub.cfg

#./Nvidia-???.run --uninstall 

#mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname  -r)-preavous.img 
#dracut /boot/initramfs-$(uname -r).img $(uname -r)

#yum reinstall mesa-libGL

# mv /etc/X11/xorg.conf /etc/X11/xorg.conf.save

#reboot

https://www-304.ibm.com/support/customercare/sas/f/lopdiags/scaleOutLCdebugtool.html

https://www.certdepot.net/rhel7-get-started-cpu-governor/

RHEL7: How to get started with CPU governor.

Presentation of CPU Governor

The modern x86 processors provide two mechanisms to reduce power consumption when idle. Useful for a portable PC, it can also help for physical servers with limited workload.

However, don’t think about virtual machines, they are not concerned.

CPU Idle States

In the x86 architecture several CPU states, called C-states, have been defined, allowing systems to save power by decreasing CPU functionalities. These C-states are broadly similar across processors but the exacts details may vary.

• C0: The processor is working as usual.
• C1: The processor doesn’t execute any instruction but can start working again without any delay.
• C2: The processor is stopped but keeps the complete state of its registers and caches. A delay is necessary for the processor to start working again.
• C3: The processor is sleeping and doesn’t keep its caches. A longer delay than in C2 state is needed for the processor to start working again.

CPU Freq

CPU Freq or CPU speed scalling is a way to reduce power consumption by adjusting the clock speed of the processor.
Five CPU Freq governors are available in RHEL 7:

• performance: with this static governor you get the highest possible clock frequency but without any power saving benefit. It is best suited for heavy workload when the CPU is almost never idle.
• powersave: here your CPU gets the lowest possible clock frequency but at the cost of the lowest CPU performance. One serious drawback of this static governor happens when the system experiences unexpected high loads: in this case it can consume more power than other governors with higher clock frequencies. For this reason, it is not recommended to use it except when overheating is a problem.
• ondemand: this dynamic governor sets the maximum clock frequency when system load is high and minimum clock frequency when idle, but without intermediate state. This allows the system to adjust power consumption according to system load but at the expense of latency. In case switches between idle and heavy workloads happen too often, performance and power saving can suffer. Otherwise, it is one of the best options.
• userspace: with this governor, any process running as root can set the clock frequency.
• conservative: this dynamic governor is very similar to the ondemand governor except it adjusts clock frequency more gradually. Instead of choosing between maximum and minimum clock frequencies, it selects the clock frequency according to usage. This more granular approach provides significant power saving but at the expense of an ever greater latency than the ondemand governor.

Installation Procedure

Install the kernel-tools package to get access to the cpupower command:

# yum install -y kernel-tools

Note: The kernel-tools package and the cpupower command are not strictly needed to manipulate CPU governors. They only provide a convenient interface. All operations can be done using the /sys/devices/system/cpu/ path and the echo command.

Basic Operations

To get the list of the various idle states supported by the CPU number 0 (available idle states are given for various types of servers), type:

# cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
...
Available idle states: POLL C1E-ATM C2-ATM C4-ATM C6-ATM (Atom CPU N2800)
Available idle states: POLL C1-IVB C1E-IVB C3-IVB C6-IVB (Xeon CPU E3-1245 V2)
Available idle states: POLL C1-NHM C1E-NHM C3-NHM C6-NHM (Core i5 CPU M 430)
Available idle states: POLL C1-HSW C1E-HSW C3-HSW C6-HSW C7s-HSW C8-HSW C9-HSW C10-HSW (Celeron 2961Y)
...

To get the same information for all the CPUs on a server, type:

# cpupower -c all idle-info

Note: The -c option can be replaced with –cpu.

To get the list of the available governors for the CPU number 0, type:

# cpupower frequency-info -g
analyzing CPU 0:
  available cpufreq governors: conservative userspace powersave ondemand performance

Note: The -g option can be replaced with –governors.

To get all the details about the available CPU frequencies for the CPU number 0, type:

# cpupower frequency-info
analyzing CPU 0:
 driver: acpi-cpufreq
 CPUs which run at the same hardware frequency: 0
 CPUs which need to have their frequency coordinated by software: 0
 maximum transition latency: 10.0 us
 hardware limits: 1.20 GHz - 2.27 GHz
 available frequency steps: 2.27 GHz, 2.27 GHz, 2.13 GHz, 2.00 GHz, 1.87 GHz, 1.73 GHz, 1.60 GHz, 1.47 GHz, 1.33 GHz, 1.20 GHz
 available cpufreq governors: conservative userspace powersave ondemand performance
 current policy: frequency should be within 1.20 GHz and 2.27 GHz.
                 The governor "conservative" may decide which speed to use
                 within this range.
 current CPU frequency: 1.20 GHz (asserted by call to hardware)
 boost state support:
 Supported: yes
 Active: yes
 1900 MHz max turbo 2 active cores
 1900 MHz max turbo 1 active cores

Note1: Without the -c option, only the information about the CPU number 0 is displayed.
Note2: The governor conservative is the current configuration.

To change the governor to performance for all the CPUs, type:

# cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Note1: Without the -c option, all the CPUs are affected.
Note2: To only change for the CPUs number 0, 1 and 2, type: # cpupower -c 0-2 frequency-set -g performance
Note3: The -g option can be replaced with –governor.

# cpupower -c all frequency-info
...
 current policy: frequency should be within 1.20 GHz and 2.27 GHz.
                 The governor "performance" may decide which speed to use
                 within this range.
...

To specify the governor userspace for the CPU number 1 with a CPU frequency of 1.2GHz, type:

# cpupower -c 1 frequency-set -f 1.2
Setting cpu: 1
# cpupower -c 1 frequency-info -p
analyzing CPU 1:
  current policy: frequency should be within 1.20 GHz and 2.27 GHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
# cpupower -c 1 frequency-info -f
analyzing CPU 1:
  current CPU frequency: 1199000 (asserted by call to kernel)
# cpupower -c 1 frequency-info --hwlimits
analyzing CPU 1:
  hardware limits: 1.20 GHz - 2.27 GHz

Note: Only the governor userspace allows frequencies to be set.

Standard Operations

All commands seen previously don’t persist after reboot. The standard way to set up CPU governor in a persistent way is through the tuned daemon and the governor directive (alternatively, using rc.local only works if the tuned service is disabled).

If we look at the throughput-performance tuned profile (/usr/lib/tuned/throughput-performance/tuned.conf), we can see:

...
[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100
...

Note: The energy_perf_bias directive allows software on supported Intel processors to more actively contribute to determining the balance between optimum performance and saving power.

Therefore, if you want to define a specific configuration, create a new tuned profile with the tuned inheritance mechanism in the /etc/tuned directory (see the tuned tutorial):

[main]
include=throughput­-performance

[cpu]
...

Behaviour Analysis

To get a better understanding of the way your system behaves, install the powertop package:

# yum install -y powertop

Then, run the powertop command:

# powertop
PowerTOP 2.3      Overview   Idle stats   Frequency stats   Device stats   Tunables            

Summary: 528.4 wakeups/second,  0.0 GPU ops/seconds, 0.0 VFS ops/sec and 4.1% CPU use

                Usage       Events/s    Category       Description
              2.2 ms/s     177.5        Interrupt      PS/2 Touchpad / Keyboard / Mouse
            445.2 us/s      44.4        Timer          tick_sched_timer
              3.4 ms/s      39.2        Interrupt      [27] nvkm
            318.1 us/s      29.2        Timer          hrtimer_wakeup
            137.7 us/s      19.4        Process        [rcu_sched]
...

By pressing the tab key, you get access to different kinds of information (more details are available in the powertop manual):

• the Overview tab displays a general state of the system.
• the Idle stats tab presents the CPUs and GPUs currently loaded in the system in relationship with their C-states.
• the Frequency stats tab shows the P-states of a system in relationship with the idle state.
• the Device stats tab presents the list of devices in the system that consume the most power.
• the Tunables tab lists the devices that are present on the system. You can tune the system to be power friendly by toggling each item from bad to good.

Source: RHEL 7 Power Management Guide.

출처 : https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c01847647

기술 작업 지침

리눅스에서 LVM 구성하는 방법

LVM 은 Logical Volume Manager 의 약자로서, 저장장치들을 좀더 효율적이고 유연하게 관리할 수 있는 커널의 부분과 프로그램을 말합니다. 처음에는 IBM에서 개발되었는데, 그 후에 OSF(현재는 OpenGroup http://www.opengroup.org)에서 차용을 하여 OSF/1 operating system 에서 쓰였습니다. 지금은 HP-UX, Digital Unix operating system, AIX 등의 상용 유닉스에서 쓰고 있습니다. 리눅스 버전은 현재 HP-UX의 것을 모델로 하여 Sistina Software사 (http://www.sistina.com)에서 open source로 개발하고 있습니다. LVM 을 이해하려면 먼저 Software RAID (Redundant Array of Inexpensive Drives)를 언급해야 하는데, 이 둘은 비슷하면서도 큰 차이가 있습니다. 비슷한 점은 여러 물리적인 디스크들을 하나의 논리적인 디스크처럼 다룰 수 있게 함으로서 조합방법에 따라 고용량, 고속, 데이터의 무결성을 실현하는 점입니다. 하지만 분명하게 다른 점이 있는데. lvm은 raid보다 관리 및 확장이 비교적 쉬운 반면, raid에는 lvm에는 없는 disk mirroring (RAID level 1), Parity Stripe (RAID level 4,5) 등의 방식이 있어서 속도 또는 데이터의 무결성을 보장 받을 수 있습니다. 그러나 이런 차이점에도 불구하고 lvm가 주목을 받는 이유는 다음과 같습니다.

VG(Volume Group)은 LVM의 가장 기본적인 요소입니다. 쉽게 말하자면 가상 디스크라고 할 수 있는데, 하나 이상의 실제 물리적으로 존재하는 블록 디바이스가 모여서 VG를 이루게 됩니다.

그 물리적인 블록 디바이스를 PV(Physical Volume)라고 하는데, 거의 대부분의 장치를 PV로 쓸 수 있습니다. 하드디스크 및 그 파티션, 소프트웨어/하드웨어 RAID 장치, 심지어 Loopback 블록 디바이스(파일 시스템상의 파일을 블록 디바이스처럼 쓸 수 있게 해준다) 도 포함합니다.

PV와 대비되는 것이 LV(Logical Volume)입니다. 이것은 가상 파티션이라고도 할 수 있는데, VG를 적당히 나누어 할당한 것이 LV입니다. 사용자는 LV를 일반 디스크나 파티션처럼 쓰면 됩니다. 정리하자면, 하나 이상의 PV가 모여 VG를 이루고, VG를 가상적으로 나누어 할당하면 LV이 됩니다.

LVM관련 디스크가 변경되었을 경우

# vgscan –v –mknodes 를 실행하면

vgscan scans all SCSI, (E)IDE disks, multiple devices and a bunch of other disk devices in the system looking for LVM physical volumes and volume groups. Define a filter in lvm.conf(8) to restrict the scan to avoid a CD ROM, for example.

In LVM2, vgscans take place automatically; but you might still need to run one explicitly after changing hardware.

See lvm for common options

--mknodes

Also checks the LVM special files in /dev that are needed for active logical volumes and creates any missing ones and removes unused ones.