This is an update to the post I created back in June of 2011 on how to expand an LVM in CentOS 5.6 running on vCenter. CentOS 6 has made some changes to the way the LVMs are setup so I thought I would update this document accordingly.
- Using your vSphere client, increase the size of the disk attached to the VM.
- Boot into the CentOS 6 installation disk and select ‘Rescue Mode’ from the list of options.
- When prompted to search for LVM partitions on the disk, select ‘Skip’.
- Type the following commands at the prompt. The following assume you have a standard CentOS LVM configuration.
fdisk /dev/sda
p # Print partition table
n # New partition
p # Primary partition
3 # ID = 3
# When prompted, add 1 to the end block value for the sda2 partition and use it as the start of the sda3 partition.
# Use the default for the size which should be the rest of the free space on the disk.
t # Change partition type
3 # Change partition 3
8e # Type = Linux LVM
p # Print partition table
w # Write partition table
# Create a new LVM physical volume from the new partition
lvm pvcreate /dev/sda3
lvm pvdisplay
# Mount the volume group
lvm vgscan
lvm vgchange -ay
# You will see the name of the volume group that is activated. Usually something like 'vg_hostname'.
# Extend the volume group with the new physical volume. Be sure to substitute the name of your volume group in the command below.
lvm vgextend /dev/vg_hostname /dev/sda3
# Extend the logical volume to include 100% of the free space on the volume group.
lvm lvextend /dev/vg_hostname/lv_root /dev/sda3
# Mount the volume group
lvm vgscan
lvm vgchange -ay
# Run a filesystem check on the newly expanded disk
e2fsck -f /dev/vg_hostname/lv_root
# Resize the filesystem to use the entire disk
resize2fs /dev/vg_hostname/lv_root
- After rebooting, you can confirm the final size of your disk using:
df -h
As always, have a backup of your data.
To enhance security, I run SSH on a non-standard port. When using OpenNMS to monitor systems, it only looks for SSH servers on the standard port (22) so I had to update the configuration to monitor systems running SSH on a different port. Here’s the configuration I used:
Note: I spent a long time trying to figure this out. The key is that the ‘banner’ property is the String that the monitor daemon looks for to confirm that it’s communicating with an SSH server. I erroneously put ‘SSH-1920′ which would never match the SSH server’s response banner.
<!-- capsd-configuration.xml -->
<protocol-plugin protocol="SSH-1920" class-name="org.opennms.netmgt.capsd.plugins.SshPlugin" scan="on">
<property key="banner" value="SSH" />
<property key="port" value="1920" />
<property key="timeout" value="3000" />
<property key="retry" value="1" />
</protocol-plugin>
<!-- poller-configuration.xml -->
<service name="SSH-1920" interval="300000" user-defined="false" status="on">
<parameter key="retry" value="1"/>
<parameter key="banner" value="SSH"/>
<parameter key="port" value="1920"/>
<parameter key="timeout" value="3000"/>
<parameter key="rrd-repository" value="/opt/opennms/share/rrd/response"/>
<parameter key="rrd-base-name" value="ssh-1920"/>
<parameter key="ds-name" value="ssh-1920"/>
</service>
<!-- ... and farther down below ... -->
<monitor service="SSH-1920" class-name="org.opennms.netmgt.poller.monitors.SshMonitor"/>
After upgrading the CentOS 5 system that is running my company’s internal ticketing system (OTRS), the automated cron jobs for processing tickets started throwing the following error:
Message: dualvar is only available with the XS version of Scalar::Util at /usr/lib/perl5/vendor_perl/5.8.8/IO/Socket/SSL.pm line 19
This error was caused by an upgrade to the Compress::Zlib package. The newer version of the package isn’t compiled with XS support. I found some information about this error from this OTRS mailing list post from 2010 regarding RHEL. Looks like it takes about a year for RHEL packages to make it downstream to CentOS.
To fix the error, I ran the following from the command line:
perl -MCPAN -e "CPAN::Shell->force(qw(install Scalar::Util));"
After letting the cronjobs rerun, the error was gone and tickets successfully processed again.