Expanding Storage Space in Linux: Step-by-Step Guide using LVM and fdisk

Expanding disk space in Linux virtual machines is a key aspect of server system management. In this article, we show how to effectively increase disk space using LVM and fdisk tools, based on real system data.

Preliminary Preparations

Before making changes to partitions and volumes, it is important to check the current state of the disks in the system. We will use the lsblk command to identify available disks and partitions.

Here is an example of the lsblk command output on a machine:

Creating Snapshots

Before making changes to disk configurations, it is advisable to create a snapshot of the LVM volumes to ensure data can be restored in case of unexpected issues.

Modifying Partitions

Next, we proceed to modify the partitions using fdisk. We remove the existing partition and then create a new one that utilizes the entire available space on disk sdb.

Saving Changes

After properly configuring the partitions, we use the w command in fdisk to save the changes and update the partition table.

Executing pvscan

After modifying the partitions, we execute the pvscan command so the system can update information about available physical volumes.

Configuring LVM

After saving changes to the partition table, we need to update the LVM configuration to include the new disk space. We use the lvextend command with automatic file system resizing.

Summary

Expanding disk space on a Linux virtual machine enhances performance and the availability of storage space. Thanks to the steps described, managing disk space in systems using LVM becomes simpler and more efficient.

Troubleshooting Proxmox clusters and restoring the LXC container

Managing Proxmox clusters can sometimes present technical difficulties, such as inconsistencies in cluster configuration or issues with restoring LXC containers. Finding and resolving these issues is crucial for maintaining the stability and performance of the virtualization environment. In this article, I present a detailed guide on how to diagnose and resolve an issue with an unreachable node and how to successfully restore an LXC container.

Before you begin any actions, make sure you have a current backup of the system.

Diagnosing the State of the Proxmox Cluster

and:

To understand the state of the cluster, execute the following command on the node-up-page-04 node:

Expected output:

Then check the detailed cluster information with the following command:

Expected output:

Removing the Container Configuration File and Cleaning Data

I discovered that the configuration file for container 107 still exists on the cluster’s file system at the path:

Output:

To remove this file and any remaining data associated with the detached node, execute:

Restoring the Container

After removing the configuration file, I restored the LXC container on the node-up-page-04 node using the command:

Output:

The restoration process was successful, and the container was ready for use. This case illustrates the importance of thorough diagnostics and configuration file management in Proxmox when working with clusters. Regular reviews of configurations are advisable to avoid inconsistencies and operational issues in the future.

Resolving performance_schema Issues in MySQL


During daily work with MySQL databases, specific challenges such as missing tables or errors related to the unrecognized database performance_schema can arise. These problems can significantly affect the performance and stability of database systems, and their diagnosis and resolution can often be complicated and time-consuming. To facilitate this task, I have created this guide, which is the result of my experiences and proven practices. I provide a comprehensive approach to identifying and fixing issues related to performance_schema. It’s quite simple to import the schema from a newly built database.

Of course, it’s best to perform a backup of the database before the entire operation.

Initial Diagnosis in MySQL

Start by identifying the problem in the MySQL shell:

Creating New Performance Schema in MySQL

Create a new performance schema from the MySQL command line:

Server Operations to Establish New MySQL Environment

Return to the system to configure a clean MySQL environment:

Then, start MySQL in safe mode to configure it – without external network interruptions:

Configuration and Verification in MySQL

Return to the MySQL command line to verify the configuration and configure the new database:

As you can see, here performance_schema is working correctly.
Update the root password in the MySQL environment to secure the new installation:

Restart MySQL in safe mode to ensure all configurations are applied:

Configure MySQL Server to Run New Database

After securing the new MySQL configuration, update the server configuration to use the new data directory:

Restart the MySQL service to load the my.cnf file during mysql startup:

Export and Restore Performance Schema in MySQL

With the new configuration, export performance_schema using MySQL commands and prepare for its restoration:

It’s necessary to shut down MySQL:

Restore the original MySQL data directory on the server, restart the MySQL service, and import the exported schema:

Make sure the default storage engine is running, e.g:

Don’t forget to remove the trash:

If you’ve reached this point, remember to delete the database backup – as long as everything is working. You did make one, right? 🙂