Add LVM cache to existing LVM RAID1 mirror

The new HP Microserver gen8 is configured with Proxmox.

Proxmox is installed on a RAID1 LVM that runs on two uSD cards: on in the uSD card slot integrated into the motherboard, the other via a USB-to-uSD adapter in the internal USB A connector on the motherboard.
I totally forgot about it, until I realized why apt dist-upgrade was running at a snails pace.

For the rest there is little remarkable about the performance of the server. I do worry a bit about writing log records, and I did not configure any swap on the SD cards.

To alleviate the pressure on the memorycards, I add a single GB of LVM cache on SSD (on a total size of 18 GB for each of the mirrored partitions).

Steps to perform:

  • SSD partitioning
    • fdisk /dev/sdh
    • for a new/unused medium: g voor GPT partitielabel
    • n for a new partition, t for type lvm, w to write and save the configuration.
  • Earmark the partitions for LVM-usage
    • pvcreate /dev/sdh1
  • Add the physical volume to the root partition’s volume group
    • vgextend usbsdraid /dev/sdh1
  • Add the future caching device to the existing volume group
    • lvcreate -vn cache_mt_usbsdraid -l254 mt_usbsdraid /dev/sdh1
  • Convert the volume to a cached volume, indicating the caching volume
    • lvconvert --type cache --cachepool cache_mt_usbsdraid /mt_usbsdraid mt_prox_sys
    • I forgot about this, and had to revert the changes on the next power outage, as the system had become unbootable.

That is all. View the result by calling lvs mt_usbsdraid:

# lvs mt_usbsdraid
  LV          VG           Attr       LSize  Pool                       Origin              Data%  Meta%  Move Log Cpy%Sync Convert
  mt_prox_sys mt_usbsdraid Cwi-aoC--- 18.00g [cache_mt_usbsdraid_cpool] [mt_prox_sys_corig] 0.04   2.10            0.00     

Print this entry

Containers do have internet, Proxmox does not

I was unable to upgrade Proxmox. It turned out that internet access was lacking. More specific: the whole lan, with the exception of (the internal side of) the router was reachable. On closer inspection PBS, the backup server, had the same problem.

Reaching those servers from the router was not possible either. In the mean time the containers were accessible from the Internet, and backups were sent as usual.

After checking DNS, dynamic and static IP, bonds and bridges, ARP came in to view as the culprit. arping gave timeouts on the IPs of these servers, while arping on the hostname gave the right MAC but the wrong IP.

Cause of this all was the static ARP-entries that I set for a couple of machines, to have the MAC at hand for wake-on-lan.

De boosdoener: een statisch ARP record

After unchecking the check boxes, applying the changes and flushing the ARP table, everything started working immediately!

Print this entry